Fwd: Bringing VOEvent v2.0 home to roost

[Mike Fitzpatrick]

Somehow this dropped off the thread to the voevent list, but I
think answers Roy's last point.



---------- Forwarded message ----------
From: Mike Fitzpatrick <fitz at noao.edu>
Date: Tue, Mar 15, 2011 at 1:51 PM
Subject: Re: Bringing VOEvent v2.0 home to roost
To: Rob Seaman <seaman at noao.edu>




On Tue, Mar 15, 2011 at 1:37 PM, Rob Seaman <seaman at noao.edu> wrote:

> Would you replace a URI type with a static string (and maybe some
> enumerated list or UCD-like process for adding entries to the list), or
> would you add a general string-valued mimetype and keep the URI around or
> what?  If there are thousands of events daily, couldn't the app cache the
> type URIs?
>

If I were processing a stream, the caching would be an option (not
a pleasant one in light of what should be a small change to the PR
doc), if I were a SEAP application mining repositories then perhaps
not so much.

Note this is separate from my comment about the use of <Reference>
as a child of <Table>:  A mime-type attribute would tell me *what*
the external object is, but not *how* (or why) it's related to the parent
element
(e.g. is it supplemental documentation of the observing strategy,
instrument design characteristics, a formal definition of say a <Param>,
or is it a related dataset as in my example.  Let's call this a 'role'
attribute that accepts some list of values like 'documentation',
'definition',
'related-data' or somesuch.

With a mime-type and role attribute on <Reference> I think it would be
much easier for apps filtering streams or mining repositories to know
when/whether they need to access the external content.  Otherwise,
I think apps have no choice but to simply access *everything* (which
may be a huge amount of data), or simply ignore the <Reference>.

-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20110315/2ad61110/attachment.html>