Date
Attendees
Goals
new spec, new github repo for spec maintenance, proposed tweaks for impersistence and developer assistance
Discussion items
Item | Who | Notes |
---|---|---|
Announcements | ||
Calls for papers, submission deadlines, upcoming meetings: Calendar of events | ||
Any news items we should blog about? | ||
New ARK spec (v30) | ||
This new (v30) spec is the first draft with raw XML stored in a github repo: jkunze/arkspec
| ||
Support (non-normative) for building ARK services using N2T's convention – should the ARK spec describe this as one known tool for resolver implementors?
| ||
Questions about how to do short term ARKs keep coming up. All the ARK services, features, metadata, inflections could be used for ARKs that are persistent but within a defined ending term (eg, access expires in 12 months). How best to avoid confusion if ARKs can be used for both persistent and impersistent identifiers? How about suggesting a NAAN-based convention, similar to how four particular NAANs (eg, 99999 and 12345) instantly (in the string itself, not requiring lookup) tell the recipient something this important? Strawdog "Zero NAAN" proposal: every org that receives a NAAN, say 98765, also implicitly receives a second NAAN with a '0' (zero) prepended. We can promise that we will never assign a NAAN beginning with zero, but that if you publish an ARK with a NAAN starting with a zero, say "ark:098765/t7gh, the recipient can assume instantly that it is not suitable for long-term reference. Implementors would be encouraged (but it would be optional) to publish with a leading zero if and only if they want to reveal impersistence right away. |