VOEvent vocabulary?

[Frederic Hessman]

Glad to hear the Trieste meeting was so successful and that the list  
of things to do looks interesting.  Rob gave me the task of preparing  
a VOEvent vocabulary, a job I'm happy to assume with your help.

For those of you who haven't read the proposed vocabulary standards  
document, here's the executive summary:

	- the format for vocabularies is the W3C SKOS/RDF standard, expressed  
either in XML or in "Turtle" (a short form without all of the <tags>);
	- vocabularies basically consist of some number of entries each having:
		- a simple token for computers (e.g. "grb");
		- simple labels for humans (e.g. "gamma-ray burst"), potentially  
localized to different languages;
		- optional aliases;
		- optional links to other entries which are related, broader or  
narrower concepts;
		- optional misc documentation (e.g. descriptions, usage hints,...)
	- vocabularies can be easily "mixed and matched" so that no  
vocabulary has to be totally self-contained and complete;
	- no one has to use anyone else's vocabulary - there's nothing like a  
universal must-use vocabulary like UCD1 - and indeed, the expectation  
is that each community will create, maintain, and publish their own  
specialized vocabularies (an unusually democratic idea with the VO);
	- you're asked to publish a translation between your vocabulary and  
some other (hopefully more standarized) vocabulary;
	- the IVOA is expected to provide a centralized collection of  
vocabularies (or copies thereof) and their translation tables.

Presently, the draft standard has several examples of vocabularies  
which can now be used "right out of the box":
	- an IAU constellation vocabulary mainly used as a simple example but  
useful already to keep track of Cygnus, Cygni, ...
	- the ancient but august IAU 1993 taxonomy (we don't have to come up  
with a token for an armillary sphere, IAU93 already has one) all in  
caps but with translations into French, German, Italian, and Spanish;
	- a version of the A&A thesaurus keywords;
	- the AVM (formerly AOIM) taxonomy used by the outreach community;
	- a SKOS version of UCD1, not (yet) intended to be the standard  
document, but which encapulates the present standard in a non-text  
based, computer-processible format.

In addition, I've been preparing a draft IVOA thesaurus ("IVOAT")  
which cleans up the IAU93 vocabulary - errors removed, labels not just  
in caps, updated with new concepts.  Since I've promised the semantics  
group to finish a working draft of IVOAT fairly soon, the simplest  
(and undoubtedly best) solution is to do exactly that and then use  
VOEvent - again - as the leading edge example of why a controlled  
vocabulary is needed and how it's used.

If you want to browse some vocabularies, try my ad hoc collection at
	Proposed IAU/IVOA Thesauri in SKOS Format
or, even better, try Alaisdair Gray's "Vocabulary Explorer", where you  
can select different vocabularies, search for terms, and follow the  
related/narrow/broader links:
	Vocabulary Explorer
For example, go to the above link and input the search term "grb": you  
will get links to an IVOAT and an A&A vocabulary reference and you can  
follow the respective ontological links.

VOEvent needs a controlled vocabulary (indeed VOEvent is used as one  
of the best examples in the semantics document).   There are two  
options:

#1 : use IVOAT

The downside of IVOAT is that it's large - so VOEvent developers must  
know that most of it won't be needed.
The upside of IVOAT is that it's large - so VOEvent developers will be  
able to trust that most of the words they might need to use/parse will  
be in it.

#2: create a unique VOEvent vocabulary

Such a process is certainly within the intent of the Vocabulary  
standard - may a thousand vocabularies bloom.   I think that -  
practically - this is not worth the effort right now given that any  
additions needed by VOEvent could just as easily be the final  
additions/corrections to IVOAT before it becomes a standard (of  
sorts).  On the long term, however, the VOEvent will probably want to  
maintain an additional vocabulary for new tokens which can't be added  
easily, quickly, or unbureaucratically into an IVOA standard.

You might think that - given this - the best solution is to go ahead  
and create a longer VOEvent vocabulary and ignore IVOAT.     
Fortunately, the VOEvent community is sufficiently broad that this job  
would be much more work than to simply use IVOAT at first - no work  
needed - and then prepare for the situation that VOEvent will  
eventually need an additional specialized vocabulary (or not).

Thus, my suggestion to all of you interested in vocabularies for  
VOEvent is:
	- assume that VOEvent at first uses IVOAT, which should take care of  
98% of our needs at first with practically no work;
	- gear up to access this and other vocabularies, assuming that they  
will be hosted centrally at IVOA;
	- decide whether your own VOEvent software wants to read XML or  
Turtle (both should be available for correctly published vocabularies);
	- see if you can find any terms you'd like to use but can't find in  
the present IVOAT standard;
	- start collecting specialized terms for a small VOEvent vocabulary.

I'd be happy to hear your opinions.

Rick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20080607/0b6e820e/attachment-0001.html>