VOEvent References

Wed Mar 23 04:14:49 PDT 2011

Rob and all, hello.

On 2011 Mar 21, at 22:11, Rob Seaman wrote:

> Passive-aggressive isn't going to get us anywhere :-)

Grrr, you're right, sorry.  I should have put that squarely in a <muttering-darkly-into-beer> element.

>> Suggestion: I think this attribute should be named 'contenttype', and its content should be "URI | safe_curie | curie" (see <http://www.w3.org/TR/curie/>).  That is, either a URI, or prefix:string optionally with [...] round it.
> 
> <Reference> currently has a value (a URI), an enumerated type, and a name.  It must be empty.
> 
> The current v2.0 phrasing in section 3.9 of:
> 
> 	http://www.ivoa.net/Documents/VOEvent/20110318/PR-VOEvent-2.0-20110318.html
> 
> still requires it be empty, and simply suggests that the type "should" be a URI.  If the language is clarified to permit "type" to be any string, can the strings be self defining enough to permit sorting out the URIs or vocabulary terms

After the last couple of days' discussion, I'm starting to think that a single typing attribute would be optimal, and that there's little benefit in any format/mime attribute.  RIck's parallel message summarised the current options: of his options, I'd go for uri, <nothing>, meaning, allowed.

The problem with a format/mime attribute is that (reiterating my previous message) it depends on there being a boundary between meaning and format which one can distinguish in any particular case, but which someone else might reasonably draw elsewhere, and which might be different in a different application.  I don't believe that boundary is stable enough to be baked into a protocol.

Doug noted that the ObsTAP list is dealing with the same problem, and (from his message of 2011 March 21 19:53; I haven't been keeping up with that list) they now have a format plus two levels of science type, one layer of which is to be defined in the standard and the other by the data provider.  This appears to end up with _three_ controlled vocabularies.  That's the road we're travelling down in VOEvent: it doesn't seem an attractive destination to me, but is an inevitable consequence of trying to pin down the meaning/format boundary.

So what I suggest is skipping a format/mime attribute, and instead having a single @meaning attribute, the value of which is a URI (which may name a SKOS vocabulary concept but need not).  This is to be compared case-sensitively [1], so it's cheap to compare, and the comparison can be done as a string, with no network access required [2].

That's probably enough.  If something is a finding chart, you probably don't need to know beforehand whether it's JPEG, PNG or GIF, because you can handle all of them (and if you can't, and it matters that much, use the 'Accept' header).  If it's a catalogue, then a client application would I imagine be able to handle a SExtractor catalogue amongst others; if the provider thinks it's likely to matter which one it is, then the provider can give the @meaning as a SExtractor catalogue, as Rick illustrated.  Any client which doesn't know what a SExtractor catalogue is, isn't going to be able to use it anyway.  The same goes for Rick's #SwiftByteFormatStream and 'telemetry'.  If some higher-level application needs to know that #SwiftByteFormatStream is telemetry, there are ways of telling it that which this spec doesn't have to concern itself with.

I withdraw the suggestion to use CURIEs.  That would add a dependence on another standard, plus extra parsing paths, plus either prescription or convention for defining prefixes.  The only benefit would be a few bytes saved in the VOEvent packet, and a slightly prettier XML file.  I know that small is good, in VOEvent, but is it worth the pain?  Yes, I _am_ suggesting forbidding ivoat:telemetry, say, in favour of the full vocabulary URI.

If it later turns out to be necessary to include these prefixed things (CURIEs), then that can be added in a future revision.

Do we need @name?  If there's a need for some chatty/scribbled human-readable content explaining the reference, then that could simply go in the element content.

Going back a little while, Mike's question of 2011 March 16 has to be addressed:

> Tell me how to write an app that knows "ivoat:LightCurve" is either a PNG file or an XML schema or a VOTable of values.  Convince me I can profitably use a 'type' attribute like
> 
>    "http://.../data-models/#h-filter-image"
> 
> and make it "machine-readable".

I think there's a couple of answers.  One is that http://...ivoat#LightCurve should be something more specific, like ...#LightCurveImage or ...#LightCurveData.  Hmm: maybe; that'll be a better answer in some cases than in others.

Or you could retrieve the URI and say 'Accept:image/*,application/x-votable+xml'.  If the URI is an XML scheme (!?) then the server will respond 406 Not Acceptable; if not, you get something you can read.  If what comes back is a .bmp file, say, then what the hell, you've wasted a few bytes on the networks, and have the excuse for a slightly tetchy email to the provider.

This way, the problem comes down to judgement, and an emerging consensus on what items should be in IVOAT, and how providers should label their References in order to be popular with developers.  That is, there's some balance between case-by-casing and good practice on the part of providers.  That's a World Wide Web type of answer: standardise little, sort out good practice later.

[1] Precise language TBD.  There are a few conventions and prescriptions on comparing URIs for equivalence, but this is the simplest one.

[2] If the URI is dereferenceable (as I think it should be), then that can provide extra information, but that shouldn't be necessary in on-line operations.

> or other ontological lagniappe for separate processing?

'Lagniappe' is a _tremendous_ word (with a four-language etymology). I'd never heard of it before.

> On Mar 21, 2011, at 11:32 AM, Norman Gray wrote:
> 
>> So perhaps the _real_ answer is to say "forget about this distinction between @sciencetype and @mimetype, since the boundary between them evaporates as you look at it; instead describe all the information you have in some suitably flexible packet of semantic description".  But I _know_ no-one's going to buy that (which is a pity, because I'm starting to think that's close to the right answer).
> 
> I kind of figured a "suitably flexible packet of semantic description" was the intent of VOEvent.

and...

> Is this really a VOEvent-specific issue?  Does it need to be addressed prior to v2.0?

You're right.  Whatever the full answer is, it doesn't have to be delivered by VOEvent.  The above might find the right balance.

All the best,

Norman

-- 
Norman Gray  :  http://nxg.me.uk
School of Physics and Astronomy, University of Glasgow, UK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5341 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20110323/47140f8e/attachment-0001.bin>