December 12, 2016

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

=Ticket Triage=
 * BP revision ticket triage
 * GitHub Issues

Issues 21 (and 31 by reference)
link
 * Mylonas was assigned this issue
 * Wanted clarifications in order to fix it
 * Last comment regarding  and @force: is this in level 3 and 4?
 * Do this for both or...?


 * Hawkins: Section for hyphenation is actually in the introduction of the BPTL.


 * Mylonas: Will rewrite the section on hyphenation
 * If you want to record your hyphen use  with or without @force
 * Otherwise just use with or without @break="yes" or @break="no"


 * Hawkins: Always use @force (otherwise, wouldn't care about putting it in)


 * Mylonas: Only care about  for users interested in the rendition of the hyphen itself
 * Need to be able to remove the hyphen in order to tokenize it
 * Also use a @rend on the


 * Hawkins: References the 4 cases in the thread


 * Mylonas: Also appropriate for #31

Issues 43 (and 9 by reference)
link
 * Assigned to Bauman
 * #9 and #43 are related
 * Half-way through...not yet committed
 * Failed to generate output from the ODD file
 * Discovered a problem in the build process
 * #43 should be quick to finish
 * #9 might need assistance

Issue 45
link
 * Mylonas assigned to this
 * Adding to the issue the values which bring it all together
 * Then will select which are preferred

Issue 3
link
 * Assigned to Gorman
 * Gorman contacted by Hawkins
 * No response, might need to reassign it
 * Some progress was made by Gorman


 * Hawkins: Tag usage is explicitly discussed once


 * Bauman: Don't need to worry about the changes in usage of tags then


 * Hawkins: Should come back next month, give Gorman more time
 * Otherwise, someone else will finish this

Issue 42
link
 * Hawkins: Previously, could be a child of . Council has since cleaned up the content model to no longer allow this. Now it's only allowed within, , or
 * Clarifies that  does require at least a child.
 * In a standard catalog record any value that would be put into, like a call number, refers to the whole bibliographic entity (the ).
 * Any in a record also refers to the entity as a whole.
 * Reiterates that the TEI has eliminated the option to have rendered outside of
 * Hearing no objections, Hawkins will implement this.

Issues 37
link


 * Item 3 from Bauman’s comment on June 6th is still unresolved
 * Bauman:  and elements are flagged as invalid when included in Schematron rules
 * Not certain as to why


 * Hawkins: Proposes that users be encouraged to ignore validation errors


 * Bauman: Approach the TEI Council itself to fix this
 * If Schematron shouldn't complain, TEI shouldn't complain either
 * The alternative is to remove these elements from our Schematron rules. Everything will still work, but we simply won’t have this extra markup.


 * Hawkins: Bauman will approach the Council with a ticket
 * Either Bauman will remove these elements from the Schematron rules or will sort this out with the Council.

Issue 7
link
 * Hawkins: Had been waiting for Council to resolve related TEI#1346, but that’s done now.
 * Bauman identified one part of prose which needs to be rewritten
 * Need to add  to the big table of header elements


 * Bauman: He could do this but wants to address build-related issues before taking on any other issues.


 * Hawkins: Volunteers to address this issue

Issue 13
link
 * Hawkins: Still hopes to have collaboration from a cataloger at UNT Libraries.

Issue 27
link
 * Wanted to give it to Stefan Majewski
 * Nothing heard from him for months
 * (New position is likely consuming his time and focus)


 * Hawkins: Either postpone this until someone with an understanding of supporting coordinated OCR in the TEI
 * Or find someone who can address this


 * Mylonas: Sometimes this is at the letter level
 * Prefers that this be prioritized for the "dormant" Milestone rather than close the issue

Issue 38
link
 * Mylonas: Is this complete?
 * Bauman: Addressing the broken build process

Issue 47
link
 * Mylonas: Looks like the big issues involving specifying attribute values without using the class system, rendering customization difficult.
 * Some constraints appear to be redundant
 * Offers to take on but consult with Bauman on aspects relating to the schema


 * Hawkins: Concurs

Issue 36
link
 * Hawkins: Mueller had volunteered to draft a recommendation
 * Updated Hawkins with an e-mail
 * No concrete changes identified for the BPTL document
 * Mueller suggests that sigla not be removed from the text
 * Doesn't seem to care about where the element is inserted


 * Mylonas: We could have both siglum and note point to each other.


 * Hawkins: I think you can't put a @target on the element itself [actually, you can!], so there would need to be a &lt;ref&gt; within the in order to point back.


 * Mylonas: You don’t want the siglum character to be an attribute value because you need to be able to handle the case of a non-Unicode glyph used to link between a siglum and note.


 * Hawkins: Best to put &lt;ref&gt; on the superscript symbol which appears in the note itself.


 * Mylonas: Perhaps an alternative pointing
 * e. g. @sameAs


 * Bauman: Need to research this a bit
 * TEI wants to use &lt;ref&gt; for the prose
 * Nothing stated about what to do for the symbol within the
 * Can use &lt;ref&gt;
 * @sameAs might be more appropriate, not certain
 * Narrower intended usages


 * Hawkins: Probably need to get an image of a page siglum and a footnote and encode this bit of text in order to make these conversations easier to follow.
 * Proposes that someone mockup a sample with a proposed way of encoding sigla and notes.


 * Mylonas: @corresp might be better
 * @sameAs won't suffice


 * Bauman: @corresp references a concept in mathematics
 * Must users don't employ @corresp in this manner
 * (Looking for examples)


 * Hawkins: Will find an image of a page with the footnotes
 * Produce a quick mockup of the encoding so that we have something concrete to discuss.


 * Mylonas: We have a set of problems
 * One option: stick note where it appears on the layout of the page, give it a reference, and ensure that it's rendered as footnote, margin note, endnote, etc.
 * Another option: place it within the text, linking it to another location (e.g., linking to notes at the bottom of the page within the text)
 * Wherever you put them, have a notation where they are anchored in the text
 * For cases where there are typos and the anchors don't correspond, what is the mechanism?


 * Hawkins: Leaving the footnotes at the bottom of the page makes sense in the case of mass OCR-encoding, where you don’t want to have to rearrange the OCR text when encoding.


 * Bauman: At what level are we discussing footnote numbers?


 * Hawkins: Recommended at Level 3, required at Level 4


 * Bauman: Not footnote numbers, but actual notes.


 * Hawkins: That’s what I meant. The BPTL don’t say what to do with footnote numbers appearing in the notes [though imply that you should put the value in the value of @n on ].


 * Bauman: Any sizable library project has recommended that footnote numbers not be encoded [because they are keyboarding].
 * Should only include footnote numbers at Level 4 or 5, not Level 3.


 * Hawkins: The BPTL is written under the fiction that someone might upgrade through the levels of encoding even though we have no evidence that people actually do this. If we continue with this fiction, I would hate to see us prescribe removing the sigla at Level 3 but then having to add them back in at Level 4 or 5.


 * Bauman: That burden is on the user


 * Mylonas: We recommend doing notes in Level 3 and require them in Level 4.
 * Don't require that the sigla be encoded at any point.


 * Bauman: Most people don't encode the sigla.


 * Mylonas: If the text being encoded is really odd...
 * Should mention sigla in Level 3 and provide some simple solution
 * But, never recommend that users encode sigla


 * Bauman: Users interested in sigla usually aren't employing mass digitization technologies (such as OCR).


 * Hawkins: Best practices permits more than one option for certain problems
 * In Level 3, if the notes are encoded where they occur in the layout of the page, you should use either &lt;ref&gt; (implies that the siglum is right there, as the content of the &lt;ref&gt; element) or a ; in the latter case, the siglum appearing on the page is not encoded as content.
 * Perhaps we should revise the BPTL so that at Level 4, the encoding of sigla becomes significant.
 * Probably need to permit both options [HAWKINS: NOT SURE WHAT I MEANT]


 * Mylonas: Mass-scale digitization [with OCR] preserves the location of the footnote in the layout on the page.
 * Case: Where a footnote starts on page 5 and flows to page 6...


 * Hawkins: This case was addressed in a separate issue.
 * Clarifies that there are many different options for encoding footnotes
 * Perhaps we need a table showing a few different ways of encoding notes so that people can see the options clearly.


 * Bauman: We could instead become more draconian
 * At Level 3 you are required to separate that the notes be encoded at the bottom of the page
 * Encode sigla within the text (as content)
 * At Level 4, encode using &lt;ref&gt; and additional mechanisms


 * Hawkins: At Level 3, leave the note where it occurs in the layout on the page, encoded the siglum in a &lt;ref&gt;
 * At Level 4, encode the note by moving to the point of attachment
 * Referencing Mueller: should always include the siglum
 * In the experience of Mylonas and Bauman, users don't tag the siglum or actually remove the siglum?


 * Bauman: To remove it means not to type it
 * If you scan it, it's easier to leave it there
 * If you're typing it, it's easier not to actually enter it


 * Mylonas: For encoding the superscript number or other symbol inside the note itself, we can use.