2022-11-08 Technical WG Agenda and Notes

jk: experimenting with beta ARKA stickers – anyone know of a business that accept sticker orders from users and mail directly to them? I've heard of shopify.com but didn't see the right fit.
dw: redbubble.com may work like shopify
tc: stickers, is shipping more important than printing?
jk: to me, yes
kh: This is what we use, not sure how it works: https://www.makestickers.com/

Calls for papers, submission deadlines, upcoming meetings: Calendar of events

2023 Code4Lib pre-conference

From Hardy Pottinger
Subject: Call for Proposals - 2023 Code4Lib Pre-Conference

We are now accepting pre-conference proposals for the 2023 Code4Lib conference at Princeton University in Princeton, New Jersey. These pre-conferences can either be a 1-day (six hour) or a 1/2-day session (three hour) and will occur on Tuesday, March 14th. These workshops are required to be In-Person ONLY.

Code4Lib 2023 is a loosely-structured conference that provides people working at the intersection of libraries/archives/museums/cultural heritage and technology with a chance to share ideas, be inspired, and forge collaborations. For more information about the Code4Lib community, please visit https://code4lib.org/about/.

The pre-conference sessions give folks a space to share and build knowledge, as well as to teach attendees new skills relevant to library technology. Pre-conference sessions can range from workshops to working sessions.

To propose a session, please go to the 2023 submission form. If you're looking for inspiration, there are many great examples of pre-conferences from recent years: 

 https://2022.code4lib.org/workshops/,
 https://2021.code4lib.org/workshops/,
 https://2020.code4lib.org/workshops/,
 https://2019.code4lib.org/workshops/.

We are taking proposals until November 30, 2022, 5 PM PST / 8 PM EST. After a period of public voting on workshops, we hope to confirm sessions with the facilitators shortly after. 

If you have any questions, please do not hesitate to email us - by responding to this email or by contacting Code4Lib.Workshops@gmail.com.

Best,

Code4Lib 2023 Pre-conference Committee

ARK panel turned down for CNI briefings, but it was suggested to resubmit as a CNI pre-recorded briefing

dw: I would be interested in developing a half-day workshop; I've worked with the carpentries, and its not too much of a stretch for me

dv: I have some open source ARK code that might be useful to present in a code4lib venue

blog posts?

draft new ARKs-Service

dv: converted the ARK spec from XML to markdown
jk: seems to work fine with a next IETF draft publication process
dv: for user-contributed change request, suggest doing PR from a branch for changes to ark spec
all: agreed

IIIF connection made

While the spec recommends opacity in the base identifier, over time the spec has become more relaxed about semantics in extensions. In that vein, the IIIF API specifies certain characters (eg, ! and ^) in extensions in order to request variants of the base image object.

OTOH, like the ARK spec, the IIIF spec uses characters that should be encoded in URIs.

Interest in working with IIIF on this issue, or on PIDs in general?

mp: a nice thing about iiif is that there's another vendor that can do
    a transcription service that's seamless once you have a iiif API
    we had challenges wrt ARKs and iiif (6 years ago) image API

dw: it may be interesting to discuss tradeoffs of the use of slashes (/) to identify resource variants versus the ARK spec's discussion using periods (.) for variant delimiting vs having (/) be more geared to hierarchy. see e.g. the image API syntax: https://iiif.io/api/image/3.0/#21-image-request-uri-syntax (cf. what Mark is talking about)
image api url format: https://iiif.io/api/image/3.0/#21-image-request-uri-syntax
seems like full arks can be embedded in the {identifier} section of the image info request URI with URI Encoding: https://iiif.io/api/image/3.0/#3-identifier

dv: chars that look like others can be a problem; I'm keen to participate in IIIF

Code of Conduct draft – please review by Nov 18

Persistence statements status

subgroup: Rob Lyon (familysearch), Roxana Maurer, Kirsta Stapelfeldt (utsc) + who else

rm: very interested in persistence statements
gj: same here
dv: and here

docker-arknoid status