Page History

Announcements

• Arkspec.md
• DeSci.com

dv: tried converting the ARK spec to markdown format suitable for IETF publication; if this works it can be a much easier way to manage the text than the XML format
ACTION: jk and dv to meet to do the conversion to new spec

jk: The DeSci.com folks are quite interested in ARKs as a citation friendly (shortish), possibly mutable objects that reference parts of IPFS and IPNS; interested in endorsing ARKA
all: general agreement that we're interested in desci's explorations in this area and about keeping up awareness
rm: I'd support mentioning them on the website
ACTION: jk: I'll ask them to fill out the expression of interest form, which we already have procedures for

k: should move
k: brings in dockerhub to suite of ARKA accounts
ACTION: move arknoid to arks-org repo, and away from jakkbl dockerhub

r: here's an example of our persistence statement
https://persist.lu/ark:70795/m4bk6v?info

jk: CNI panel proposal (for December 12-13) was submitted

persistence descriptors

• Upcoming meeting with FamilySearch

jk: will meet with FamilySearch; please speak up if you're interested in joining

rm: BnL (National Library of Luxembourg) uses these terms

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"
}

d: N2T resolver challenges around classic inflections
   hope to be finished by end of year
g: distributed with failover?
d: yes, definitely, possibly a large number of resolvers

g: minter state still seems fragile given that containers disappear
d: docker-compose with volume spec and env variable

d: also noidy tool https://github.com/datadavev/noidy

New resolver update from Dave V:

• The N2T resolver replacement is being implemented using the Python FastAPI asynchronous web service framework. Goals of the implementation include minimal resource requirements, maintainable codebase, multiple parallel deployment support, emphasis on API access, and compliance with applicable specifications.

  The purposes of the implementation include:

  • Determine the applicable resolver service given an identifier or portion thereof.
  • Provide information about the resolver(s) available for a given identifier.
  • Periodically evaluate the operation of advertised resolver services.

  Challenges that need to be addressed include dealing with the ARK inflection requests and concocting a resolver service metadata spec.

• For example, a double “?” (“??”) can be reliably passed through to the web application, appearing as a single “?” since technically the second “?” is the query string. However a single “?” may be consumed at the client, the proxy, the load balancer, the web server, the web server application environment, or the web application framework with no hint to the web application since any of those components may perform some url normalization that removes the single “?” since it is a no-op under HTTP.

d: N2T resolver challenges around classic inflections
   hope to be finished by end of year
g: distributed with failover?
d: yes, definitely, possibly a large number of resolvers

g: minter state still seems fragile given that containers disappear
d: docker-compose with volume spec and env variable

d: also noidy tool https://github.com/datadavev/noidy

docker minting tool update:

SYNOPSIS                          (./arknoid)
    arknoid - tool to mint ARK (Archival Resource Key) identifiers

USAGE
    arknoid [options] init
    arknoid [options] mkminter [ NAAN[/Shoulder] ]
    arknoid [options] mint [ Count [ FQShoulder ] ]
    arknoid [options] testmint [ Count ]
    arknoid [options] lsminter [ FQShoulder ... ]
    arknoid [options] rmminter FQShoulder ...
    arknoid [options] test
    arknoid [ help ]

DESCRIPTION
    This script is used to mint globally unique, opaque, random-looking ARK
    (Archival Resource Key) identifiers. Here, "to mint" means to generate a
    string of letters and digits suitable for use as an ARK. To create an ARK
    is to publicize your assignment of a minted string to a thing (eg, for
    reference purposes). The less that you publicize your ARK assignment, the
    easier it is to "undo" the act of ARK creation.

    To ensure ARK global uniqueness, the ARK namespace is divided into NAANs
    (Name Assigning Authority Numbers). NAANs are further (sub)divided into
    Shoulders, which are useful for delegating responsibility within NAAN
    namespaces.

    To run this script you will need a NAAN that will appear at the beginning
    of your ARKs. You may request a NAAN for your organization using the link

        https://n2t.net/e/naan_request

    Use the "init" command to initialize the system with the NAAN reserved
    for you (usually a 5-digit number), or with the test NAAN, 99999.

    The "mkminter" command creates a minter of unique opaque strings consisting
    of digits, letters (betanumerics actually) and a final check character.
    With no arugment, it creates a random shoulder using your NAAN, but you may
    also specify a fully qualified shoulder of your choice. A Shoulder string
    must start with one or more betanumeric letters (bcdfghjkmnpqrstvwxz) and end in
    a digit. The NAAN should be one that you have been assigned (eg, 12345) via
    the global ARK NAAN registry. Each minter created with this command can
    generate 70,728,100 unique ARKs.

    The "mint" command generates Count (default 1) strings suitable for ARK
    assignments from the "fully qualified" minter name, FQShoulder, which
    consists of the NAAN, a '/', and the Shoulder string. The "testmint"
    command generates ARKs beginning with 99999, which recipients understand
    to be impersistent, untrustworthy, and for test purposes only.

    As an example, these commands create a minter, then use the minter to
    generate one ARK, and then again to generate 2000 ARKs.

        $ arknoid mkminter 98765 z4
    $ arknoid mint 1 98765/z4
    $ arknoid mint 2000 98765/z4

    Use the "lsminter" command with FQShoulder arguments to check for the
    existence of one or more minters, or use it with no arguments to list all
    minters available to you. Use the "rmminter" command to remove minters.
    The "test" command verifies whether the software is correctly installed
    and the "help" command (the default command) outputs documentation.

    Most commands exit with zero status on success and non-zero on error.
    It is possible to run init on more than one NAAN. This script relies on
    the Noid (v0.424) software.

OPTIONS
    -f force run even if not inside a docker container
    -e enter container if not already inside a container (xxx unused)
    -c on init, clear out any previous NAAN data

FILES
    ./minters/ark/<NAAN>/<Shoulder>