VOEvent working draft published

[Roy Williams]

Tony
Thank you for your careful reading and comments. Please take a look at 
the responses below.
Roy

> I'm confused by the use of the IVOA identifier in the spec.

I am thinking that an event will have an identifier like this example:
	ivo://nvo.caltech/VOEvent#banana1234
where "ivo://nvo.caltech" is the authorityID,
and "ivo://nvo.caltech/VOEvent" is a resourceID that the Registry can 
resolve.

The resourceID will resolve to a server that speaks the VOEvent 
transport protocol, (which has not yet been created). That server will 
know how to convert the event identifier (after the # sign, 
"banana1234") into the corresponding VOEvent packet.

> It seems to
> imply that all VOEvents will have unique identifiers of the form used 
> to
> identify Resources, and so will all have an entry in the Registry.

All  VOEvent *servers* will be in the Registry. Each server however 
will deal with its own idiosyncratic labelling scheme (eg banana1234) 
that the Registry does not know.

> I would have thought it more likely that each VOEvent 
> server/database/xxx
> would be registered as a resource and the identifiers for each 
> individual
> event would be constructed from the resource identifier for the 
> database
> followed by a unique identifier within the database.

Yes. As above. I guess the document doesn't say this clearly enough.

> More specific comments:
>
> 2.1 Para 1: <<These identifiers are required to begin with "ivo://", 
> and are
> meant to stand in for a particular metadata packet, obtainable from a 
> VO
> registry.>>
>
> What is a 'metadata packet'? This is the first time I've come across 
> the
> term. But an IVOA identifier identifies a VObs *resource*, nothing 
> else.

A metadata packet is an XML document, I think the same thing that you 
mean when you say "resource", which should more properly be called a 
"resource record".

> 2.1 Para 3: <<These take the general form 
> "ivo://authorityID/resourceKey",
> and are references to metadata packets that may be found at a VO 
> registry or
> VOEvent database.>>
>
> Again, the identifier string "ivo://authorityID/resourceKey" refers to 
> a
> resource only, the metadata for which can be returned from any full 
> registry
> or from the publishing registry (whether it is a full one or not).

See above. The VOEvent database server is 
ivo://authorityID/resourceKey, and an event stored in that database is 
ivo://authorityID/resourceKey#eventID

> 2.1 Para 4: <<authorityIDs ... are like domain names on the net>>
>
> No, they are definitely not like domain names. The registry which 
> 'owns' an
> authorityID is the one that can change the resource metadata - the 
> authID
> means nothing else.

A domain name is an abstract entity, then it is hosted at a specific 
internet service provider. In the same way, an authorityID is an 
abstract entity, which is hosted at a specific registry. For example, 
the abstract authorityID "nvo.caltech" is hosted at the specific 
registry http://nvo.caltech.edu:8080/carnivore/

> 2.1 Para 4: <<each is resolved to exactly one endpoint machine>>
> Again, there is no endpoint machine for an authID.

I disagree. See above. Perhaps we are using the wrong words?

> 2.1 Para 4: <<resolve the secondary part of the identifier, the
> resourceKey>>
>
> Any full registry, anywhere in the world, can return the metadata 
> associated
> with a resource identifier, regardless of the authID, and that is all 
> the
> registry does: it does not 'resolve' the identifier.

When I say "resolve" an identifier, I mean "return the metadata 
associated with the resource identifier". Perhaps we could use 
different words?

> 3.2 & 3.2.1: <PublisherID>ivo://uraniborg.hven</PublisherID>
>
> That is not a resource identifier but an authorityID. You might search 
> for
> that authID in the registry and it might have a publisherID associated 
> with
> it but you'd be better off using a proper resource identifier pointing 
> to a
> publisher metadata record.

Correct. We should say instead "ivo://uraniborg.hven/VOEvent". This is 
the identifier of the resource record that points to a VOEvent database 
service. The resource record is hosted at the registry associated with 
the authority ivo://uraniborg.hven.

> Other points
> ============
>
> 3.1.3 version:
>
> Why do you need the version number of the spec? Won't that be 
> contained in
> the namespace for the metadata elements?

Reason 1: Because it is simpler and easier for a parser to get the 
version number from a specific attribute.
Reason 2: Because there may be local updates to a version that have not 
made it up the standards process yet.  A collaboration could use their 
homegrown version 2.1, but it all still parses with IVOA namespace 
version 2.0.

> 3.3.1 <param>:
>
> What is the point of this element? If it contains real data, shouldn't 
> that
> data be part of the schema for the VOEvent? If it is data so 
> specialized
> that only a few applications will use it, it ought to go into an 
> extension
> schema with its own namespace so that apps can see directly whether 
> they can
> handle the data. If it is just extra information that no application 
> will
> ever use, why not just put it in as CDATA?
>
> The param element will lead to confusion and errors in applications 
> handling
> the data (e.g. if two event source databases choose to use the same 
> param
> name for different data) as well as slowing apps down as they have to 
> search
> for and interpret text strings that ought to be represented as 
> elements.

We have had this discussion before in the VOTable context......

Objective: We want to add flexibility to the format, so that somebody 
can put in a datum like
GCN_INTEN_CNTS=17467

My solution is to just put in a
<Param name="GCN_INTEN_CNTS" value="17467"/>
  It is simple and easy, and if the receiving software knows what it 
means and that it should be a positive integer, then we we use it. But 
if you don't know what it means or what to do with it, it is useless.

Your solution is (I think) to make an extension schema, called perhaps 
"gcn". In this case we could encode it as:
<gcn:GCN_INTEN_CNTS>17467</gcn:GCN_INTEN_CNTS>
In this case the extension schema would encode the idea that the value 
should be a positive integer, and it would be automatically checked. 
But I maintain that the extra effort of the extension schema has little 
benefit over this automatic checking. I still have to know the semantic 
meaning of the paramter and its relevance in order to make use of it.

> 3.3.2 <group>:
>
> Same problems as with the param leading to even more errors in 
> applications.

I don't think there would be *errors*, certainly not at the 
parsing/validation level. Perhaps just lack of understanding. If you 
don't know what the group types and param names mean, then you can't 
interpret the packet fully. The same is true even if you go to all the 
effort of including an extension schema.

> 3.7 <citations>:
>
> Does this mean that a retraction has to have a new event ID? If you 
> use the
> same event ID as the original event, isn't that likely to lead to 
> errors?

Yes, the retraction has its own unique eventID.  We have modelled this 
on the scientific literature, where every paper has its own unique 
citation, even one that retracts another.

Roy