2022-05-10 Technical WG Agenda and Notes

m: texas conference on digital libraries, with emphasis on pids, arks, what choices, use cases
j: any links to recorded talks? would be great to save them

m: I will add link in calendar entry on texas conf

ARK spec transition plan; what can we learn from the Outreach discussion?

Below are notes from the last Outreach WG meeting.

We've blogged about the upcoming change in the recommended form of newly published ARKs (starting on STARTDATE) – from ark:/12345 (oldform) to ark:12345 (newform)

• what is STARTDATE? how do we determine what STARTDATE is?
• when do we change documentation on the website and wikipedia?
• recall that all sites producing newform ARKs must also serve all their ARKs in newform or oldform, regardless of production date, eg, 2025
• at CUTOVERDATE, all sites should serve all their ARKs in either newform or oldform, regardless of production date, eg, 2006

Discussion notes on the above strawman (rf=Ricc Ferrante, mg=Maria Gould, jk=John Kunze):

rf: confused about CUTOVERDATES; does this mean we have to start normalizing to newform ARKs? do we leave old ARKs in oldform in our system?
jk: nothing is intended to tell implementers about changing or normalizing internal representation of ARKs (eg, oldform or newform); we should make this clear and find language that is clear and minimizes stress
rf: could we put out some use cases so that people can see what this change means in the real world?
mg: yes, what are the implications for (a) our dev team and (b) our users;
mg: also, is it up to the ARKA to decide? or do we need a focus group?
rf: I like the idea of a focus group because it engages people and helps keep the community alive, but I have no energy for it
jk: could use more Outreach members
rf: I will float the idea out there for new wg members; Tom Creighton might be a good focus group wrangler

J Introduced strawman and discussion from the previous Outreach WG meeting. Some questions:

Are there non-backward compatible changes? no
Does this mean we have to change our previously published ARKs? no

j: is a focus group the right thing? if so, do we want formal or informal?
t: prefer less formal focus group
j: how big a group, how to populate?
t: would we want to add the topic of how people might approach pids in general? could be useful in recruiting new ARK users
j: I have some concern about scope being too wide
g: not sure I understand; is the focus group designed for how users should address spec changes?
j: its to help understand whether our messaging around the transition (when we figure out what the messaging is) is clear and feasible
t: I think Outreach WG should have a big part in setting this group up
j: since there no breaking changes, how big a deal does this need to be?
k: where a focus group might help is in breaking down use cases, eg, Portico cannot remove the forward '/' in all the places they're stored without incredible cost
m: i like the idea of laying out how institutions A, B, C, etc. will have different approaches to implementing this; eg, "if you're just starting out, do X"; anything we can do to give people a pathway to go forward will be useful
g: if there will always be oldform ARKs, then everyone needs to be aware of it; then there's the question from deprecation; the term "cutover" is misleading
t: I don't get: "recall that all sites producing newform ARKs must also serve all their ARKs in newform or oldform, regardless of production date"
j: it's just that you may see you own (originally) oldform ARKs sent back to you in newform, or vice-versa
t: ok, so basically our goal is to help people to not experience breakage of ARKs
g: so "here's an ARK (newform), and if you see the legacy oldform (even of your own stuff), honor it"
k: i like greg's language; so much easier to update how you accept (resolve) and display; vs storage
t: let's not use the word "cutover", but "by date X, expect to see references in the wild both forms"
ACTION: Karen will start a use case doc
ACTION: All will add use cases to it

Some ARK spec publication options

• IETF (with obstacles, eg, URI or non-URI?)
• W3C
• neither