TC: having ability to forward shoulders under one NAAN is much better than using multiple NAANs; also a convention to support temp ARKs may work better than configuration requirement RM: could make organizational shoulders that look like the organizational NAANs, so by convention you don't collide, which avoids need to register JR: for INCIPIT project we want test ARKs w.o. using our own NAAN JK: maybe accommodate both BC: BNF could probably use this KH: should shoulders be a temporary shoulder registration? JK: that wouldn't work for, say EZID; ironically, there's a long-term need for temporary ARKs, eg, whenever you install a bug fix we mint a fake ARK as a basic test to see if things are working
Meeting frequency and preparation
JK: ok to reduce meeting frequency to once a month? All: ok, canceling first Monday meeting
Consolidation of recent concept exploration around X?info
Revisit basic requirements
return basic information about X
return a persistence statement
don't depart too far from original ARK spec
retain ability to add optional richer metadata
retain ability to use other formats
retain spirit of ERC/ANVL/THUMP and Dublin Kernel "story" metadata
Concept that X can refer to a landing page, and what that means for X?info
Concept that X can refer to a plunging (non-landing) page, and what that means
Concept that resolution may in general involve multiple resolvers, any of which might be tasked to respond to X?info (tradeoffs)
Unknown: can/should we support notion of X referring to one or more of these (avoiding the more challenging terminology of the Networked Entity Model):
bp (born physical) thing
bd (born digital) thing
bc (born conceptual, eg, vocabulary term) thing
dfp (digital from physical, eg, scanned document)
dfd (digital from digital, eg, lower res surrogate from master image)
pfp (physical from physical, eg, photographic print of painting)
pfd (physical from digital, eg, German wikipedia is printed and bound annually)
JK: (summarize agenda item) MP: dfd -- when do we know that? MP: important to know why are there so few implementers of some areas JK: yes, eg, ? and ?? hard to recognize, leading to change to use ?info
RM: some of this is apropos Mario's email about landing page vs resource KH: also, for the rmap project, the :/ after ark caused problems; even though the "/" is now deprecated, the ":" by itself still causes a few problems MP: technical challenges implementing certain things create cost/benefit tradeoff that may not be worth it JK: other things we're doing to make the cost lower is to change recommendation from ANVL to YAML/JSON
JK: Also, we could use a place holder to indicate the count below in the namespace created by the ARK, (a kind of enumeration point, as Smithsonian uses it); this could actually be considered a piece of the counting ARKs project
Action items
John Kunze will cancel first Monday of month meeting series
John Kunze will talk to Outreach WG about contacting U. Amsterdam