Bringing VOEvent v2.0 home to roost

[Mike Fitzpatrick]

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/1a1d5235/attachment.html>