Bringing VOEvent v2.0 home to roost

[Rob Seaman]

As Matthew says, how would this interact with the registry description of the corresponding VOEventStream?

So basically you are saying that type should not be a URI, but rather a mime-type.  Perhaps such an attribute would better be called just "mime".  And there should also be a role attribute.  In both cases we would need to define the acceptable values either explicitly, or perhaps via the registry?

Or perhaps a URI-typed "type" attribute in addition?  Or is omitting this the real benefit?

Once we sort out the options, perhaps it's better to move forward from the v1.11 language:

> 	3.9.2 type — The type of the document. Allowed values are "voevent", to reference a previously issued VOEvent packet (in whole or in part);"url", for a MIME-typed URL; "rtml", to refer to an RTML [15] document (typically the one used to drive the telescope that made the observation(s) resulting in the event), or — "ivorn", to refer to IVO resources. The default value is "url".

In the absence of rapid convergence, the chair suggests we leave the v1.11 language in place and hold the issue over for v2.1.

Whether tables (or fields of tables) can contain references is a separate issue.  Strong opinions on this?  Perhaps "no" for v2.0 with the thought to revisit the issue for v2.1 (hopefully under a different chair :-)

Rob
--

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

> 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/11b7118c/attachment.html>