May 2, 2016

=Attendees=
 * Kevin S. Hawkins (University of North Texas Libraries)
 * Elli Mylonas (Brown University Library)
 * James R. Griffin III (Lafayette College Libraries)

Apologies

 * Stephanie Gehrke
 * Peter Gorman
 * Martin Mueller

=Ticket Triage= BP revision ticket triage GitHub Issues

Issue #20

 * Mylonas is still going to handle this.

Issues #30 and #33: milestones at &lt;div&gt; boundaries

 * Hawkins: The question in issue 30 actually applies not just to elements but also to milestone-like elements such as . Issue #33 created to address the same question for .
 * We had previously reached consensus that you should always put s within the lowest level of the text division. However, Martin Mueller brought this topic up for discussion on TEI-L . Hawkins prefers to take the initial approach (our previous consensus), but he summarized the views offered in response to Mueller’s post:
 * Holmes:  at the highest level of the tree consistent with division (e. g. between &lt;div&gt;’s) (This represents a purist model of text structure.)
 * Wagner: “For ease of processing and high consistency [. . .], we put milestone elements as the first child of the first mixed content of the element” (the first child of a &lt;p&gt; or —that is, at the bottom of hierarchy of elements)
 * Schaffner: Follows our consensus for div boundaries but discusses tricky cases of page breaks occurring between items in a list, lines of poetry, and in the middle of words.
 * Hawkins: When a page break occurs at a boundary (middle of a word), it’s not really a question of &lt;div&gt;'s. This recommendation was driven by ease of processing: we thought that enough people use systems which extract entire &lt;div&gt;'s at once. Putting all ’s inside a &lt;div&gt; allows for easy displaying of page breaks in the interface.
 * Mylonas: Willing to go with saying in the BPTL that we should put milestone-type elements in the first &lt;div&gt; (for the purposes of consistency), but that users can undertake a different approach if they document it (as Holmes said in his response).
 * Hawkins: Holmes takes an approach strongly informed by textual purism. The motivation behind our current motivation is that if you have a system that displays one chapter at a time by extracting a div, and if this system displays page breaks, it’s confusing to a user if one or more page breaks are missing between chapters.
 * Mylonas: I think the  should be inside the first &lt;div&gt; in order to assist processing (should a work need to be handled on a single chapter [or, chapter-by-chapter] basis).
 * Griffin: How would a user document taking a different approach?
 * Hawkins: I think  is where such things go. Mylonas confirms this.
 * Hawkins: We could, for example, allow users to specify here whether they have put s inside the lowest or highest possible &lt;div&gt;.
 * Hawkins: What we currently specify in  is to document things where the encoding decision had to do with expediency versus richness of encoding (for example, whether page breaks are captured at all). If a user has decided to capture s, I think we should just say where to put them.
 * Hawkins: So, if no objections, I’ll implement as in the consensus from last time: s should be put within the lowest-level &lt;div&gt;. This is just an improvement of wording, not a schema change. [Myllonas would like to see facility for documenting divergence of practice in . Hawkins will do that too.]
 * Hawkins: Confirms that he will address this.

Encoding sigla

 * Hawkins: Before going onto the next issue in the triage, I want to mention that Mueller said during our last meeting that he’d ask on TEI-L about how people encode sigla (as the content of a &lt;ref&gt; or as an attribute value on a or an &lt;ref&gt;).
 * Hawkins: Should I nudge him to do so, or should one of us offer the question on the list ourselves?
 * Consensus: Nudge Mueller.
 * Hawkins: Will do.

Issue #34: how to handle footnotes that span pages

 * Hawkins: We don’t address this at all in the current BPTL. For example, if a footnote crosses pages 12 and 13, you could use a  within the even though a  for the boundaries of pages 12 and 13 in the main text will be elsewhere in the TEI document. We agreed last month to make this explicit but haven’t assigned anyone to implement. It’s just a change to the prose
 * Griffin volunteered to take this on.

Issue #3: rewriting discussion of and

 * Hawkins: This was discussed 2 months ago, and Peter Gorman began working on it. [The minutes say we assigned to him, but we never assigned in GitHub.] I suggest we leave to Peter Gorman to finish: he and Paul Schaffner have made substantial progress.

Issue #4: what element to use for typographic milestones

 * Hawkins: BPTL currently recommend the usage of . Proposal is to clarify which this was chosen over or ) and to add style= to the example. However, last month Martin Mueller raised the possibility of using . I don’t think he did so. [He actually did.]
 * Mylonas and Hawkins: We should revisit P5 to see what it says about the options discussed in comments on the issue and explicate within the GitHub issue.
 * Mylonas: <pc> feels wrong to me because these typographic milestones don’t feel like punctuation characters.
 * Hawkins: This is sort of punctuation at the level of paragraphs rather than sentences or parts of sentences.
 * Mylonas: It’s closer to decoration. She offers to revisit what P5 says and post a recap in the issue.

