VOEvent References

[Frederic V. Hessman]

> On 03/16/2011 2:23 AM, Frederic V. Hessman wrote:
>> Roy's low-level solution is fine as a VOEvent hack,
>
> Not sure I like the word hack.

;-)

>> practical solution with the possibility of maintaining generality  
>> RIGHT
>> NOW is
>> <Reference type="ivoat:lightCurve" ucd="meta.code.url"
>> for which you simply have to check the type to understand very well.
>
> This is certainly the reasoning behind the <Reference> element.
>
>> Roy's example means knowing that the name "Light curve chart" is  
>> what to
>> look for, whereas looking for "ivoat:lightCurve" is just as easy and
>> perfectly general.
>
> What does the code look like? Is it comparing the Reference type  
> with known strings:
>    if Reference.type == "ivoat:lightCurve": handle the light curve
> Or is there a web service involved:
>    meaningObject = vocabularyLookup(Reference.type)
> in which case I ask what is in the meaningObject?

That depends upon how hard-wired you want to make it (after all, your  
solution was totally hard-wired).  Since IVOAT is currently the only  
relatively complete vocabulary, I'd
just make my own handy-dandy list of things out of it I'd like to  
listen to, the "RoysFavorite" vocabulary.  Nobody is suggesting doing  
an extensive semnatic background check for every VOEvent.  It would be  
good to have a correct connection to a schema namespace (already  
officially published for IVOAT, even if it's tentative), but that's  
just cut-n-paste in your code.

> There are a very small number of vocabularies which
>> one could be looking for (here the IVOAT which, while not yet  
>> official,
>> DOES exist: see
>> http://www.astro.physik.uni-goettingen.de/~hessman/rdf/IVOAT/dict/L.html
>> and look for lightCurve).

> OK, so we can look up in your vocab, and we find that Light Curve is  
> related to other terms (magnitude ,maximum ,minimum ,period ,phase  
> shift ,phase wave ,variable star ,velocity curve). I suppose we  
> could also find out it is a subclass of Time Series, and maybe we  
> already have a handler for those, so we can process the light curve  
> with that. Is that the right idea?

That's the idea, even if IVOAT isn't there yet.   I frankly won't have  
time to work on improving the vocabulary basis  if I don't have use- 
cases and drivers.

  Frankly, let's get the first step going and see where it takes us.   
The more fun you have with more semantic information the better, but....

>> I have added (or? haven't checked the new VOEvent schema) the ucd
>> attribute for VO-compatibility. This could be the way to make the
>> "mime-sh" typing, e.g. by being able to use
>>
>> meta.code.xml
>> meta.code.rtml
>> meta.code.fits
>
> This is exactly what Skyalert does. If a Param has  
> ucd=meta.code.url, then it is handled differently in the  
> presentation from other Params. The UCD is coerced to hold a mime  
> type.

That's what I thought.  Better than nothing, but too often with UCD's  
you have to concatenate things without any semantic context, making  
the content hard to understand, hard to parse, and thus hard to use.    
With more astronomical content, you can piece things together more  
intelligently (e.g. not just ivoat:lightCurve but somewhere you see  
ivoat:supernovae and your code and my code can immediately know that  
the lightcurve is of a supernova without either of us hard-wiring a  
parser to make us match).

>> but the other, better solution would be to be able to access
>
> Why better?

Just one lookup, not two.

>> type="ivoat:RTML"
>> type="ivoat:FITSimage"
>> ...
>>
>> so that there is just one, simple, uniform means of identifying  
>> content.
>
> But ucd is also "just one, simple, uniform means of identifying  
> content". Isn't it?

Yes, but UCD is very limited in semantic contexst and content, whereas  
IVOAT - having inherited gobs of stuff from the IAU - is alarmingly  
exhaustive (albeit also incomplete).

>> Roy's solution uses two XML constructs, 10 things to parse and 195
>> characters, mine one XML construct, 8 things to parse, and 174
>> characters (well, one does nominally need a reference to the IVOAT
>> namespace, but I'm sure Roy could hard-wire this one). ;-)
>>
>> Of course, as soon as I get a little bit of input, we can have a  
>> VOEvent
>> vocabulary covering everything Roy could possibly dream of needing  
>> in as
>> compact a set of terms as possible.
>
> As I said above, the thinking behind the "type" attribute of the  
> Reference is to make a place for semantic identifiers.

That's why using "type" for generic semnatic content is so nice and  
why "ucd" is helpful but inadequate all by itself.  This is why I  
suggest adding a "ucd" attribute to  help those who cannot yet consume  
semantics and need something which looks familiar.   That way "type"  
can be reserved for non-mime-ish info.

The bottom line is: why doing something complicatedly and less  
generally when you can do it simply and generally, right now.  Out of  
the box.  No assembly needed.

Rick