Skip to content

2026 05 12 Technical WG Agenda and Notes

Jump to bottom
John A. Kunze edited this page Jun 4, 2026 · 7 revisions

Attendees

  • Roxana, Julien, Curtis, Karen, Randy, John K

Goals

  • shoulder creation and maintenance; replication

Discussion items

Item Owner
Announcements? 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

Discussion

  • jk: I'm speaking at the COAR conference in a few weeks; any feedback from those attending the community call?
  • jr, rm: the community call was good
  • rm: I'd be willing to do talk at next call
Item Owner
clarifying N2A (n2t.net+arks.org) shoulder request
  • At last meeting, approved spending time to advise the NAAN WG on shoulder issues
  • Old shoulder form defunct; how do users request shoulders
    • under shared NAAN
    • under their own NAAN?
    • backing out to first principles, are shared NAANs the way forward today given new flexibility of NAAN?
  • Draft shoulder creation procedure:

Create a new testing shoulder, in this case ark:99999/mk0, by copying an existing shoulder file. This can be done purely through the Github UI, but in a Unix shell with a recently updated fork of the repo, the steps look like

 cp naan_records/9/99999_fk4.json naan_records/9/99999_mk0.json

editing the copy to match the requester's information, and then committing the change. Finally, use git pull to update the local repo, then push the new record back to the main repo. Finally, on Github, run the workflow build_public_gh_pages, wait for an hour, and test that it works. For example, the shell command

curl -IL https://n2t.net/ark:99999/mk0foobar

should redirect to the configured target with the "foobar" suffix. Alternately, you can test that URL in a browser.

  • evolving still; need to create UI (not just CLI) version
  • kh, rm: we're not currently using shoulders internally
Item Owner
Idea: NAAN extensions

Discussion

  • cm: are there good definitions of these object types?
  • rw: events as concepts? we do persons, birth records, images, in JEDCOMX we have resource description (person, record, artifact)? we have prefixes (like shoulders, eg, 1....); we wouldn't need these terminal letters
  • jk: would you want other letters for durable categories?
  • rw: asking an ARK for its for its metadata seems like a good place to expect to learn the semantics; there's a tradeoff
  • jk: exactly; tradeoff question: can we optimize for a tiny group of semantics that are durable?
  • kh: why did we have reserved NAANs for conveying semantics?
  • jk: originally the NAAN was the only hammer we had, short of prescribing a particular metadata set on everyone
  • kh: the new approach seems more natural and reasonable, esp for linked data
  • cm: is there much call for this?
  • jk: yes, pressure to add semantics, and we want to relieve some of that pressure by allowing them some latitude
  • rw: not a breaking change; but a general concern is that the more complex it becomes we more difficult for users to adopt and to change
  • jk: without a "terminal" letter, recipient won't know what's there unless (a) they do a metadata request and (b) get metadata that they understand; the second part pre-supposes that we first agree on a standardized metadata format (which is a huge obstacle); the convenience of imparting limited semantics inside the ARK string itself could be very powerful, provided we carefully avoid the classic pitfalls, namely, only allos the most durable semantics
  • kh: do users already do shoulders like this?
  • jk: yes, but the current setup for conveying these semantics are hard to explain and requires ARK orgs to establish and remember a separate identity (shoulder under shared NAAN)
  • jk: also hard for ARK recipients to learn and track the assigning organization, requiring them to remember and that org X assigns ARKs under several different NAANs and lexically unrelated shoulders; in the new proposal, all semantics would be conveyed by one NAAN that optionally ends in a letter, and it would discourage people from adding non-durable semantics in their id strings
  • rw: it would help me to know that there are real users who want this
  • jr: I like the idea but I wonder if we should rather have a separate list (NAAN disjoint namespace extension) so we could describe what c, x or whatever namespace means and easily extend the list. Perhaps this is also something ARK assigners could manage themselves and decide if they want to deploy or not. Because the current shared-NAAN shoulders could also be used.
Item Owner
Zulip public rollout
  • what does that look like?
  • code of conduct violations?
  • risk of requests for support going unanswered
Item Owner
replica requirements; create recipe/scripts to make setting up a replica simple
  • no time for this topic

Zoom chat

Old action items

  • convert ARK URI registration to modern ARKs

GH Wiki Tips | ARKA Calendar | WG Background | ARK Alliance | N2T.net

Clone this wiki locally