Options for Concept URIs

@@TODO

... URI identifier convention for concepts and schemes

The simplest way to talk about a specific concept, category or subject of interest on the semantic web is to give it a Universal Resource Identifer (URI). (@@TODO examples of URIS)

URIs can look alot like URLs (Universal Resource Locators), but there is an important difference - a URI is an identifier for something, whereas a URL tells you how to retrieve something. This can obviously get a bit confusing. However, try to bear in mind that, when we are talking about 'the concept with URI <http://www.example.org/concepts/0023>' we are not talking about a web page - we are just using <http://www.example.org/concept/0023> as a unique identifier for some idea we have in our heads.

You don't have to use HTTP based URIs for your concepts - you can use the INFO URI scheme (@@TODO e.g.) , or even go so far as to register a new URN domain (@@TODO e.g.) . However, the convenient thing about using HTTP based URIs for concepts is that you can arrange it so that, when you plug that URI into a web browser, it does actually fetch and display something for you (i.e. the URI resolves to some web resource). So for example, I could describe a concept with URI <http://isegserv.itd.rl.ac.uk/semwebtopics/124> and then put either a web page at that address, or a service that redirects to a web page. If that web page the tells you about the concept itself, what it is, how it is defined, how it should be used etc. that can be really useful for other people wanting to use your concept scheme.

Ideally, you would like to have a service that supplies a content-negotiable representation of your concept. What this means is that, if a web client program asks for <http://isegserv.itd.rl.ac.uk/semwebtopics/124> and requests content-type 'text/html' (as a normal web browser such as IE or Mozilla always does), then the service returns an HTML description of the concept. If a different web client program asks for <http://isegserv.itd.rl.ac.uk/semwebtopics/124> with content-type 'application/rdf+xml' then the service returns an RDF/XML description of the concept.

Anyway, the choice is up to you. But if you do decide to URIs as identifiers for concepts, you are going to have to decide upon a URI naming convention for your concept scheme and all of your concepts. The convention used throughout the examples in this guide was chosen for purely practical reasons. It is described here as a suggestion only - for a full discussion and recommendation of URI naming conventions, see the upcoming VM TF Note (@@TODO).

@@TODO Describe URI convention

Scheme URI base: HTTP URI base chosen because easy to deploy service for resolution. Must use domain name that you own or are in control of.

Scheme identifier: Here same as base uri. Could be somthing appended to base uri.

Concept identifiers: Defined by appending some unique number or string to base uri. Here slash used throughout, alternative is hash. Slash chosen because frag iDs don't get passed to http servers in http requests - means can't have concept URIs resolving to something unique to that concept. This can be desirable for large schemes.

Doesn't really matter too much, just choose something and stick with it.

For alternatives to using URIs, see part 2 (Advanced Features) section on reference by description.

Note that, just because you have used an HTTP URI for a concept, doesn't mean you are under any obligation for that URI to resolve to anything. However, it is often convenient to have a simple resolution service ...