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? | jk: some suggestion in Outreach we should blog about new spec versions, but some of our new spec versions are often only of minor interest; the total departure (in sum) from version 18 will be of interest when we're done | |
New ARK spec (v30) | jk: minor changes in this version, mostly to test new github actions in its new home (first git version) dv: what should we focus on overall in the spec? jk: are we ok leaving the metadata defined (for this spec) by example? jk: current repo is probably going to have to be redone to get it correct | |
This new (v30) spec is the first draft with raw XML stored in a github repo: jkunze/arkspec
| dv: PRs is right; two ways to do it: either fork or add additional participants to the repo; there's usually a social contract, eg, that one designated person approves | |
Support (non-normative) for building ARK services using N2T's convention – should the ARK spec describe this as one known tool for resolver implementors?
| dv: prefix extension could go into an implementors guidelines doc | |
Are there best practices in how to do short term ARKs? All the ARK services, features, metadata, inflections can be used for ARKs that expire (persistent 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 persistent-but-expiring identifiers? 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) reveal something important to the recipient. 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 no org will ever be assigned a NAAN beginning with zero, so if you see a NAAN starting with a zero, published in an ARK, say "ark:098765/t7gh, you can assume that it is expiring and not suitable for long-term reference. Implementors would be encouraged to publish with a leading zero if and only if they know they are publishing an expiring ARK. | dv: maybe instead of ark:0 use "tark:" cm: don't see any reason to say that there's an expiration date up front when it can be in the metadata | |
New comments (from TC) on the ARKs in URLs document Please review for next time | dv: I responded to comments in the doc |
Action items
- John Kunze set up ARKA account and repo
- John Kunze and Karen Hanson will meet to walk through some PR scenarios