Workgroup to revise the Best Practices for TEI in Libraries

Background

Invitation to participate in revision of Best Practices for TEI in Libraries

Logistics

First Monday of each month

9–10 a.m. Eastern Time in North America (14:00–15:00 UTC in winter in North America, 13:00–14:00 UTC in summer in North America)

If you can't make it, follow along by reviewing minutes (linked below) and/or watching issues on GitHub and adding comments there.

Our Google Drive folder

Members

• Kevin Hawkins (kevin.s.hawkins@gmail)
• stuart yeates ()
• stefanie gehrke (stefanie.gehrke9@gmail.com)
• Elli Mylonas (elli_mylonas@brown.edu)
• James Griffin (griffinj@lafayette.edu [or jrgriffiniii@gmail.com])
• Lisa McAulay ()
• Martin Mueller (martinmueller@northwestern.edu)
• Michelle Dalmau ()
• Antonio Rojas ()
• Paul Schaffner (pfspfs@gmail.com [or pfs@umich.edu])
• Peter Gorman ()
• Andrew Rouner (andrew.rouner@gmail.com)

Suggested meeting procedure

1. Appoint notetaker, creating a new Google Docs file in our Google Drive folder.
2. Resume discussions postponed from last meeting.
3. Go through issues not yet discussed in order of BP revision ticket triage. For each issue, someone volunteers to summarize the issue:
   1. If the issue is straightforward and there's immediate consensus, ask for volunteer to record consensus as a comment on the issue, wait 7 days for objections, and then implement.
   2. If issue is complicated, ask for volunteer to examine issue more closely after the meeting to propose a solution (either rejecting suggestion or changing prose and/or schema to implement). Volunteer will post proposed solution as comment on the issue at least 7 days before our next meeting and lead discussion at next meeting.
      1. If there is consensus, volunteer implements after the meeting.
      2. If there are any adjustments to proposal at that time, volunteer records in a comment on the issue and waits another 7 days for objections before implementing.
4. After meeting, those present review the minutes in the next 48 hours. Notetaker then announces minutes on TEILIB-L.

Meeting minutes

• February 1, 2016

Present: Kevin Hawkins (KH) Stefanie Gehrke (SG) Elli Mylonas (EM)

1. KH: Discuss meeting procedure. Others agree that it seems reasonable as laid out in wiki by KH.
2. Make Google Docs folder and document for minutes, appoint note taker (EM), but all can chip in.
3. Look at tickets:
   1. Issue 6: Since we released BPTL, P5 Guidelines have standardized on sourceDesc/@type=”ISBN”. Kevin suggests not specifying if it’s a 10- or 13-digit ISBN; instead, let the user figure it out, either by the length of the string or using check digit as Stuart Yeates suggests in comment.
   2. SG: We are looking at details but should keep overall structures and relationship of BPTL and P5. Perhaps a wider view might be a better way to guide decisions. KH: Yes, I was wondering about that. We could allow minutiae to raise the larger issues, but perhaps it’s better to start with overall goals.
4. KH reviews goals of and structure of BPTL version 3:
   1. Intended to provide something that serves needs of libraries (sometimes larger scale encoding, often little domain expertise)
   2. Intended to provide a framework for determining the level of encoding depending on the features of the document to be encoded and the resource constraints (time and money). One workflow BPTL wanted to allow for was to start with a low level encoding and then revisit and upgrade to a higher level of encoding in the future. While we weren’t aware of this happening in practice, we still wanted to allow for it.
   3. Allows round tripping of header with MARC. Group spent time mapping to MARC, Michael Sperberg-McQueen created a tool to execute it.
      1. EM: Perhaps we should not only look at MARC but also alternative metadata standards used by libraries (a nod to the future, so it’s clear that we are aware and ready to move in that direction)
         1. RDA (replacement for AACR2)
         2. BIBFRAME (replacement for MARC)
      2. KH: Yes, we should prepare for the future, but we also can’t get ahead of our users (TODO: add issue on BIBFRAME, assigned to KH)
   4. Editing the BPTL document:
      1. The BPTL homepage is a static file. The first link is to a long file (main-driver.html) that is a snapshot generated from the ODD documents. These were created by Syd Bauman. There’s one file for the header specification and one for each level’s “body.” The build process allows you to put these fragments together to create an ODD for the level.
      2. As “best practices”, the document doesn’t use the term “must” (except in element specifications inherited from P5, which show up at the end of main-driver.html). BPTL indicates what people should do to be conformant, not what they must. However, in the ODDs, all the “should” statements are enforced. This helps users who would like to make sure they are following the recommendations of the BPTL, but for any given encoding project, they could further customize the ODD to enforce only those recommendations they decided to actually follow.
   5. EM: Is version 3.0 tagged in the GitHub source? KH: No. (TODO: add tag to github to indicate v3.0 release, assigned to EM)
   6. SG: We should focus on the relationship of the BPTL with TEI Tite and TEI Simple.
      1. Discussion: Perhaps the BPTL can provide a header to be used with those customizations, both of which lack header elements [CORRECTION: Tite lacks a header, whereas Simple doesn’t constrain the header in any particular way.]. We could add some documentation of how to do this. (TODO: create a new issue on this, assigned to KH)
      2. Further discussion: Perhaps we should also map differences in body elements. SG: It could be simple list of elements in the BPTL, with three columns for “used as in customization X”, “not used as in customization X”, and “it’s complicated”. You’d put a checkmark in whichever column applies. [SG has started creating a Google spreadsheet with correspondences: [1]
   7. How to proceed? Before each call, we should all review the next couple of tickets in the BP_revision_ticket_triage triage document and the corresponding sections of the BPTL (comment odd on github / comment on google docs version as well ?) KH: I can include a reminder about this in my reminder emails for each call (which I pledge to send with more notice than this past time!). (TODO: create calendar reminders to send these reminders, assigned to KH)
   8. Resumed discussion of issue 6:
      1. KH: Any objection to updating all instances of “isbn-10” and “isbn-13” to “ISBN” (in prose of BPTL, in elementSpecs, and in encoding examples)? None heard.
      2. KH: I’ll post this as a comment on the issue as in our meeting procedure.
   9. How to handle these minutes?
      1. Discussion: Read and comment by end of business on Wednesday. Then EM will post to the wiki. KH: Please also announce on TEILIB-L so that I’m not the only one pushing this group forward. (TODO: clean up these minutes, assigned to EM, SG, and KH; TODO: convert to wiki and announce, assigned to EM)