...
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 Are there best practices in how to do short term ARKs keep coming up. ? All the ARK services, features, metadata, inflections could can be used for ARKs that are expire (persistent but within a defined ending term (, eg, link expires after first access, object access expires in 12 months per agreement with rights holder). How best to avoid confusion if ARKs can be used for both persistent and impersistent persistent-but-expiring identifiers? How about suggesting One approach is a NAAN-based convention, similar to how four particular NAANs (eg, 99999 and 12345) instantly (in the string itself, not requiring lookup) tell reveal something important to 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 no org will ever be assigned a NAAN beginning with zero, but that so if you publish an ARK with see a NAAN starting with a zero, published in an ARK, say "ark:098765/t7gh, the recipient you can assume instantly that it is expiring and 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.they know they are publishing an expiring ARK. | ||
New comments (from TC) on the ARKs in URLs document Please review for next time |