2023-04-11 Technical WG Agenda and Notes

• https://www.pidwijzer.nl/en - Persistent Identifier Guide from Dutch Digital Heritage Network
  • • no mention of ARKs?
• jk and dw did first ARK workshop. Was very nice. Donny shared copy of slide deck with call participants

dw: clarify messaging around v.18 being "current" (elaborate on this?) vs e.g. v.36

jk: agreed we should clarify this. punting for now in favor of existing agenda items.

Final discussion of WG homepage review

• KH: counting ARKs via API vs survey (pros/cons)

IETF standardization update

• ARK as URN namespace ? Doesn't preclude pursuing as separate IETF RFC, eg, DOI is getting a URN namespace
  • should be very easy, doesn't require using urn: in front of ARKs
  • would need to remove spec's discussion of URNs and DOIs (a URN namespace)
  • would need to verify a few char set conflicts
• ARK as API rather than as identifier? ARK as centralized silo rather than as distributed (see GJ's April 10 email about n2t)
• Current ARK draft expires April 20

• Define a URN namespaces?
  • see e.g. https://www.iana.org/assignments/urn-formal/doi
  • Could help in the form of establishing ark as ours.
  • Easier to gain standardization
  • jk: any harm in pursuing this?
  • gj: can this be seen a bit like pursuing a trademark, eg, w3id?
  • dv: will look into registering arkid at w3id

• Current draft spec expires April 20.
  • can’t standardize path elements
  • IETF ok with DOI and Handle Informational RFCs that document how their respective domains work; perhaps we should do the same?
• Should we promote arks.org as a global resolver?
  • benefits to having a scalable model - distribute the resolver
  • decentralized vs centralized?
  • Can we continue to advertise decentralized if we have a centralized resolver? Is this a ‘marketing’ issue?
  • would we be betraying ‘first principles’? eg, ARKs not just another silo
  • this issue came up as a result of trying to gain IETF standardization. 

ARK spec transition

* what to call before and after -- call them? V.I and V.II ? old and new?
* add those names to new spec, and add section about transition?

• blog post https://arks.org/blog/upcoming-changes-to-the-ark-specification/
• Changes (complete?):
  • NAAN should be preceded by "ark:", as in ark:12345/x7th8, but the the V.I format should also be accepted as valid in perpetuity, ie, no links will break because of the transition
  • NAAN can be 1 or more betanumerics (no length limit mentioned)
  • ARK chars:    =   ~   *   +   @   _   $        %   -   .   /
       this removes #, adds ~
  • inflections: add ?info  (with ? and ?? reserved for future use, but undefined; ok to keep using them as you do for now)
  • For received ARKs, implementations must support a minimum length of 255 octets for the string composed of the Base Name plus Qualifier
• Draft Transition Plan

  Overall impact should be minimal. The fewer NAANs you deal with, the easier. Timings T1, T2, ..., T6 to be determined later.

  1. If you produce ARKs, by time T1 you should produce ark:12345 instead of ark:/12345

  2. If you produce ARKs but only ever produced new format (ark:/12345) ARKs, by time T2 you should prepare to receive your own ARKs in the old format (because others may unwittingly reformat your ARKs)

  3. If you receive or resolve ARKs, by time T3 you should accept either ark:12345 or ark:/12345, and plan to do that in perpetuity.

  4. If you receive or resolve ARKs, by time T4 you should accept ARKs at least as long as 255 octets.

  5. If you validate ARKs, you should by time T5 make sure your validation is relaxed enough to not reject new format NAANs, ARKs with ~ or #, and Name and Qualifier parts longer than 128 octets.

  
  6. If you receive or resolve ARKs, by time T6 you should recognize ?info and (a) not flag it as an error, (b) return metadata or return something other than 404 (eg, return the object as if no inflection).

dv: arks.org might be better for tying the spec to than n2t.net; I see big benefit to name branding,
    with arks.org distributed among different orgs
kh: wordsmithing needed, separating centralized software from the service
gj: spec is squishy wrt global resolution
dv: should be trivially obvious where to go to find the resource,
     eg, any local resolver system could to
    see my notes https://hackmd.io/dor0GlmTSEuLYouGJ6TIjA?view
    comments welcome

• ARK spec transition
• Initial plan is T1-T6, each representing a set of implementation requirements.
• Can’t really require adherence to the newer standards.
• Perhaps we can reach out to the contact info in the NAAN registry to at least let them know of the changes and propose upgrading.

gj: for transition, we don't have levers to force people to do this
jk: maybe use social pressure, list of reference ARKs that should work
dv: we could use contact info in the NAAN registry to reach out

• Chat log:
  • doi is listed at https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
  • https://github.com/perma-id/w3id.org
  • https://github.com/perma-id/w3id.org/tree/master/ARK
  • https://github.com/perma-id/w3id.org/tree/master/n2t
  • https://hackmd.io/dor0GlmTSEuLYouGJ6TIjA?view
  • (Dave is contact for w3id.org/n2t above)