VOEvent References

[Rob Seaman]

See?  Consensus:

Frederic V. Hessman wrote:

> This is why I suggest adding a "ucd" attribute to  help those who cannot yet consume semantics and need something which looks familiar.   That way "type" can be reserved for non-mime-ish info.
> 
> The bottom line is: why doing something complicatedly and less generally when you can do it simply and generally, right now.  Out of the box.  No assembly needed.


While:  Mike Fitzpatrick wrote:

> What I'm saying is:  Either <Reference> is human-readable content and can be arbitrary, or it's machine-readable in which case you need to do more to say physically what the URI will return for an application to be useful.  If there is no actual usage of <Reference> in the current (or future) VOEvent net, then contrain it, define it, or lose it as being non-pragmatic.

But: Roy Williams wrote:

> Is there any change that anyone thinks needs to be made to the specification or schema? I have not heard that yet, looks like we are clear for PR and REC.

And: Matthew Graham wrote:

> Which one? I don't like Roy's solution. If you want a standard term for something like this then use the Standards registry extension that is currently under development. This is the mechanism that VOSpace uses for exactly this purpose:
> 
> 	ivo://net.ivoa/vospace/core#fits
> 	ivo://net.ivoa/vospace/core#jpeg
> 
> These point to human-readable descriptions of what it means in the IVOA resource ivo://net.ivoa/vospace/core
> retrievable from a registry (see the VOSpace spec for more text about the descriptions).

1) First, a point of order.  Is URI syntax general enough for the different possibilities discussed?

	"A URI reference may take the form of a full URI, or just the scheme-specific portion of one, or even some trailing component thereof – even the empty string. An optional fragment identifier, preceded by #, may be present at the end of a URI reference. The part of the reference before the # indirectly identifies a resource, and the fragment identifier identifies some portion of that resource."

If not, we could simply remove the enumerated values that were present in v1.11 and permit an arbitrary string.

2) v2.0 is a hurdle we must clear to get to work on the registries and other neato second generation VOEvent technologies - as has been suggested we should discuss over Gelato.  VOEvent is the poster child for borrowing from other IVOA standards.  Here it appears we would be borrowing from VOSpace.

3) All design is ultimately evolutionary.  We have received useful feedback from prior deployment of VOEvent technologies in the field, as Matthew will discuss regarding SkyAlert at the VAO/LSST meeting next week.  We are relaxing the reference syntax with the presumption that projects will begin using this feature more.  We will gain experience and tweak the usage.

So.  Actions items:

	A) Any objection to including an (optional) ucd attribute as suggested by Rick?  This will "do more to say physically what the URI will return".

	B) Is it a "blocker" for anybody to relax the value of the v1.11 type attribute to a URI?  (Not do you object, but will you take your football home?)

	C) Perhaps you four guys could write a note on reference usage in VOEvent, or perhaps more generally in the IVOA?

	D) Would the description in section 3.9 benefit from clarification?  How?

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20110316/34c9e9f9/attachment-0001.html>