Re: next

Bernard, hello.

On 2008 Jan 28, at 17:43, Bernard Vatant wrote:

>>> - suggest keeping version info in the name of the vocabulary
>>> (rather than in the pathname, which might change without the
>>> vocabulary actually changing) - eg. "http://myvocab.org/myvocab-v1.1#mytoken
>>> " rather than "http://myvocab.org/v1.1/myvocab/#mytoken".
>>
> I wonder if it's a good idea to have version number at all in the
> token URI (identifying a concept, right?). Generally, the vocabulary
> itself has a version numner, but the concepts are better off defined
> by a stable URI, e.g., http://myvocab.org/myvocab#mytoken. Since the
> definition can change and the authoritative one is in the current
> version, you can use something like :
>
> http://myvocab.org/myvocab#mytoken rdfs:isDefinedBy http://myvocab.org/myvocab/
> where the later URI serves the most recent version of the vocabulary.
>
> See a good exemple of this good practice in the publication of
> Dublin Core elements in RDF. The vocabulary is permanently at http://purl.org/dc/terms/
> which currently serves the latest version of the vocabulary http://dublincore.org/2008/01/14/dcterms.rdf
> in which elements have version-independent URIs, such as http://purl.org/dc/terms/creator

I had seen, but never fully apprehended this feature of the DC namespace.

Is this necessarily a good thing? There seems to be a potential problem here, since if I describe something as http://blah#X in 2008/ v1.0, and later describe something as http://blah#X in 2018/v2.0, I'm relying on the concept meaning the same thing at both times.

Wouldn't it be better for me to say that the thing is a http://blah/2008#X   once and for all? At least then I'm committing myself to what this concept means in 2008, and not whatever shades of meaning it might acquire in the future.

I might subsequently declare that http://blah/2008#X and http://blah/2018#X   are the same thing; but I may not, because our understanding of what Xs are might have changed. Also, what happens if a maintainance process decides that the term http://blah#X wasn't a useful one, and deletes it: in that case when I try to find out more about some resource labelled as being about http://blah#X, the redirection to the fully-versioned namespace fails. What was a valid term has suddenly ceased to be so.

If I recall correctly, the DC set handles this by having various deprecated terms. Does that really work? Is it perhaps the case that DC works in this case because it's almost entirely structureless?

Perhaps I'm being over-fussy here, and this level of precision is appropriate only to a fully formal ontology.

As Rick says:

> If your app downloads a vocabulary one day and finds that it's
> useless the next, what do you or the app do? Simply give up and try
> again? Many of our vocabularies are liable to be fairly volatile.

[I think I would qualify the last remark by saying that the vocabularies will be volatile in the short term, as they standardise and as the community gains experience, and volatile in the long term, as the underlying domain knowledge changes; but at least they'll be stable in the medium term]

But yes, +1.

> See what I've done at http://lingvoj.org

This is very nice, in multiple ways.

> There is a heap of RDF good parsers, but they are not equal vs the
> XML world. If you want to interface RDF storage/processing with a
> "normal" (non-RDF) XML environment, this is to be looked at closely.

Yes: I would think that generating `normal' XML vocabularies would not be a massive intellectual challenge, but it would require some thought and some standardisation effort, and be a logically separate step, and a distinct vocabularly deliverable.

> Just a reminder that SKOS mapping had never been so far a
> "standard", but a side-order of first versions of SKOS vocabulary as
> a product of SWAD-Europe project, when it was not even on the W3C
> track. In a nutshell, was has been decided is that the few elements
> of SKOS mapping were not worth a separate namespace and
> specification, but were to be revisited and included in the "core"
> specification. And effectively with less expressivity (or more
> simplicity).

Thanks for this clarification -- much more concise than my version. So does this imply that the union/intersection/complement support has been deferred or dropped?

Best wishes,

Norman

-- 
Norman Gray  :  http://nxg.me.uk
eurovotech.org  :  University of Leicester