Vocabularies and VOEvent

[Norman Gray]

Roy, hello.

On 2008 Feb 4, at 22:10, Roy Williams wrote:

> But I am still waiting for the cost benefit analysis.

Hang on: you asked for use-cases, you got use-cases.  You want a cost- 
benefit analysis?

* Benefit: you get the use-cases
* Cost: you have to put "voevent:" in front of your KISS keywords in  
the VOEvent packet.

> I know very little about it except that precision of expression is  
> possible (eg "I want Supernovae Ia but not Ic").

Precision (neigher too much nor too little) is the goal here.

> I worry that there are many vocabularies with no agreement.

The goal is multiple vocabularies, with just the right amount of  
agreement.

> I worry that there are many representation technologies for  
> vocabularies that use complicated languages.

Nope, just SKOS.

I'm taking it that the application of all this to VOEvent will be to  
have very slightly magic strings in the 'why' position.  There are  
some finicky technicalities about the best way to curate, version and  
distribute these, and these are what are being discussed on the  
semantics list.  But these technicalities are all about how one makes  
vocabularies robust no-brainers for the users, with the first  
representative of 'the users' being the VOEvent standard authors, and  
the subsequent developers who will use their standard.

> I worry that use of vocabularies will require knowledge of complex  
> matters like namespaces,

Barely.

> schema extension,

Yuk.  No!

> sparql,

If you want to do funky things with VOEvents or archives of them, then  
it might turn out that this would help, but it won't be necessary.

> skos

Perhaps a very little.

> rdf,

Nope.

> owl,

Definitely not (heh, unless you're Brian!)

> I worry about no being able to use SQL or even Xquery but must learn  
> a new query language.

_In principle_ there's a slight complication in that the namespace  
prefixes (why='voevent:supernova1a') are arbitrary (this is the same  
issue that the Registry folk had to handle a few months ago).  But if  
you want to, you could specify VOEvent to mandate that the prefix  
always be the same one (such as 'voevent:'), so the resulting string  
will be constant, and so you can SQL away all you like without ever  
having heard of SKOS.  Of course, if you're restricting yourself to  
dumb string-matching, then you can't get the added value that  
supernova1a is a type of supernova.

> I worry that the creator of the VOEvent will also need to understand  
> these complex technologies, meaning that few event streams will be  
> done this way. Are any of these valid worries?

They are entirely valid worries. Fortunately, the answers to all of  
them are easy.

> (*) http://www.astronomerstelegram.org/
> click on "Post a New Telegram", you see these categories:
> Request for Observations, A Comment, AGN, Asteroids, Binaries, Black  
> Holes, Comets, Cosmic Rays, Cataclysmic Variables, Globular  
> Clusters, Gamma-Ray Bursts, Meteors, Microlensing Events, Neutron  
> Stars, Novae, Planets, Planets (minor), Pulsars, Quasars, Soft Gamma- 
> ray Repeaters, Solar System Objects, The Sun, Supernovae, Supernova  
> Remnants, Transients, Variables, Stars

Delete the spaces, prefix a suitable URL and a '#' and bingo!, you've  
got your SKOS vocabulary.  Job done! (attached)

Are you proposing this SKOS vocabulary for inclusion in the set of  
distributed vocabularies?  I could sling it in the repository just now.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
eurovotech.org  :  University of Leicester
-------------- next part --------------
A non-text attachment was scrubbed...
Name: roy-telegrams.ttl
Type: application/octet-stream
Size: 1122 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20080204/1db947ba/attachment-0003.obj>