Bringing VOEvent v2.0 home to roost

[Mike Fitzpatrick]

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/02856177/attachment-0001.html>