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)

Action items