[DDI-SRG] URN Syntax and URN Resolution

[Pascal Heus]

Achim:
Thanks for putting this together. I'm not attending IASSIST so my
comments below.

- For versioning, I think 3 levels should be enough.
- I don't think all levels should be explicit.

- The syntax for agency is too restrictive and introduces significant
changes form the current approach described at
http://tools.ddialliance.org/?lvl1=community&lvl2=agencyid
- you should allow for additional levels in the agency name. We
currently for example have bls.gov.us.ddi and many institutions will
have "subdomains". For example, I could think decdg.worldbank.org.ddi
for the data group at the World Bank or p6256.crdcn.ca.ddi for metadata
produce under a research project in the Canada RDC network (this scheme
is being implemented today).
- We cannot impose the .ddi as an extension. This has simply been
introduced to identify the registry itself. There is no requirement that
a DDI user must register under the DDI Alliance registry. Other
registries could exist as well (like for example csa.eth.ihsn,
ukda.uk.cessda, insee.fr.eurostat)
- There is no need for the agency identifier to use the reverse notation
- agency syntax should therefore be more loose (*.registryID) and simply
accompanied by a best practice or recommendations.
- If you want t impose a region code, we do support others than iso
(currently .int, .org)

best
Pascal

Joachim Wackerow wrote:
> Dear all,
>
> We had a bug regarding an illegal DDI URN syntax in 3.0. Square
> brackets are not allowed in URN's. The bug fix is to replace square
> brackets [] with parentheses () .
>
> In this process I looked more detailed into the URN syntax and the
> into URN resolution approaches. I looked through the related best
> practices paper, a stack of RFC's and papers on voice-over-ip services.
>
> With this background I have now the impression that several steps
> would make sense
>
> 1.
> again a change of the DDI URN syntax (within version 3.1): clearer
> hierarchical structure, only two separators, the colon as a separator
> between major parts, dot as a separator within major parts. Colon is
> anyway a separator in URN's like urn:nid:nss (nid - namespace
> identifier, nss - namespace specific string)
>
> 2.
> restriction of the number of version levels of an object to a fixed
> number. Unlimited number of versions can cause processing issues in
> every resolution system. This can be especially the case when using
> latebound versions at a specific level (a proposal is using an
> asterisk for the highest version), like 7.*.5. A reasonable amount of
> levels should be defined. Would three be enough?
>
> 3.
> applying for the URN namespace DDI. For this purpose a formal RFC
> document must be written.
>
> 4.
> proposal of using DNS for URN-to-URL resolution
>
> 5.
> application for a DNS NAPTR record for DDI below urn.arpa (for DNS
> names like *.ddi.urn.arpa.)
>
> Topics 1 and 2 are related and time critical. This should be decided
> soon, so it can go into the published version of 3.1
>
> Topic 4 should be discussed in relation to the approach which is
> described in the best practices paper on URN resolution. Both ways
> have some overlap. The DNS-based URN-to-URL resolution provides an
> additional level of interaction. The URN is not necessarily resolved
> to an metadata object directly. The details of the DNS would probably
> need some further clarification with an DNS expert.
>
> Topic 3 and 5 would be a requirement for topic 4. Topic 1 und 2 would
> ease the conversion of a DDI URN into a DNS domain name.
>
> Topic 3 should be done anyway independently from the other topics.
>
> Attached are two documents with details regarding the proposed DDI URN
> syntax and the URN resolution.
>
> Arofan and I would like to discuss these issues with you while the
> IASSIST conference.
>
> I would suggest to have lunch together at Wednesday for this
> discussion. Not all of the people are at IASSIST, but they were
> involved in the best practices paper. Input for the discussion is
> welcome.
>
> Achim