IVOA Identifiers Version 2 Proposed Recommendation: Request for Comments

IVOA Identifiers describes the syntax and semantics of the IVOA's special URIs. Such URIs are being used in the Registry to identify records, but IVOIDs are also used to denote datasets of all kinds, reference standards, and more.

Latest version of Identifiers 2 can be found at:

• http://ivoa.net/Documents/IVOAIdentifiers/20150709/index.html

See also Examples of the validator.

Reference Interoperable Implementations

Doesn't really apply here, as no protocol is defined. However, IVOA identifers are in daily use in the Registry, and we preserve the Version 1 properties that make that work.

The special form of Dataset ids has been in use in the GAVO data center for a while. We will try to have other data centers on board for TCG review and provide a reference service implementing the recommended procedure for resolving these things.

The special form of standard ids has, essentially, been used for VOSI URLs and RegTAP. TAP 1.1 will probably be the first standard to fully use the patterns proposed here.

Implementations Validators

There is a validator for IVOIDs at http://dc.g-vo.org/ivoidval/q/val/form

RFC Review Period: 2015-07-22 - 2015-09-01

TCG Review Period: TCG_start_date - TCG_end_date

Comments from the IVOA Community during RFC period: 2015-07-22 - 2015-09-01

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comments from MarkTaylor

Basically clear, it's good to have a detailed definition of Identifiers for reference. However I have some comments:

• Sec 2: The term "resource key" is used in several places starting in sec 2.1 before it is defined, even informally. A note of what it means should be added early in sec 2.1; maybe add it as an annotation on the graphic that already illustrates "IVORN" and "local part".
• Sec 2.1: The term "IVORN" is introduced here to mean the ivo://<authority>/<path> part of the Identifier. I'm not sure if a formal definition of IVORN has ever existed up till now, the term didn't appear in the previous version (1.12) of the Identifiers standard, and certainly I wouldn't have been able to tell you the difference between an IVORN and an ivo-id. I do think the definition proposed here is useful, but historically that term doesn't seem to have been used consistently in that sense. A couple of examples of historical usage contrary to the current definition are "The IVORN for the only language mandatory for TAP services, ADQL 2.0, is ivo://ivoa.net/std/ADQL#v2.0 " (TAPRegExt sec 2.3), and "... declaring support for the data model Registry 1.0 with the IVORN ivo://ivoa.net/std/RegTAP#1.0 " (RegTAP sec 7); in both these cases the strings are not IVORNs in the proposed sense since they contain fragments. There are probably other examples out there. So, I raise the question of whether we can redefine this term now in the face of contrary historical usage. If we do (which I think would be OK), there should at least be a note in this document to explain how previous contrary usage should be treated - either say it's just wrong, or say that it used to have a more sloppy definition but when used with explicit reference to this document it has the more specific meaning.
• Sec 2.3.3: There seems to be some inconsistency about whether the resource key and/or <path> (which are equated to each other in the first sentence of this section) contains a leading solidus ("/"). The illustration in sec 2.1 suggests not, but the restriction to <path-abempty> would seem to require that it does.
• Sec 4.2: "Registry interfaces will in general offer features for comparing such identifiers with regular expressions ... For instance, with RegTAP an exampleProto 1.0 client would look for capabilities for which standard_id LIKE ′ivo://ivoa.net/std/exampleProto#query−1.%′ ". It's a nitpick, but I wouldn't say the pattern matching language used in SQL is a regular expression; to me (and wikipedia) regexp refers to that syntax used by grep(1) and friends. Replace by "Registry interfaces will typically offer some pattern matching capability for comparing such identifiers ..." ?

Plus a few spellings and typos:

• sec 1.3: "necessiates" -> "necessitates"
• sec 2.3.3: "semanitcs" -> "semantics"
• sec 2.6: "fragement" -> "fragment"
• sec 3: "resrouces" -> "resources"
• sec 4.1: "affected by these requirement" -> "affected by these requirements"

-- MarkTaylor - 2015-08-20

Comments from TCG member during the TCG Review Period: TCG_start_date - TCG_end_date

!!! SECTION TO BE ADDED ONLY ONCE THE TCG REVIEW PERIOD HAS STARTED !!!

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )

Applications Working Group ( _Pierre Fernique, Tom Donaldson )

Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )

Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )

Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )

Registry Working Group ( _Markus Demleitner, Theresa Dower )

Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )

Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )

Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )

Data Curation & Preservation Interest Group ( Francoise Genova )

Knowledge Discovery in Databases Interest Group ( George Djorgovski )

Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )

Standards and Processes Committee ( Françoise Genova )

Operations ( _Tom McGlynn, Mark Taylor )