VOEvent References

[Rob Seaman]

On Mar 20, 2011, at 8:44 AM, Norman Gray wrote:

> By the way, should we be talking about this on both the Semantics and VOEvent lists?  I'd suggest limiting it to just the VOEvent list.

Or just Semantics if the scope continues to grow.

> I'm sure someone's going to mention that they don't want 'ivoat' to have to be declared before this, but instead to be taken as read.  That was the conclusion of an earlier discusson about vocabulary names and utypes.  I think that was a poor resolution, but hell, it's only storing up problems for developers in the future, so we needn't bring it up again now.

Passive-aggressive isn't going to get us anywhere :-)

If a current consensus were to include 'ivoat', I see no reason to kowtow to some nameless earlier conversation.

> Suggestion: I think this attribute should be named 'contenttype', and its content should be "URI | safe_curie | curie" (see <http://www.w3.org/TR/curie/>).  That is, either a URI, or prefix:string optionally with [...] round it.

<Reference> currently has a value (a URI), an enumerated type, and a name.  It must be empty.

The current v2.0 phrasing in section 3.9 of:

	http://www.ivoa.net/Documents/VOEvent/20110318/PR-VOEvent-2.0-20110318.html

still requires it be empty, and simply suggests that the type "should" be a URI.  If the language is clarified to permit "type" to be any string, can the strings be self defining enough to permit sorting out the URIs or vocabulary terms or other ontological lagniappe for separate processing?

Is there likewise a better use or definition for the "name" attribute?

Or if <Reference> is permitted to have an optional value (i.e., not required to be empty), is there some useful function that can perform?

What is the minimum modification we need to the current language to achieve our immediate goals while also setting ourselves on the righteous path for the future?

> If it's a MIME type, then why not call it a MIME type?
> 
> And I can't see any reason why it shouldn't be a MIME type.

A sufficient reason why not might be if this is going to require additional time to secure the MIME types.


On Mar 21, 2011, at 1:44 AM, Frederic V. Hessman wrote:

> You're right - in the interest of simplicity, lets cut things down to just 2 attributes, please!

Currently we have three attributes.  Which should we omit? :-)


On Mar 21, 2011, at 3:44 AM, Frederic V. Hessman wrote:

> On second thought, put back the corks.....

Corks are for after the ship is launched.  Our goal is to smash the bottle across the prow of the ship.  This conversation, as interesting as it is, should not be allowed to delay the launch.

> P.S. Oh yes, one IS allowed to include several <Reference>'s anywhere one needs them, isn't one.....?

Yes.  We should make sure the schema permits this.


On Mar 21, 2011, at 9:45 AM, Frederic V. Hessman wrote:

> I understand, and this is all very good, but does IVOA then have to create VO standards for everyone who might need it?

Maybe the IVOA has to, but not VOEvent.

> If someone wants to create blue-painted VOEvents, then let's let them say "blue" and not have to hand them the paint.


Indeed.


(resisting a quote from Tobias Fünke)


On Mar 21, 2011, at 11:32 AM, Norman Gray wrote:

> So perhaps the _real_ answer is to say "forget about this distinction between @sciencetype and @mimetype, since the boundary between them evaporates as you look at it; instead describe all the information you have in some suitably flexible packet of semantic description".  But I _know_ no-one's going to buy that (which is a pity, because I'm starting to think that's close to the right answer).

I kind of figured a "suitably flexible packet of semantic description" was the intent of VOEvent.

> This may be turning into a larger question.  Enough now!

Can we identify a trade-off between modest changes now and a broader mandate later?


On Mar 21, 2011, at 11:56 AM, Steve Allen wrote:

> It became clear that the MIME media type could not advise on what sort
> of things were to be done with the images and/or tables; it could not
> say what was intended to be communicated by the file.

> If specific cases are to be described by MIME
> then a standards document defining those conventions can be used to
> register a new MIME media type with semantics as well as syntax.

Is this really a VOEvent-specific issue?  Does it need to be addressed prior to v2.0?


On Mar 21, 2011, at 12:53 PM, Douglas Tody wrote:

> I'll just note that we are discussing much the same thing currently in
> connection with ObsTAP, used to index science data products in an
> archive.  The solution we are currently looking at is similar to what
> has been described here, i.e., there are separate science types and file
> format types used to describe each data product (reference in the case
> of voevent).

Conveying <Reference>'s is not the primary purpose of VOEvent, but is more central to other standards.  What is the appropriate incremental change to the current usage?  We can address a broader mandate in a future update.

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20110321/3e0587aa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attachment.jpeg
Type: image/jpg
Size: 6771 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20110321/3e0587aa/attachment.jpg>