Minutes for February 1, 2016

Present:
 * Kevin Hawkins (KH)
 * Stefanie Gehrke (SG)
 * Elli Mylonas (EM)
 * KH: Discuss meeting procedure. Others agree that it seems reasonable as laid out in wiki by KH.
 * 1) Make Google Docs folder and document for minutes, appoint note taker (EM), but all can chip in.
 * 2) Look at tickets:
 * 3) 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.
 * 4) 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.
 * 5) KH reviews goals of and structure of BPTL version 3:
 * 6) Intended to provide something that serves needs of libraries (sometimes larger scale encoding, often little domain expertise)
 * 7) 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.
 * 8) Allows round tripping of header with MARC. Group spent time mapping to MARC, Michael Sperberg-McQueen created a tool to execute it.
 * 9) 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)
 * 10) RDA (replacement for AACR2)
 * 11) BIBFRAME (replacement for MARC)
 * 12) 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)
 * 13) Editing the BPTL document:
 * 14) 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.
 * 15) 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.
 * 16) 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)
 * 17) SG: We should focus on the relationship of the BPTL with TEI Tite and TEI Simple.
 * 18) 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)
 * 19) 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:
 * 20) 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)
 * 21) Resumed discussion of issue 6:
 * 22) 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.
 * 23) KH: I’ll post this as a comment on the issue as in our meeting procedure.
 * 24) How to handle these minutes?
 * 25) 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)