2025 02 11 Technical WG Agenda and Notes

Attendees

• Karen Hanson, Curtis Mirci, Randy Wilson, John Kunze

Goals

• arks.org and google site search, modern vs classic ARKs, .suffixes

Discussion items

Item	Owner
Announcements	all

• ARKs for Wordpress sites? (similar to ARKs for Github Pages sites)
• Africa PID Alliance (APA) endorsement

Item	Owner
proposed default ARK metadata schema to match DataCite?	all

• kh: maybe default, but optional
• cm: every time the schema changes, it creates lots of work; but the schema has lots going for it; the genie is out of the bottle, eg, we already committed to Dublin Core for many ARKs
• jk: no suggestion that this would affect older implementers; maybe we can use datacite indirectly
• cm: one flavor of datacite, but there's talk at Utah about using ARKs with DataCite
• jk: how to keep costs reasonable?
• cm: on your own system you can declare that we're only at VN instead of VN+1
• rw: who is the audience, eg, google, and who would have a problem with version incompatibility; we could use a way to interop with FS and, say, Ancestry
• jk: maybe a genealogy profile?
• rw: i tried to come up with a common generic gen. model
  • very hard to get people to change
  • easy if they're just coming in
• cm: many of my ARK users would not want DOIs because of lack of flexibility
• rw: ARK are so important for what we do is we lots of sources of data and we give each person an ARKs, and the sources help us troubleshoot controversy and disputes (so we need unbreakable links to sources), and we can slowly convert things to ARKs

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

• rm, dv, cm to draft proposed common json format as possible best practice
• Bertrand Caron reports that ark.bnf.fr resolver should be good with https (ok to revert homepage image link)

Item	Owner
.suffixes follow up	John

• we didn't get very far with this, but did note that v2.0.13 is likely a poor way to construct an ARK path

From previous meeting intro:

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?

From the discussion thread:

   There is an obvious syntactic problem, however: Both the release tags and
   the file names often contain periods. If I understand the the ARK scheme
   correctly, though a Name Mapping Authority is free to publish their arks
   with qualifiers or not, a period anywhere after the "ark:" part *must*
   indicate an object variant (I'm reading the 2023 draft here). That is
   clearly not the case in my example above: "v2.0.13" is one single tag, not
   a variant of a variant. Likewise with the filename at the end: There is no
   "/gitplugin" object of which "/gitplugin.go" is a variant.

This is a good question, and it highlights several issues. PID schemes make
tradeoffs to try to be usable today and in the future. In order to be
compatible with current internet (ie, web) practice, ARKs tried to align with
common conventions around periods near the ends of URLs (eg, .pdf), but to keep
parsing rules simple and to accommodate providers who prefer to organize some
variation (eg, language: .en, .fr, .es) earlier in the path, periods would be
treated the same way anywhere they appeared in the ARK, for example, in
non-suffix positions such as

ark:/12345/x54b92/foo.en/bar.pdf
ark:/12345/x54b92/foo.fr/bar.pdf
ark:/12345/x54b92/foo.de/bar.pdf

OTOH, we never actually heard demand for the non-suffix position (it doesn't
mean there's not latent demand). nd the ARK spec has avoided using examples of
periods in non-suffix positions in order to make it a little easier if
implementation experience suggests that the rule should be changed (so that
periods have special meaning only in the final path component).

What if that change were proposed to and approved by the Technical working
group? First, it would take care of the "v2.0.13" in
n2t.net/ark:/15737/p654p8z5cgjv/v2.0.13/pkg/ark/git/gitplugin.go. As for the
"/gitplugin.go" implying the existence of a "/gitplugin" object, the latter
(with no .suffix part, and even if there's no such file) would plausibly be
mapped to the default variant (or the only variant), namely, the go-lang source
file.

• Current spec doesn't look quite right; final step of normalization too harsh?

     8.  Structural characters (slash and period) are normalized: initial
         and final occurrences are removed, and two structural characters
         in a row (e.g., // or ./) are replaced by the first character,
         iterating until each occurrence has at least one non-structural
         character on either side.

     9.  If there are any components with a period on the left and a slash
         on the right, either the component and the preceding period must
         be moved to the end of the Name part or the ARK must be thrown
         out as malformed.

Item	Owner
google site search of arks.org	John

• whereas site search via bing.com and duckduckgo.com do ok with, eg, "factor site:arks.org", it's useless to search for ARK documentation via google.com
• how to restore site search via google?
• didn't have time to discuss

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?

Idea: announce on ark-forum, and send each NAAN record contact an email, inviting them to "click if they agree"

Dear ARK stakeholder,

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:

1. What other major stakeholders should we prioritize?
2. Should we email a simple form to all contacts in the NAAN registry?
3. How many responses is enough stakeholders before we can we go ahead and modernize our documentation?

• discussion among kh, rw, and jk continues via proposed letter of consent

Item	Owner
implementation ARK testing options	all

didn't get to this

Zoom chat

New action items