Volunteers for VOEvent registration?

[Markus Demleitner]

Dear Dave,

On Wed, Oct 07, 2020 at 05:05:52PM +0100, Dave Morris wrote:
> Line 705 of your modified VOEvent.tex file says:
> 
>   "Public VOEvent streams MUST be registered in the VO"
> 
> Based on my experience of talking to people in the community who are using,
> publishing and consuming VOEvents, this is not actually what people want. In
> fact there have been a number of informal requests to remove the requirement
> to use an IVORN as part of the event identifier and allow services to use
> their own URI schema for identifiers.

You're pointing out the problem precisely.

You see, sect. 2.4 of IVOA Identifiers says:

  IVOIDs are used to identify resources in the general sense, i.e.,
  they might refer to datasets, abstract concepts, etc.; their
  Registry parts, on the other hand, MUST always be dereferenceable,
  i.e., resolve in the VO Registry.

  http://ivoa.net/documents/IVOAIdentifiers/20160523/REC-Identifiers-2.0.html#tth_sEc2.4

In other words, if your VOEvent has the id

  ivo://firenze.galileo/jupiter?io-eclipse

then ivo://firenze.galileo/jupiter *must* be something registered
(we could relax that a bit in an Identifiers 2.1 spec, but at this
point I don't think that would be wise).

The background of the MUST above, now, was the implict assumption
that VOEvent ids are built as 

  <event stream id>?<event-id>

If this is what we want, we need to require registration or we're
damaging Identifiers.

If that is not what we want, we should tell people so ("The Registry
part of the event id must point to a registered resource under the
creator's control, but not necessarily the event stream itself, just
so long as the creator can guarantee the event id's uniqueness").

Or, as you say, we could just say "use whatever URIs schemes you
want, just so long as the URI is guaranteed to be globally unique".
I don't think there's anything wrong with that -- what was the use
case for using ivoids there anyway?  The only thing I can imagine is
that by an event id you can find the metadata of the originating
VOEvent stream.  And that's something that the community obviously
has done without for the past 10 years or so...

Meaning: I'd be happy to drop that sentence, but only if we commit to
one of the various fixes of the identifier problem.

> This hasn't been proposed as a change to the standard yet, mainly because no
> one has worked out the details of how an alternative scheme would work yet.
> However, given that there may be a number of VOEvent users who would like to
> make that change, I would be wary of adding more text to the document
> re-enforcing the requirement for services to be registered and excluding the
> use of non-registered services in the future.

Ok, what if (once I get a VOEvent stream provider to register and I
can finish the PR) we merge the language as-is and file an issue
against the MUST pointing to this sub-thread?  Based on that, we'll
get a nice additional PR (I volunteer for writing it if nobody else
steps forwar) that saves us from having to require registration.

On the other hand, though: I frankly have a hard time seeing how an
un-registered service could count as "public".  In that sense I'd
claim the contentious sentence is a bit of a tautology anyway...

> In light of this, would you accept a slightly weaker version of the
> statement on line 705, to say that "IF a service does use an IVORN as part
> of the event identifiers, then the base IVORN SHOULD be registered, and the
> following section defines how ..."

Hmmm -- that contradicts the IVOA Identifers spec, and contradictions
within a set of standards are never a good thing. So, let's not.  But
I'd be fine with any of the use-different-resource or
use-any-uri-scheme options above.

           -- Markus