Resolving Term and Ontology URLs

Best Practice for Resolving Term URLs

If you are serving an ontology, you are serving two potential users: someone who has come across a term of your ontology, and wants more information on it; and a tool that wants to read your ontology, or the definition of a term within it, in RDF format. Earlier we said that the first set of users is very important, but how can we simultaneously satisfy tool developers who will not be able to account for all the format and structure variations in HTML web pages?

Fortunately, the general purpose answer is provided by the concept of 'content negotiation' between web servers and clients. This can be used to reply with different content, based on the interest expressed by the web client. And the W3C has presented specific guidance [11] on implementing this approach, most of which is reflected in the descriptions below.

Some questions are not fully settled. (For example, it isn't clear whether providing RDF relationships (as in, "here is the RDF for this term") as an OWL file will break tools that want to see pure RDF. So it is possible that some of these approaches will evolve to reflect current practices, but we believe they are the best available solutions to meet the needs of all the user communities.

Dereferencing URLs for Terms and Ontologies

General Practices

The first entry in each section is the RDF resource representing the vocabulary.

HTML documents are served as content type text/html

OWL documents are served as content type application/xml+rdf

The "Accept: " strings are the content negotiation headers provided by the client, describing what kind of response it would like to see.

Dereferencing Ontology URLs

someVocab (no file extension): the RDF resource representing the vocabulary; dereferenced according to content negotiation as

  1. an OWL document (if some XML-based Accept mime-type dominates, eg., "application/rdf+xml")
  2. an HTML document (if Accept: text/html dominates )
  3. an XXX document (if the corresponding accept mime time for format XXX dominates, eg., "application/pdf" will resolve in a PDF document)
  4. an OWL document (if no Accept)

someVocab.owl
or
someVocab.rdf (these are not the term for the RDF resource itself) : dereferenced according to content negotiation as

  1. an OWL document (if some XML-based Accept mime-type is present, eg., "application/rdf+xml", regardless of existence or dominance of others)
  2. an HTML document (if Accept: text/html is present but no XML-based Accept mime-type is present, eg., "application/rdf+xml")

someVocab.html : dereferenced as HTML of vocabulary

someVocab.n3 : dereferenced as N3 representation of vocabulary

someVocab.xxx : dereferenced as xxx representation of vocabulary

Note:  HTML responses can insert a named anchor for each term (so the client will go to the anchor named 'someTerm' within the HTML).

Dereferencing Term URLs

To be clear, only one of the first two forms below will be designated by MMI as the resource for a given term. The first is the default choice. But if some ontologies require a '#' form for their RDF term resources, that option may be made available. (To maximize usability, HTML responses can be supplied for both forms, as long as each response clearly indicates which form is the actual resource.)

someVocab/someTerm (no file extension): RDF resource representing term (MMI default); dereferenced per content negotiation as

  1. an OWL document (if some XML-based Accept mime-type dominates, eg., "application/rdf+xml")
  2. an HTML document (if Accept: text/html dominates )
  3. an XXX document (if the corresponding accept mime time for format XXX dominates, eg., "application/pdf" will resolve in a PDF document)
  4. an OWL document (if no Accept)

someVocab#someTerm : alternative RDF resource for the term, but only if this form is needed/specified;
dereferenced per content negotiation as in the someVocab case above.

someVocab/someTerm?form=n3 : example of a technique to obtain alternative server content; as above, "?form=owl" or "?form=rdf" will have the effect of changing response (c) to the OWL response, instead of the HTML response.