Bringing VOEvent v2.0 home to roost

[Matthew Graham]

Hi,

This might be a useful piece of metadata to include in the registry entry for a stream.

	Cheers,

	Matthew

On Mar 15, 2011, at 1:30 PM, Mike Fitzpatrick wrote:

> 
> 
> On Tue, Mar 15, 2011 at 1:24 PM, Rob Seaman <seaman at noao.edu> wrote:
> So the type attribute (section 3.9) doesn't work for this purpose for some reason?  Which is to say that a URI doesn't serve?  "MIME-typed web content" is one of the stated intents for a type URI.
> 
> Ahhh, but then I would be forced to access each and every
> Reference object to find out what it actually is before deciding
> it isn't useful.  Is it really necessary to trigger all those (often 
> repeated) data requests when the Publisher who put the 
> Reference in the doc in the first place likely already knows 
> what it is and could easily tell me in an attribute?
> 
> 
>  
> 
> Regarding where references may appear, I would tend to support "everywhere" as the default with specific omissions if there are good reasons to limit usage.  Rather than "nowhere" as the default with specific inclusions.  Black list, not white list, that is.
> 
> Comments welcome from the peanut gallery.
> 
> Rob
> 
> --
> 
> On Mar 15, 2011, at 1:03 PM, Mike Fitzpatrick wrote:
> 
>> 
>> 
>> On Tue, Mar 15, 2011 at 12:38 PM, Rob Seaman <seaman at noao.edu> wrote:
>> 
>>> The graphic in the v2.0 PR draft is illegible in the PDF version.
>> 
>> It zooms ok for me.  ....
>> 
>> Sorry, I meant in a *printed* PDF copy of the draft.
>> 
>>  
>> I hadn't previously understood you to be commenting on references in tables and I'm not sure I understand what you're talking about yet.  Perhaps an example?
>> 
>> 
>>     <table>
>>        <reference uri="http://...../something.fits" />
>>        <field  ....>
>>             :
>>        <data> <tr><td> ........ </tr>
>>        </data>
>>     </table>
>> 
>> Other than my example where the data in the <Data> are a subset
>> of what's in the <Reference> (which can only be assumed since there
>> is no way to explicitly state this), I'm not clear how a <Reference> in
>> this case adds anything to the table other than confusion.
>> 
>> The same can be said about other uses of <Reference>:  On one hand
>> they provide links to external content that might be meaningful to a
>> human via presented links to some HTML description.  On the other
>> they can be "a link to the data model that is needed for a machine to 
>> understand the meaning" or perhaps another voevent packet itself, 
>> but there is no way to know which hand is being used when parsing 
>> the packet.
>> 
>> What I'm suggesting is that a new mime-type (NOT 'mimeType' 8-)) 
>> attribute might resolve this and at least offer apps a chance to figure 
>> out what the object is (even if it is meant for human consumption this 
>> might cause an app  to launch a FITS viewer instead of a web browser 
>> to render it).  In the face of many thousands of packets a night surely
>> it can't ALL be human consumable references, so how do I effectively
>> make a machine know when something is useful or not?
>> 
>> -Mike
>> 
>> 
>> 
>>  
>> 
>>> One last comment:  As an application developer I'm not sure I find the
>>> <Reference> all that useful.  I understand the desire to be able to link to
>>> any external content, but what I'd like to see is something like a mime
>>> type attribute so my app can decide whether it can handle whatever 
>>> the data might be.  The 'uri' is essentially free text, you say it's in a URI
>>> syntax but a value like "http://.../data-models/#h-filter-image" is
>>> meaningless unless the app knows what to expect (or just treats it
>>> as bulk data for download).  The case for a reference to another event
>>> packet is pretty clear, but how do you expect apps to use e.g the
>>> <Reference> in a <Param> ???
>> 
>> It's heartening to see comments from the point of view of using VOEvent in applications.  One aspect of references is similar to the description element, as a way to supply human readable (or clickable) content.  Whether this is useful may depend on the application.
>> 
>> VOEvent represents the trade-off of transient alert "telegrams" between human-readable and machine-parseable text.  An early choice was to express values as params rather than explicit schema elements and attributes.  The table mechanism in v2.0 is an evolution of this.  An attempt was made to introduce more explicit machine-parseable elements into the schema via SimpleTimeSeries.  Objections were raised that this was too heavy a schema load.  The objection here appears to be that references are too lightweight.  Maybe so, but they haven't changed that much since v1.0 of the standard.
>> 
>> Are your last couple of comments just suggesting that <Field> not be permitted to contain <Reference>?  Perhaps Roy can comment.
>> 
>> Wherever a reference or other URL/URI appears, I would think the obvious app behavior would be to provide a clickable link, likely via a browser.  If the app doesn't have a GUI, presumably just pass the reference to the output packet (if any).
>> 
>> Rob
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20110315/5f03e786/attachment-0001.html>