Standard IVORNs, data model identifiers

[Paul Harrison]

On 2014-02 -18, at 15:53, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:

> Dear Colleagues,
> 
> I seem to run into IVORN related gotchas with alarming regularity
> these days, I'm afraid.  Really sorry about this.
> 
> Well, this time it's about StandardsRegExt and data model ids in
> TAPRegExt.  At the root of the problem is that I foolishly declared
> the ivo-id attribute on dataModel as vr:IdentifierURI (rather than
> xs:anyURI).  vr:IdentifierURI doesn't allow fragments, though.
> 
> Why is that bad?  Well, what do these identifiers reference?  Why,
> resource records of course.  No, not quite.  With StandardRegExt, the
> idea is to register a standard more or less like this:
> 
> <ri:Resource xsi:type="vstd:Standard" ...>
>  ...
>  <endorsedVersion status="rec">1.1</endorsedVersion>
>  <endorsedVersion status="wd">2.0</endorsedVersion>
>  <deprecated>1.0</deprecated>
> </ri:Resource>
> 
> After that, I thought it'd be clever to reference these version
> entities in there, for which there is the fragment identifier.
> Hence, version 1.0 of RegTAP would have been
> 
>  ivo://ivoa.net/std/RegTAP#1.0
> 
> I'd have liked that a lot, so I went ahead, put that change into my
> relational registry implementation, from where it went into
> TAPRegExt's dataModel and boom! This is not an IdentifierURI, service
> invalid.
> 
> This is not (only) about URI cosmetics. These identifiers are
> important for locating TAP services supporting, e.g., obscore, the
> relational registry, and more in the future.  How important is
> versioning in that process?
> 
> The answer will determine which of the two exits I can see is
> preferable:
> 
> (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.

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 that there would be cases where this more extended referencing was allowable - see the note in http://www.ivoa.net/documents/REC/Identifiers/Identifiers-20070302.html#formats - again being a small technical extension to the schema it need not require a full update of the standard.

In both cases I think that it is better to amend the schema to be closer to the intention of the standards than either of your workarounds.

Cheers,
	Paul.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2774 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/registry/attachments/20140218/5b6e662a/attachment.bin>