2022-12-13 Technical WG Agenda and Notes

jk: everyone please have a look at the end of year wrapup blog post before it goes out later today
dw: NASA proposal with rolling deadline (due 2023-03-29): NNH22ZDA001N-HPOSS (https://nspires.nasaprs.com/external/solicitations/summary.do?solId=%7bB364DBB8-390B-744D-013F-8F4C304B9A63%7d&path=&method=init). "proposals that would advance and streamline the open sharing of scientific information...supports the development of innovative open-source tools, software, frameworks, data formats, and libraries that will have a significant impact to the...science community". "expected to support...3-5 projects for the call. The awards will be for a duration of one year and a typical size of ~$100,000 per award."

CNI pre-recorded briefing on ARKs accepted, speakers jk, dv, and Tim Clark

Any news items we should blog about?

• Final comments on end of year wrapup draft blog post?

Should we point to presentations by Bertrand's and Donny's talks
dw: one topic could be to recommend tagging your github repo with "arks" label (not "ark"): https://github.com/topics/arks
rm: could blog that we are looking for people interested in working on persistence statements and about best practices and use cases using ARKs with IIIF

What should be the scope of the ARKA Persistence Statements subgroup?

• Rob Lyon, Roxana Maurer, Kirsta Stapelfeldt, Greg Janee, Dave Vieglais, Donny Winston

Do p. statements apply to the object only, or to the organization, or to a record of the past (even if the digital artifacts change)?
dv: it would be good to start with a scoping statement
dw: "persistence of identification" -> "nonReassignment" property? so the base ark variance is "rising", but you'd like to specify "frozen" for a ".pdf" variant of the base ark name? (also a fully-qualified ark name?). am I getting that right?
tc: As Roxanne is saying, any digital preservation system must anticipate format migration.
dw: so "frozen" would be an unacceptable content variance assertion for a "base ark" (non-variant); this makes sense to me.
tc: Yes. ‘frozen’ is antithetical to current thinking in digital preservation
jk: for better or worse, there are many people who believe that "frozen" is (or will be) a common use case
tc: It’s not that a bitstream can’t be maintained in a preservation system, but the general thinking is that bitstreams must be changed over time in order to provide viable access through time. An archivist once told me that “digital preservation is an oxymoron.”
gj: Might be worthwhile to separate/distinguish the essential intellectual content vs the packaging by which it is delivered
dw: storage-->processing-->interface for presenting a digital object.
tc: Part of the issue is that we are not clear on the ‘user’ the audience. What is the interest of the user? If one of our online patrons wants to retrieve an image of a birth record, he/she likely wants a nice presentation of that document. but one of our industry partners might want the image itself, the archivist who owns the original document might want the highest quality of the image. This is basically what Dave is saying.
dw: conventional http content negotiation, but also perhaps "connegp" (i.e. "by Profile") (https://w3c.github.io/dx-connegp/connegp/); would "redirection" be in scope for persistence statements? e.g. "this other org has asserted that they will persist this object in some way"

From last time, Roxana's implementation:

persistence: { // Persistence statements: https://datascience.codata.org/articles/10.5334/dsj-2017-039/    

        contentVariance: {  // how an object’s content will change over time

            type: String,

            enum: [

                "frozen",   // The bit stream representing previously recorded content will not change.

                "keeping",  // Previously recorded content will not change, but character, compression, and markup encodings may change during a format migration, and high-priority security concerns will be acted upon (e.g., software virus decontamination, security patching).

                "fixing",   // Previously recorded content may be corrected at any time, in addition to any change under “keeping”.

                "rising",   // Previously recorded content may be improved at any time, for example, with better metadata (datasets), new features (software), or new insights (pre- and post-prints). This encompasses any change under “fixing”.

                "molting",  // Previously recorded content may be entirely overwritten at any time with content that preserves thematic continuity (homepages).

                "waxing"    // Change that is limited to appending content in a way that does not in itself disrupt or displace previously recorded content. Examples of waxing objects include live sensor-based data feeds, citation databases, and serial publications.

            ]

        },

        objectAvailability: {   // the period of time during which the provider expects to keep the object available

            type: String,

            enum: [

                "finite",   // Availability is expected to end on or around a given date (e.g., limited support for software versions not marked “long term stable”) or trigger event (e.g., single-use link).

                "indefinite",   // The provider has no particular commitment to the object.

                "lifetime", // The object is expected to be available as long as the provider exists.

                "subinfinite"   // Due to succession arrangements, the object is expected to be available beyond the provider organization’s lifetime.

            ]

        },

        nonReassignment: {  // (NR) Once assigned and made public, the identifier will not be reassigned.

            type: Boolean

BnL example: https://persist.lu/ark:70795/m4bk6v?info returns

{
  "persistence": {
    "objectAvailability": "lifetime",
    "objectContentChange": {
      "contentVariance": "rising",
      "contentGrowthOverTime": false
    },
    "arkNonReassignment": true,
    "arkOpacity": true,
    "arkCheckCharacter": true
  },
  "erc": {
    "what": "Diekircher Wochenblatt",
    "when": "1841-01-23",
    "type": "Newspaper (digitized)",
    "format": "METS/ALTO"
  },
  "status": "public",
  "owner": "Bibliothèque nationale du Luxembourg (=) National Library of Luxembourg (=) BnL",
  "target": "https://viewer.eluxemburgensia.lu/ark:70795/m4bk6v",
  "updated": "2020-06-16T07:06:41.575Z"
}

What should be the scope of the ARKA IIIF subgroup?

• Julien Raemy, Dave Vieglais, Kyle and Nat (UTSC), 

Right now we're looking at best practices for those considering using ARKs and IIIF

dw: https://gallica.bnf.fr/iiif/ark:/12148/btv1b8449691v/f29/2131,4016,1467,948/full/0/default.jpg 
        (from https://arks.org/blog/images-and-the-promise-of-arks-with-iiif/, this link resolves)