Volunteers for VOEvent registration?

[Seaman, Robert Lewis - (rseaman)]

IDs received a lot of discussion in the early days. This was coupled with a fervent wish to leverage the IVOA registry structure in near real-time to handle (broker, filter, route, whatever) event packets. The WG pressed on this goal through several interops and later shifted to a more stream-based conceptual model when action on VOEvent registries seemed stalled. As this thread demonstrates, the natural tendency is to bounce back and forth between the two world views.

From my point of view by all means find a new balance that works with the modern evolution of the IVOA. Copying Roy and Matthew since as I recall CACR had a diversity of opinions about IVORNs. (Which is to say there may be additional engineering issues, not to rehash history of little interest even to those of us who were in the room.)

While you're at it you might scan through the ADES schema (also a Pasadena product, hmm...) for moving object use cases and requirements. Back in the day we took a meeting at the Minor Planet Center to extol VOEvent, and somehow "XML" was the only thing they remembered 8 years later when the IAU adopted ADES. I can attest that ADES IDs and brokers are the things I wake up to every day while the NEO community for some reason persists in protecting this planet.

Rob
--

On 10/9/20, 1:27 AM, "voevent-bounces at ivoa.net on behalf of Markus Demleitner" wrote:

    External Email

    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