2026 07 14 Technical WG Agenda and Notes

Attendees

Goals

• shoulders and NAANs; 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

• Complete: May 7 Community Call note
• Recent: COAR conference talk
• Upcoming workshop: SPNHC (Society for the Preservation of Naturual History Collections)

Item	Owner
NAAN extensions revisited: a response to requests for ARK metadata

• Many identifier schemes specialize in one kind of data, and they can afford to commit to one kind of metadata
• ARKs are inherently cross-domain, so metadata has to be cross-domain, eg, Dublin Core or Dublin Kernel (who, what, when)
  • Even so, cross-domain metadata is a difficult to prescribe
• Stepping back from metadata, is there any way at all to let providers convey meaning in another way?
  • Traditionally, embedding meaning inside the id string (still no metadata) as gone very wrong, creating very unstable ids
  • But that doesn't mean that there are no ways to convey meaning inside a stable id string
• Hypothesis: carefully constrained NAAN semantic extensions can support stable ARKs that meet some of the longstanding demand for ARK metadata
  • We have already done this for years. In the constrained 5-digit NAAN world, we did this by reserving 4 semantic NAANs (99152, 99166, 99999, 12345).
  • Providers request an exclusive shoulder under these shared NAANs. What they get is functionally a NAAN, but extended by a few characters.
  • This is long, ugly, requires separate registration and maintenance, and obfuscates the provenance of individual ARK ids.
  • Can we evolve the current semantics-in-ARK-strings functionality into something clearer and cleaner?

With modern ARKs, we have new freedom with NAANs. This is proposal to extend NAANs and simplify common shoulder creation.

 https://docs.google.com/document/d/1JEiGDEuLUx2iJ8dXDCWKlYX6SqieN79i2Y9EgOGW6Ww/edit?tab=t.0

Discussion from May 2026:

• 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
replica requirements; create recipe/scripts to make setting up a replica simple

Zoom chat

Old action items

• convert ARK URI registration to modern ARKs -- turns out not to need conversion (still needs new document owner)