> 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]

The difference may also be that the Dublin stuff, being fairly  
straightforward, simply didn't/doesn't/won't change.   Yes, most of  
the VO vocabularies will be fairly stable, but there will be  
additions, changes and corrections all the time.  The versioning  
must, therefore, be explicit.   I think the solution of stable URI  
root (e.g. "www.ivoa.net/?/vocabularies/"?) and changing vocabulary  
names and versions (e.g. "..../IAU93-v1.1") is a great solution and  
not even a compromise.

>> 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.

I still don't see this point at all, especially if we restrict  
ourselves - at least at first - to the basics we've agreed upon (e.g.  
the ones I've been using): we're talking about a very small handful  
of elements that are trivial to parse in XML.  The randomness of a  
zillion possible RDF expressions is irrelevant if all we do is  
broader/narrower/related/... and I haven't heard ANYONE claim we  
should standardize, accept, parse, translate, ... anything more  
complicated (e.g. rdf:List et al.).

Still, I'm willing to give up on this point, hoping that you're all  
correct about the format being a non-issue.

>> 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?

There won't be a solution to this until we also get AND, OR, and NOT,  
so we can officially agree that all we're talking about for now are  
simple, trivial, vocabularies.   If VOEvent needs fancy expression  
elements - really fancy, like the concept of "NOT" - it'll simply  
have to invent it's own standard for now.

Rick