-
Notifications
You must be signed in to change notification settings - Fork 8
2025 01 21 Technical WG Agenda and Notes
- Roxana Maurer, Curtis Mirci, Dave Vieglais, Karen Hanson, Donny Winston, John Kunze
- modern vs classic ARKs, .suffixes
| Item | Owner |
|---|---|
| Announcements | all |
-
rm: we have new version of our resolver at BnLuxembourg; includes some counters for resolutions of ARK vs target URL (ie, who is using the PID vs the final browser-displayed URL), but might only be for the past several weeks since we delete our logs regularly
-
rm: also counters for numbers of arks per institution; see https://persist.lu/
-
rm: also, we are separating out resolver requests for the resource and for the metadata; and we made some changes to our persistence statements; still need to make sure it again accepts classic form ARKs (with ark:/)
https://persist.lu/resolve/ark:72849/952fvb4fq0 https://persist.lu/resolve/ark:70795/30xgzdkd03
ACTION: rm, dv, cm to draft proposed common json format as possible best practice
- dv: N2T may be able to report ARK resolutions for short windows of time
- jk: possible informal Africa PID Alliance collaboration
| Item | Owner |
|---|---|
| Any news items we should blog about? Any calls for papers, submission deadlines, upcoming meetings we should note? See Calendar of Events (ARKA-Calendar). |
all |
| Item | Owner |
|---|---|
| issues updates | all |
- bulk NAAN trial (John) Notes from Dec 2024 NAAN meeting
jk: have been working for a few months now, experimenting with bulk updates for LA Referencia; we reserve for them a block of N candidate NAANs, and they send us back N correctly formatted NAAN records
ab: at ROR we ask people to give us bulk assignments via a CSV file
bm: a CSV file sounds easier all around; I could supply a template form
ab: we could give people a template form to download
jk: that would save us the extra step of reserving candidate NAANs in advance and save them from having to get all the formatting correct
ACTION: bm and ab will supply example templates
jm: would the spreadsheet come in to the group? or to the primary curator?
ab: on duty curators could review incoming spreadsheets
jk: we could start conservative via known representative individuals, eg, LA Referencia
ab: that's exactly what we do with RORs, and we don't pre-populate sheets with candidate naans
jk: that saves a pre-assignment step
-
jk: bulk registration in very experimental stage
-
dw: what is the use case?
-
jk: service provider with hundreds of clients instead of a handful (eg, LA Referencia)
-
dv: should bulk uploads create GH issues? is there a limit to the size of bulk upload?
-
jk: good question; we have many unaddressed policy and workflow tracking issues; we do want whoever is submitting a batch to be a full-fledged and trained NAAN curator
-
rm: limits are a good idea; we have limits to uploads of individual ARKs
-
dv: conceivable to do registry updates with a simple GH pull request
-
BnF ARK resolver status (none)
-
dv: NAAN request form processing on hold while dealing with a backlog of documentation updates; chipping away at n2t usage stats
-
dv: any idea how ARK infrastructure is perceived outside the US?
-
rm: it really helps that the ARK Alliance exists
-
rm: n2t converts modern to classic (ark: -> ark:/)
-
dv: that's actually configurable via the registry
-
rm: we still want our local resolver to do both
| Item | Owner |
|---|---|
| New spec with .well-known (discussed 2023.05.09 and 2024.11.12) | John |
- https://datatracker.ietf.org/doc/draft-kunze-ark/
- diffs here
- no news yet from RFC Editor, trying to set up discussion with Mark Nottingham
| Item | Owner |
|---|---|
| proposed stakeholder sign off approving new form ARKs (ark: vs ark:/) | all |
Problem: All the ARKA website documentation uses classic (old) form ARKs, but for years the spec has been using the modern form. Many brand new implementations are publishing the old form. To reduce confusion and reconcile this inconsistency, how about we ask priority stakeholders to agree with the reconciliation?
Unless your implementation accepts ARKs in both classic form (ark:/12345/...) and modern form (ark:12345/...), your published ARKs may be at risk of appearing to break. In other words, just because you publish ARKs in one form, doesn't mean you're not at risk for them coming back to you in the other form. Out in the wild, well-meaning aggregators and normalizers may flip your ARKs from classic (ark:/) to modern (ark:), or vice-versa, before other users attempt access with them. (We should ask normalizers to leave modern modern and classic classic.)
The ARK Alliance proposes to begin converting its documentation in July 2025 (a) to use the modern (ark:NAAN) form and (b) to recommend that implementations publish ARKs in the modern form. As usual, ARKA will continue to strongly recommend that implementors resolve both classic and modern ARK forms in perpetuity.
We ask you, as an ARK stakeholder, to please indicate that you understand the risk and accept this upcoming change in the documentation published by ARKA.
| When | Stakeholder | Contact | local/global | Notes |
|---|---|---|---|---|
| 2018 | N2T.net | Dave V | NA/yes | |
| 2024 | ?FamilySearch.org | Randy W | yes/yes | ?top-level resolver handles both, will adapt other resolvers as needed |
| 2024 | ?Portico | Karen H | ?no/yes | ?handles few public ARKs |
| 2024 | ?BnF | Bertand C | ?yes/yes | |
| 2024 | ?WACREN | Omo O | yes/yes | |
| 2024 | ?LA Referencia | Lautaro M | yes/yes | |
| 2024 | ?Smithsonian | Rebecca Snyder? | ?yes/yes |
We don't necessarily expect every resolver to accept both forms (the ideal), but we would like to know if (a) they want more time to make their changes before we update our documentation and (b) if they understand and accept the risks if they only accept one form.
Questions:
- What other major stakeholders should we prioritize?
- Should we email a simple form to all contacts in the NAAN registry?
- How many responses is enough stakeholders before we can we go ahead and modernize our documentation?
- problem explained, no real time for discussion; to be continued
| Item | Owner |
|---|---|
| shall we tweak the ARK spec to observe '.' variants mainly/only in the last path segment? | all |
Based on this arks-forum thread, some platforms (eg, github) could much more easily do ARK variants if they variants (indicated by '.') only needed to be observed in the final path segment instead of in earlier path segments. Although the variant rule has been in place for over 20 years, should we consider a small change to make it easier?
- jk: please think about this for a future meeting
- dv: would be awesome for ARKs to be as liberal as possible about reserved chars, including hyphens
https://github.com/arks-org/arks.github.io/wiki/2025-01-21-Technical-WG-Agenda-and-Notes
08:10:04 From Roxana Maurer (NLibLux) to Everyone:
https://persist.lu/ark:72849/952fvb4fq0
08:10:27 From Donny to Everyone:
Cool! https://persist.lu/resolve/ark:72849/952fvb4fq0
08:10:29 From Roxana Maurer (NLibLux) to Everyone:
ark:70795/30xgzdkd03
08:13:30 From Curtis Mirci to Everyone:
Not sure why my format is always invalid.
08:13:36 From Donny to Everyone:
Looks like the redirection metadata at n2t.net (arks.org?) needs updating: https://n2t.net/ark:72849/952fvb4fq0 ?
08:21:04 From Curtis Mirci to Everyone:
Replying to "Looks like the redir..."
https://toi.lib.utah.edu/ ark:72849/952fvb4fq0
08:21:36 From Donny to Everyone:
https://toi.lib.utah.edu/ark:72849/952fvb4fq0 404 not found for me…
08:22:18 From Donny to Everyone:
Replying to "https://toi.lib.utah..."
Ah!
08:23:28 From Donny to Everyone:
Replying to "https://toi.lib.utah..."
The N2T link given though is “n2t.info”? https://n2t.info/ark%3A72849%2F952fvb4fq0 404s
08:24:30 From Donny to Everyone:
Replying to "https://toi.lib.utah..."
(Oh, it 404s at collections.mnaha.lu, sorry.)
08:26:03 From John Kunze to Everyone:
Replying to "https://toi.lib.utah..."
Hmm. n2t.info may still work, but it should be n2t.net
08:28:32 From Donny to Everyone:
Anyone using https://www.countermetrics.org/code-of-practice/ for usage statistics, e.g. how InvenioRDM (and therefore Zenodo?) claims to? https://inveniordm.docs.cern.ch/reference/statistics/
08:29:55 From Roxana Maurer (NLibLux) to Everyone:
Replying to "Anyone using https:/..."
No
08:38:24 From Donny to Everyone:
Perhaps require a tracking issue for each bulk-upload request? So one issue maps to “one” “request”?
08:52:21 From Roxana Maurer (NLibLux) to Everyone:
https://digipres.club/@BertrandCaron/113764628483760812
08:52:41 From Karen Hanson (she/her) to Everyone:
Reacted to "https://digipres.clu..." with 👍
08:52:57 From Donny to Everyone:
Reacted to "https://digipres.clu..." with 👍
08:56:10 From Roxana Maurer (NLibLux) to Everyone:
https://n2t.net/ark:70795/30xgzdkd03
09:01:09 From Donny to Everyone:
“In form, the Qualifier is a ComponentPath, or a VariantPath, or a ComponentPath followed by a VariantPath. A VariantPath is introduced and subdivided by the reserved character '.', and a ComponentPath is introduced and subdivided by the reserved character ‘/‘.”
09:01:23 From Donny to Everyone:
From https://www.ietf.org/archive/id/draft-kunze-ark-40.html . So…already done?
- rm, dv, cm to draft proposed common json format as possible best practice