VOEvent References

[Matthew Graham]

Hi,

Which one? I don't like Roy's solution. If you want a standard term for something like this then use the Standards registry extension that is currently under development. This is the mechanism that VOSpace uses for exactly this purpose:

ivo://net.ivoa/vospace/core#fits
ivo://net.ivoa/vospace/core#jpeg

These point to human-readable descriptions of what it means in the IVOA resource ivo://net.ivoa/vospace/core
retrievable from a registry (see the VOSpace spec for more text about the descriptions).

Each stream provider could actually register their own standard for terms that they are using and then this can be dereferenced (exactly as it says at the moment).

	Cheers,

	Matthew



On Mar 16, 2011, at 10:42 AM, Rob Seaman wrote:

> Matthew, Mike,
> 
> What do you guys think?
> 
> Rob
> --
> On Mar 16, 2011, at 10:31 AM, Roy Williams wrote:
> 
>> Rick
>> 
>> 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?
>> 
>> 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?
>> 
>>> 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.
>> 
>>> but the other, better solution would be to be able to access
>> 
>> Why better?
>> 
>>> 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?
>> 
>>> 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.
>> 
>> Roy
>