Hello Norman

Norman Gray a écrit :
> 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.
Indeed. This is a very difficult question. What does "meaning the same 
thing" mean exactly? Formally a concept is defined by its description. 
The description changes with time. At which point is a concept 
different? etc. As said by others, dc concepts might be more stable than 
astronomy concepts.
> 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.
Sure enough. But what happens to applications relying on this URI, but 
wanting to use only up-to-date versions of the concept. How will they 
know when, if, how to ... update to new URIs and descriptions?
I have no definitive answers on all that. Just thinking aloud. I have 
several ongoing projects dealing with evolution of concepts. For example 
we've started discussing that at geonames.org. Geographical  are like 
concepts, they are created, named, renamed, merged, destroyed etc ...
> 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.
Deleting without notice used concepts is a bad practice :) You should 
provide instructions of how to reindex the resources.
> 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?
Not only. Deprecation mechanism can be implemented in structured 
vocabularies. Actually we manage that in Mondeca's software. You can't 
delete an indexing concept without redirecting to another one. It does 
solve every problem, for example it does not provide any solution to the 
situation where a single concept is split into several ones, etc.
> Perhaps I'm being over-fussy here, and this level of precision is 
> appropriate only to a fully formal ontology.
No, no, you are pointing at real and hard problems. Time and versioning 
management has nothing to do with the level of formalization of the 
concepts. It happens in dictionaries as well, and in rough data.
> 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]
Hopefully. Concepts, like reference systems, have a certain level of 
stability. Otherwise language and science would be impossible :))
>
> But yes, +1.
>
>> See what I've done at http://lingvoj.org
>
> This is very nice, in multiple ways.
Thanks. Work in progress, wish I had more time to update/improve/enrich. 
Long to-do list ...
>
>> 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.
Yes
>
>> 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?
"Operations on concepts", so to speak, seem to be out of the 
specification - as far as I understand. Look closely at the last working 
draft, and, as said above, feel free to feedback on the SKOS forum. Now 
is the moment to speak, before the specification is cast in stone.

Bernard


-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, cité Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 871 488 459
Mail:     bernard.vatant at mondeca.com <mailto:bernard.vatant at mondeca.com>
Blog:    Leçons de Choses <http://mondeca.wordpress.com/>