Any (best) practices for multiple versions of a vocabulary?

[Richard Walker]

I'm interested in hearing of practices, best or otherwise,
regarding publishing multiple versions of a vocabulary (through LDA
in general, and elda specifically).

E.g., one way could be:

.../myvocab/1.0/myendpoint...
.../myvocab/2.0/myendpoint...

I guess this is related to the question of how to host
multiple versions in an RDF repository: host as multiple
repositories, and therefore as separate SPARQL endpoints, or try
to combine as one repository, with the different versions in
separate graphs, or ...

Any ideas gratefully received.

Richard.

[Stuart Williams]

--
You received this message because you are subscribed to the Google Groups "linked-data-api-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linked-data-api-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I won't claim this as *best* practice, but it is a practice I tend to follow. I'd claim that it is inspired at least in part by the way that the FOAF and DC vocabularies are versioned and published as linked data.

First you need to make a distinction between the identification of a term, say <http://xmlns.com/foaf/0.1/Person> and its description in a document, say <http://xmlns.com/foaf/spec/20140114.rdf> or for human consumption at <http://xmlns.com/foaf/spec/#term_Person> (generic) or <http://xmlns.com/foaf/spec/20140114#term_Person> (specific version).

Note that the identifiers for the terms themselves are not versioned. It is their descriptions that are versioned.

Secondly, in each version of a definition of a term (at least in the RDF) add an rdfs:isDefinedBy statement that links from the given term to a downloadable of the version of the ontology document that contains the full ontology eg:

foaf:Person
      ...
      rdfs:isDefinedBy  <http://xmlns.com/foaf/spec/20140114.rdf> ;
      ...

That way you keep the term URI stable whilst retaining the flexibility to update their definition. Only update the definitions in ways that don't conflict with prior use. If you need to coin change a definition in ways that exclude entities that would have been admissable under the 'old' term - create a new term (which may be derived from the old one and include more restriction - or indeed can admit more entities through class composition).

What we tend to do is load current versions of vocabularies into triple stores - which serves up definitions for individual terms (BTW that 'forces' you down a '/' namespace path rather than a '#' namespace - because the fragId is not transferred in the request) and seed the vocabulary with rdfs:isDefinedBy links that reference the definition of the whole vocabulary. eg:

<http://environment.data.gov.uk/def/bathing-water/CoastalBathingWater>

has an rdfs:isDefinedBy (which is seeded in the source file itself) to the deployed location of the source file - from which you can download the full definition source.[We haven't been very good at doing dated/versioned file names - we really only have a current version here - but you can't see how you'd do something more foaf: or dct: like].

We also set up endpoint that work on truncations of URI so that for example:

<http://environment.data.gov.uk/def/bathing-water> will list terms (Classes, Properties etc) from the bathing water vocabulary.

Wrt Dublin Core Terms

    wget --debug --header=Accept:application/rdf+xml http://purl.org/dc/terms/title
and
    wget --debug --header=Accept:text/html http://purl.org/dc/terms/title

and follow along with the redirections - you'll get a sense of how they separate the versioning of descriptions from the terms those descriptions describe.

HTH

Stuart

-- 
Epimorphics Ltd                        www.epimorphics.com 
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069

Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK

[Rob Walpole]

Why publish the vocabulary through LDA specifically? Is it because you want to run queries against it? I would've thought a vocab was just a file and the convention is to publish it at it's own uri e.g. http://reference.data.gov.uk/def/central-government/ so you just need an old fashioned web server for this.

If you want to version it then I would suggest following the OWL 2 recommendation described at http://www.w3.org/TR/owl2-syntax/#Ontology_IRI_and_Version_IRI 

If you are using the vocab in a triplestore then having more than one version could get complicated. I would suggest keeping it in it's own named graph, i.e. separate to the data, then if you want to update it you can just drop and reload the graph. This way you avoid the risk of leaving redundant terms floating about, although of course you will need to patch your data if you are dropping/replacing terms. Creating a SPARQL patch is a one way to manage this.

Cheers

Rob

Rob Walpole
Email robkw...@gmail.com
Tel. +44 (0)7969 869881
http://www.linkedin.com/in/robwalpole

[Rob Atkinson]

many vocabularies are large, structured and dynamic - eg species taxonomies. so if we are talking about a best practice then a general solution is preferred. 

term identifiers need to be / not # based - doc#target is document-centric addressing - and therefore in general only relevant to information resources, not concepts (non-information resources).

so - yes fine to publish a file, but you should at least put a redirect from 

e.g.

http://mydomain/def/myconcept -> http://mycurrentserver/mydoc.fmt#myconcept 

 or for a list endpoint->

 http;//mycurrentserver/myapi?_format=fmt#myconcept

or for an item endpoint

->  http;//mycurrentserver/myapi?arg=myconcept&_format=fmt

The last model will scale to any size or complexity of vocabulary, all will allow many different formats to be used to deliver the same vocabulary.

[Rob Atkinson]

unless you are conflating the general term vocabulary with the limited sense of an RDF definition - but I dont think thats the case here. LDA provides a bridge between RDf-only worlds and the general data web - so i think the broader sense must be assumed.

[Rob Walpole]

Doesn't talk much about versioning in particular but for completeness and following on from Rob A's comments, this is a useful resource for best practice when it comes to publishing RDF vocabularies - http://www.w3.org/TR/swbp-vocab-pub/

As to whether you choose a hash or slash namespace may be influenced by the anticipated scale of your vocabulary..

Rob Walpole
Email robkw...@gmail.com
Tel. +44 (0)7969 869881
http://www.linkedin.com/in/robwalpole

[Rob Atkinson]

In this case recipe 5a is the most general - but the recommendation is "

Step 3

Create files ClassA.html ClassB.html propA.html propB.html each of which contains HTML content documentation relevant to the class or property with the corresponding local name, as at 2005-10-31 (or whatever the current date is). Create a file index.html that contains HTML content documentation about the vocabulary itself, with hyperlinks to all class or property documentation.

whereas sensible people would just put an API to create these on the fly and use URI redirection (as per the other W3C practice).

W3C doesnt always tell the right tentacle what the other 7 tentacles are doing :-)