> 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 Received on 2008-01-28Z21:34:55