Standard IVORNs, data model identifiers

[Markus Demleitner]

On Tue, Feb 18, 2014 at 07:51:48PM +0000, Paul Harrison wrote:
> 
> On 2014-02 -18, at 15:53, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> > (a) have unversioned standard identifiers in dataModels (and possibly
> > other places like standardIDs) henceforth, i.e.,
> > ivo://ivoa.net/std/RegTAP -- that kinda works as long as the standard
> > evolves smoothly enough and we make a new record for a new major
> > version ("std/RegTAP2").  But then there's no machine-readable way of
> > figuring out the version actually found on the other end, which is
> > probably not good.
> > 
> > (b) go on as we have so far and create a new standards record for
> > every (even minor) version that we need in standardIDs and similar
> > places.
> > 
> > On a longer run, we might want to fix VOResource to allow fragment
> > identifiers in IdentifierURIs, but that's not an option right now.  I
> > need to put the id people should be looking for into the RegTAP
> > document now.
> > 
> > My feeling is that (a) would be nicer in priciple, but it would be
> > basically impossible for a client to use any features introduced  in
> > point versions.  That would throw us back to (b) with the implied
> > inflation in records.
> > 
> > Opinions?  Elegant solutions, anyone?  Please?
> > 
> 
> Is not the easiest/best solution to change the TAPRegExp schema and
> standard to expand the reference to be xs:anyURI as you need? What
> you want to do with the <ri:Resource xsi:type="vstd:Standard" ?> as
> above is exactly what is the intention of the StandardsRegExt, so
> it would be better if the reference attribute were  xs:anyURI.
> Doing this does not invalidate any existing records, therefore it
> should be a small technical update to the standard which need not
> go through the whole process.

...but still means a schema change, which is something I'd rather
have avoided.  But from what responses there were, I conclude that
(b) is *really* unpopular, and while (a) might be good enough I still
have a bad feeling about taking away the only standard way to tell
apart different versions of a standard.

Hence, I'm going to put out a schema for
http://www.ivoa.net/xml/TAPRegExt/v1.1 chaning all vr:StandardURI to
xs:anyURI.  Even if what's below is carried through, I can't really
see how being a bit more liberal here will badly hurt us.

Protest if you disagree.

> As for changing the definition of IdentifierURIs in VOResource, I
> think that perhaps a new type could be introduced where the
> allowable references do include the fragment and query parts of the
> standard URI - I think that it was definitely envisaged originally

Well, the trouble with this is that then quite a bit of other stuff
needs to be fixed, too, if fragments become standard in standard
IVORNs.  Here's a selection of items in VOResource and vicinity that
would need to be touched, by a quick go through the schemas:

cs:CSCapRestriction/@standardID,
sia:SIACapRestriction/@standardID,
sn:SNCapRestriction/@standardID,
ssa:SSACapRestriction/@standardID,
tr:DataModelType/@ivo-id,
tr:TAPCapRestriction/@standardID,
vg:RegCapRestriction/@standardID

On the other hand vr:identifier presumably should not allow fragments
(though I'm not sure whether this actually needs enforcing by the
XSD).  About the same goes for vr:Validation/@validatedBy and
vs:ServiceReference/@ivo-id (call that set "pure").

For vr:ResourceName/@ivo-id (that's for things like contributor,
facility, instrument, managingOrg, name, publisher, relatedResource,
I frankly think allowing fragments would make sense for some use
cases (think an enumeration of staff within a future version of
vr:Organization; this would make a whole lot of sense with
contact/@ivo-id and creator/@ivo-id).

Looking at this list I think just changing IdentifierURI will do what
we want while losing only very little in terms of error detection
power (and of course, a strict validator would have to dereference
all these ids anyway and see if the references make sense, so syntax
alone -- which can't catch most of the interesting errors anyway--
may be even less helpful).

If we actually decide we want to tell apart references to records
from those to elements within them, then I'd rather vote for making a
type (vr:RecordReference, say) that restricts the the loosened
StandardId to not having a fragment identifier; that way, only three
elements (the "pure" set) would need to be changed, and only in two
XSDs.


Now, if we feel these kinds of identifiers are what we want, then
*someone* (see me conspicuosly watching the sky?) would have to care
about this; I expect datalink will go PR fairly soon, and by then we
should be able to tell DAL how to write the id.

Cheers,

          Markus