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