Issue #5: key= and related matters

 * Hawkins: P5 no longer recommends use of key= attribute for “magic tokens”. Instead, two practices are offered in P5: a tagged URI scheme or a private URI scheme, either on &lt;ref&gt;. We need to update the discussion in the BPTL. I think we should follow P5 in not recommending use of key=. Furthermore, the example of a “magic token” that we give is outdated since the Library of Congress now provides a URI for the authority record. Implementing this ticket will involve not only prose revisions but also encoding within the example and possibly something on linked data, which is further addressed in issue #7.
 * Mylonas: Waiting on the Council for updates regarding linked data.
 * Mylonas: Moved to <xenoData> (double check) - xenodata - used to include non-TEI data in the header, for ex. rdf or Dublin Core.
 * Bauman did much work on this topic.
 * Thinks that &lt;ref&gt; is preferred
 * Adding whole RDF graphs, need something else...but &lt;ref&gt; will suffice as a mechanism to provide URIs for linked data.
 * Mylonas: You can keep a key= if using an internal or specialized information.
 * Mylonas: If there is a linked data vocab., use &lt;ref&gt; with the appropriate URI
 * If an internal identifier which is free-form, use key=.
 * Hawkins: But on this issue, I recommend that for second case (an internal identifier), we don’t recommend key=, just as P5 doesn’t. Instead, &lt;ref&gt; should be used to reference a tagged/private URI scheme. It’s a bit more cumbersome, but I’m anticipating future deprecation of key= in P5.
 * Hawkins: There are currently two approaches for magic tokens within &lt;ref&gt; for P5. I think I want to ask Council to reexamine whether they really want to offer these two different approaches. In any case, we could retain key= if we think it’s especially useful.
 * Mylonas: Recommends that the Council be contacted.
 * Hawkins: Wants to create this Issue on the TEI GitHub Repository regardless
 * Postpone this discussion.
 * Hawkins: Will update the GitHub ticket

Issue #8: more granular encoding for

 * Hawkins: The element within the header is, I think, not actually used by TEI users very often. It’s an analog of part of a bibliographic description in cataloging practice, usually used for the dimension of a physical item. The P5 examples are mostly about file size. I realized that we might include and from the msdescription module as children of.
 * If we recommend that these be used, it would make more machine-processable.
 * Mylonas: Clarifies that the msdescription module includes not only and but also and, which can be a wrapper for the other three.
 * Two set of choices: If height and width are recommended, should also recommend depth
 * Can be free-floating/unordered elements, or could place them within
 * contains ;, , and are siblings
 * can also encode information for pagination
 * Hawkins: In the BPTL currently, we say to include two elements if converting from a catalog record: “one for the extent of the item (e.g., number of pages) and other physical details, and a second one for the dimension(s)”. However, these elements do not have type= attributes to distinguish them. Is this worth having (are there any community use cases)?
 * And if the BPTL recommends using elements like and, should there be some form of a wrapper for these, to separate them from other extent information?
 * Mylonas: Confirms that does not have a type= in P5.
 * Hawkins: P5 has an example where has two elements with @unit attributes. Maybe we need to consider this.
 * Mylonas: Can put as a sibling for.
 * Hawkins: I think I need to review and revise this approach. I might explore using .
 * Mylonas: I think we want only one element but more than one and multiple.
 * Hawkins: Right, has unit= and quantity=, which could be useful.

=Deadline for Minutes=
 * Mylonas: 1 week for feedback
 * Hawkins: 2 days (Wednesday end of day (05/04/16)
 * Griffin will then migrate this to the wiki.

=Action Items=

Issue 20

 * Mylonas: Implement

Issues #30 and #33

 * Hawkins: Implement

Encoding of sigla

 * Hawkins: Nudge Mueller

Issue #34

 * Griffin will implement.

Issue #4

 * Mylonas: Will revisit options in TEI guidelines, post recap in ticket

Issue #5

 * Mylonas: Moved to <xenoData> (double check) - xenodata - used to include non TEI data in the header, for ex. Rdf or dublincore.
 * Hawkins: Wants to create this Issue on the TEI GitHub Repository regardless
 * Hawkins: Will update the GitHub ticket

Issue #8

 * Hawkins: Review options that we discussed and revise the proposal.