The W3C issued some recipes for publishing your vocabulary that are a good complement to what is introduced here, as well as some more generic good practices for HTTP resources.

Vocabulary IRI

One of the rules of Linked Data is that things are named with IRI so that they can be looked up. Vocabularies are no exception, so make sure yours has an IRI you control. Your vocabulary should be accessible when looking up its IRI. There exists some recommendations to make sure the IRI you picked is cool:

  1. Keep it simple: short, memorable IRI are less error-prone
  2. Ensure stability (remember: cool IRI don’t change). To this end, consider applying for a w3id, a permanent IRI that redirects to your own, less stable namespace.
  3. Promote manageability by using versioned IRI. The W3C versioning approach is to ensure that the permanent IRI of a document always points to its latest version, and that each version has a specific IRI typically including its publication date or version number (referenced with the property owl:versionInfo). Each version points to the previous one with an owl:priorVersion link, and the latest version includes a owl:versionIRI property indicating its versioned IRI. The Dublin Core also provides versioning terms: terms:isReplacedBy and terms:replaces to connect versions to one another, terms:isVersionOf to connect version to the permanent IRI.

We already chose a w3id identifier for the webcomic vocabulary, so all we need to do is versioning, which could look like the following:

@prefix terms: <> .
@prefix owl: <>.

<> rdf:type owl:Ontology ;
                               owl:versionInfo "0.1.0" ;
                               owl:versionIRI <> ;
                               owl:priorVersion <> ;
                               terms:isReplacedBy <> .

Vocabulary metadata

We already described some meta that should be attached to a vocabulary when covering documentation and versioning. Apart from versioning info and a human-readable description, the Linked Open Vocabularies (a reference for vocabulary publication) recommends to add additional metadata to a vocabulary:

Putting all together, the metadata of the webcomic vocabulary could look something like that:

@prefix cc: <> .
@prefix terms: <> .
@prefix vann: <> .

<> rdf:type owl:Ontology ;
                               # Ownership
                               cc:license <> ;
                               terms:creator <> ;
                               terms:contributor <> ;
                               terms:publisher <>;
                               # Description
                               terms:title "Webcomic ontology" ;
                               terms:description """
The Webcomic ontology aims at describing webcomics, the things they talk about, the artists who make them and the people who read them.
    """ ;
                               vann:preferredNamespacePrefix "webco" ;
                               vann:preferredNamespaceURI <> ;
                               foaf:primaryTopic "Webcomics" ;
                               # Version
                               owl:versionIRI <> ;
                               owl:priorVersion <> ;
                               terms:isReplacedBy <>
                               owl:versionInfo "0.1.0" ;
                               terms:issued "52BC-01-01"
                               terms:modified "2019-10-09".

Content negotiation

Now that you have an IRI, a vocabulary and its metadata, and its documentation (that you might want to regenerate to include the metadata), you’re nearly there! The next step to publishing your vocabulary is setting up content negotiation, so that your server serves tailored content depending on who asks. The first usage for this is to show, under the same IRI, documentation to humans and RDF to programs. If you exported your vocabulary in different RDF syntaxes, you can also use content negotiation to serve these different flavours to clients who specifically ask for one. The content negotiation mechanism also explains why we left the file extension out of the IRI: the resource identified by the IRI is not necessarily a single document.

Content negotiation is based on HTTP Accept headers:

  • On Accept: X, X being a IANA MIME type for an RDF syntax (e.g. text/turtle, application/rdf+xml, application/trig, ` text/n3, application/ld+json`…), serve the appropriate document
  • On Accept: Y, Y being a IANA MIME type for human-readable text (e.g. text/plain, application/xhtml+xml, text/html…), serve the documentation
  • If the client does not provide one, be sure to implement a default behavior, e.g. serving the Turtle document.

Here are specific instructions to set up content negotiation on some popular web servers:

You now have all the information you need to publish your vocabulary online in a friendly manner for people and programs who need to read it.