Date

Attendees

Goals

  • Brainstorming basic messaging

Discussion items

TimeItemWhoNotes
10AnnouncementsallJK: TS sent ARK/EZID requirements for repository vendor document to group list. Maria, John, Tracy were at CNI in St. Louis. JK attended DuraSpace summit. Connections made at summit: Cesar Olivares, Peru. 160 DSpace sites, interested in using ARKs. Noted: There’s currently no standard way to configure DSpace with ARKs. There is an EZID interface from DSpace for maintaining DOIs. KE and JK met with Erin Tripp and Laurie Arp about using the “It takes a village” approach to community building.
50

Some topics

  • We don't yet have a great statement of the "value proposition" as it applies to ARKs, or to the N2T.net resolver. This will need some interaction with the Sustainability WG and may need some discovery with the users survey.
  • Although we have reserved the arks.org domain name, we don't have a proper brochure site as a jumping off point for all things ARK.
  • There are lots of gaps in the documentation (eg, no FAQ). What are the priority documentation gaps to fill? There are things not written down yet, and things not yet known.
  • JK could try presenting the lightning talk and the group could (gently! :) tell me how it could be improved for re-use, or scrapped.
all

Discussion item: ARK Summit

Members of this group should be familiar with notes from previous ARK Summit Experts Day. There was interest at CNI/DuraSpace in having another ARK Summit.

SP: Should be in North America since the first was in Europe. Possibly in Canada; possibly Montreal.

MG: Should book now if in 2019, otherwise looking at 2020.

Discussion determines that a summit would best be planned in conjunction with an international conference that people may already have travel funding for. Barring that, we should make sure that it doesn’t conflict with related events.

Discussion item: Gaps in ARK documentation?

TS and MG note that we get questions about ARKs that we can’t readily answer. JK suggests that we should start our FAQ just with the questions, whether we have answers or not. The group also discussed best practices documentation. ARKs are flexible, so are people documenting their own use of them - for example, what is the object to which they assign ARKs? SP noted that there is different practice between his group and the librarians for this. He has documentation for his group’s best practices, eg, at what level of granularity should one assign ARKs, but it is in French. Other approaches discussed.

PC: For FAQ, what are the benefits of using ARKs? and how much work does it take?

KE: Flexibility can make it hard for people to engage initially – good to have an answer for what 10 things that ARKs do especially well? And a simple statement for the value proposition for ARKs

Discussion item: Survey

Suggestions: don’t try to learn everything we need to know from a single, long survey. We may need to learn things from different respondents at the same institution (technical/non-tech users). Consider piloting survey first within existing AITO participants, eg, we can ask big users, like FamilySearch and Portico as well, plus all AG and WG users. This would help us debug the survey and inform documentation gaps.

If we use surveys for all assessment, design so that the data will make sense across multiple surveys. Consider using a different form of assessment for learning more detail (interviews, focus groups). MG suggested asking respondents of the first survey if they would be willing to participate further. TS and SP noted challenges in the survey format: you can’t tell for certain that people are using language/jargon in the same way, and you don’t have a chance to ask clarifying questions. SP suggested focus groups. Multiple choice options may limit peoples’ responses; with a live conversation it’s easier to know what consensus is. JK noted Joan Starr’s “Buy a feature” approach to EZID assessment activities.

Discussion item: arks.org domain

This URL currently goes to the N2T resolver page. How to make this site more of a brochure site for ARKs? JK noted that when you Google ARKs, you get a wikipedia page, which doesn’t reflect well. Even before doing assessment with users, what can we do to improve that now? PC Suggestion: move the text that is at the top of http://arks.org/e/ark_ids.html to the arks.org home page. Even for people who aren’t using ARKs, if they see “ark:” in a URL, this will help them understand what they’re looking at.

Discussion item: video

SP: It would be good to have an introductory video to convey what ARKs are, why they’re useful. TS mentioned data-sharing video (sent to list). JK asked if others had good examples. KE: survey interview could ask for contributions of video production skills.

Action items

  • All: Activate your Confluence wiki account.
  • All: Look at calendars for appropriate meetings to co-locate with a second ARK Summit meeting, starting in 2020. Look for dates that don't compete for the same audience (eg, RDA) and be prepared to share ideas in future calls.
  • John Kunze Will start a confluence wiki page for questions to start the basis for an FAQ.
  • All: Add questions to the FAQ page when JK notifies us it’s ready.
  • John Kunze and Kurt Ewoldsen will draft small initial survey that draws from current survey.
  • Sébastien Peyrard  Share link with BnF best practices document and provide summary in English, or share French version and we can try Google translate.

2 Comments

  1. Here is the document summarizing BnF best practices : https://multimedia-ext.bnf.fr/pdf/ark_preconisations_bnf.pdf

    Summary :

    • Use of the BnF NAAN
    • Naming policy : characters used
      • subnaming authorities
      • substring specific to the resource
      • check character
    • Management of resources through time
      • deletion
      • deaccessioning (global or withdrawal of resources under rights)
      • modification of the perimeter of the identified resource
      • splitting
      • resource A replaced by resource B
    • Use of qualifiers
      • hierarchy qualifiers
      • variant qualifiers
      • Generic variant qualifiers : .description (stands for "?"), .policy (stands for "??"). Generic structure for BnF identifier policies
    • Resolver policy
      • NAAN management (in case a non BnF naan is accessed with a .bnf.fr domain name)
      • subnaming authorities management (redirect rules)
      • check character computation
      • qualifier management
    • Annex : list of recommended HTTP response codes for a list of use cases
  2. Disclaimer : implementation of those best practices is a target, not all our application implement the whole batch yet - but this is on our implementation roadmap. This document was intended to provide best practices to external users first and foremost.