VOResource 1.1: IdentifierURI

[Markus Demleitner]

Dear Registry WG,

Next up on my list of things to discuss in the run-up to VOResource
1.1 is IdentifierURI.  That's a type that in 1.0 is locked down to
essentially IVOIDs without query or fragment parts[1]; in Identifiers
2.0 language, that's a "registry reference", and it was probably
intended to be just that: A reference to a registry record.

It's used in places like Resource/identifier, capability/@standardID,
ResourceName/@ivo-id, and validation/@validatedBy. Also, TAPRegExt 1.0's
dataModel was an IdentifierURI, which hurt me a lot.

So, it's become a problem.  The reason is that in some of these
places, there should now be more general references.  In particular,
versions of standards eventually turned out to be parts of resource
records rather than separate resource records.  This means that we
now have standardIDs like ivo://ivoa.net/std/tap#query-1.1.  Which
are IVOA identifiers just fine but don't match IdentifierURI.

So, how can we fix this?  I see a couple of ways:

(1) Leave IdentifierURI as is (well, fixing the case-insensitive ivo)
and re-define everything that can have non-simple IVOIDs to be
xs:anyURI.  TAPRegExt/dataModel already went this way in 1.1. In
VOResource, we'd probably just have to touch
vr:Capability/@standardID.  Advantage: it's not very invasive.
Disadvantage: the name IdentifierURI is wrong, because the schema is
far more restrictive than actual IVOIDs are.

(2) Change IdentifierURI to actually allow at least as much as
Identifiers 2.0 does.  Introduce a new type (RegistryReference, say)
that would be essentially the current IdentifierURI.
Resource/identifier, ResourceName/@ivo-id and perhaps
validation/@validiatedBy would then become RegistryReferences.
Advantage: to my taste, that's the cleanest solution.  Disadvantage:
It's quite intrusive, and it changes IdentifierURI, which is/was used
in registry extensions, so we're  "liberalising" some other
schemas, too (which may be what we want, but it's still fishy).

(3) Deprecate IdentifierURI and define RegistryReference as above.
Then, in addition, define  IVOID, say, which allows for full identifiers.
Advantage: as (2), but avoids collaterally changing other schemas.
Disadvantage: Deprecated definitions hanging around.  And it's as
intrusive as (2).

(4) Deprecate IdentifierURI and just allow xs:anyURI whereever there
is now IdentifierURI.  Advantage: in effect, it's a simplifiation;
also, for quite a few of IdentifierURI uses there's no terribly
strong reason why the Registry should play a role at all (e.g.,
standardID), so perhaps allowing whatever URIs people want to use is
even the right thing to do.  Disadvantage: In Resource/identifier,
which architecturally must be a Registry reference (since the primary
key is built from it), we have no syntactic guarantees any more that
what we're dealing with is an IVOA identifier.

So... Does anyone have preferences to one side or another?  Or
perhaps even other solutions?

Me, I'm currently leaning towards (2); hence, if you don't like (2),
you should speak up (even if you hate the other alternatives, too).

Cheers,

           Markus


[1] In case you're curious: it's this wonderful RE:
ivo://[\w\d][\w\d\-_\.!~\*'\(\)\+=]{2,}(/[\w\d\-_\.!~\*'\(\)\+=]+(/[\w\d\-_\.!~\*'\(\)\+=]+)*)?
-- which is probably not right because the scheme must be
case-insenstive (as it is for all URIs).