Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

TimeItemWhoNotes
5mquestions about Experts Day meeting notes?Curtis, Tom
  • Curtis has reviewed, no issues to report
  • Trailing ? possible issue, see below
5mquestions about Bertrand's URI compatibility discussionBertrand
5mNAAN registry URL confirmationall

Sheila: correct entry, but Portico re-working landing pages for ARKs

Mark: Correct entry

Greg: (UCSB) will followup

Curtis: EZID, works fine

Adrien: will check

Bertrand: works fine

Tom: works correctly, registry entry correct

45mprioritizing Experts Day spec issuesall
  1. Literal character repertoire changes: allow '~', but disallow '#' (which is is reserved in URIs fragments and LOD): Greg – are there existing arks with # - if there was no objection, probably safe to assume ok ; to be clear: ok at end of URL, but not part of ARK id itself APPROVED
  2. Make the first '/' optional, so that ark:/12345/678 is equivalent to ark:12345/678. This would match a near universal practice in other id schemes, and is a commonplace and understandable mistake that currently penalizes ARK users and potential adopters. Seems to have become common practice NOT to include first '/'; do not expect it to affect existing ARKs; TOM: caution - without / in FS environment, will 404; JOHN: when ready, publishing new ARKs, do not have to use initial '/'; TOM after change, must support existing arks (that have '/', but are submitted without; We are saying arks for an object, with or without slash, are equivalent to each other; should able to resolve (to that same object) whether or not submission as the '/' ; BERTRAND re ':' Is this a URI compatibility issue? JOHN: per spec should be encoded, so we will have to include this in compatibility question APPROVED
  3. Parsers (resolvers) should check for inflections (final punctuation character combinations) before normalization of final structural characters ('/' and '.'), for example, given "ark:/12345/678./", parsers should check if "./" is an inflection and only normalize to "ark:/12345/678" if no inflection is matched Resolving code should check for inflections first, strip off if found, then do resolution to stored ARKid when receiving an ARK for storage or for resolution; GREG: concerns; EG '.' at end of ARK that has been cut and pasted: is '.' part of ARK or just punctuation - Roxana: question about suffixes; JOHN: importance of normalizing ARKs before storing (i.e. strip off punctuation at end); GREG stress importance of knowing where an ARKid ends for e.g. sharing purposes - complication is that inflections have meaning, and might make it more difficult to "see" the end JOHN, reserving ? will help clarify, solve many problems, NOT allowing '. ' as inflection operator will help clean up many; perhaps we need to make this prohibition more explicit; Tom making further point that proxies are stripping inflection ? already; JOHN possibility is have N2T convert '/' to standard long-form query string that proxies would have easier time correctly resolving; perhaps we should add long-form equivalent for inflections, just use ? and ?? as convenience/macro for user; TOM suggests using application specific approaches to returning different representations (different questions returned by inflections) JOHN have spec express way to use content negotiation mechanisms to express equivalences; PENDING: John will work on clarifying wording
  4. Make the NAAN more flexible – instead of just 5 digits or 9 digits, allow any "beta-numeric" string (defined to be the same as noid repertoire: bcdfghjkmnpqrstvwxz0-9) with no runs of adjacent letters longer than two, eg, ark:/bc8/… but not ark:/bcd8/…. CURTIS is there a need for this? JOHN benefits of shorter id; future for onboarding other identifier systems (eg CrossREF DOI prefix mapping could be done); preserves opacity; might remove barrier for new registrants GREG might make ARKs less immediately "grok-able" as ARKS, but not showstopper; BERTRAND questions re: 9 digits – JOHN - -none exist now, we can just suppress reference to 9 digits; CURTIS single digit NaaN? JOHN yes possible in theory
  5. Update our understanding of what it means for metadata returned by inflections ('?' and '??') in 2018 to be both human- and machine-readable. In 2003, a simple email-header format (eg, ANVL) served both purposes, but now it is common to see a human-readable HTML landing page with machine-readable metadata embedded in it (where it doesn't interfere with the user experience). JOHN Currently simple to embed machine readable version in human-readable response (EG JSON) TOM strong encourage for future of spec, Curtis also APPROVED
  6. Max link length for the ARKs : now 128 digit limit change the spec to eliminate the limit, but we will make a recommendation for a minimum of 255 characters supported in implementations Strongly encourage supporting open ended APPROVED


Action items