URIs

Table of contents - URI-related pages

-

A URI is simply a string having a certain form (defined in RFC 3986), usually recognizable by beginning with a short acronym followed by a :, as in http://neurocommons.org/page/URIs. Generally URIs are used as parameters in various Internet protocols and network applications, but they can also be used as names in declarative statements written in a formal language such as RDF - names of people, names of documents, names of logical predicates, names of anything.

How do you find out what a URI names? Any apparatus for keeping track of meanings of names can have flaws, so there is no definitive answer by way of a protocol. But the short answer is that usually you can just use the Web to find out. If you treat the URI the way you would any URI and use the HTTP protocol to get a web page, and that web page has definite statements about what the URI is supposed to mean, then what the URI means is in most cases what the page tells you it means.

If the web page doesn't say anything about what the URI means, you're in trouble - you will just have to infer that from the way it's used; there are so many different things it might be that we can't give you much guidance. (Some people might say that the URI names the web page, but it's not clear what a web page is or what you can say about one. We don't recommend the use of documentationless URIs in RDF, with the possible exception of providing rdfs:seeAlso targets.)

For more careful advice on finding Web-based URI documentation, see URI documentation protocol.

Which URIs?
Since the goals here are communication via RDF and "data mashups", everyone involved in the Neurocommons (or Semantic Web generally) should be motivated to pick URIs for things that match the URIs that other people have chosen or will choose for the same thing. The choice is fundamentaly arbitrary, so judgment must be exercised to try to guess which among the many possible URIs should, or will, "win" any competition. This judgment takes into account difficult questions of organizational backing, quality of documentation, and marketing.

Having multiple URIs for the same entity makes life more difficult. Somehow each project that comes along decides that URIs previously invented for a thing are inadequate to its needs, and invents its own. Our project is no exception. But we have written down our URI requirements and feel that they should be quite generic - they appeal to common sense and ought to appeal to a wide variety of projects.

If no one else has made a URI for the thing we want to name, or if the URI requirements fail on all of them, we feel justified in arguing for the introduction of a new URI. When we want to coin new URIs for our own work, we do so via the Common Naming Project or another one that has similar values.