June 6, 2016

June 6, 2016

=Attendees=


 * Kevin S. Hawkins (University of North Texas Libraries)
 * Syd Bauman (Northeastern University Libraries)
 * Peter Gorman (University of Wisconsin–Madison Libraries) (recorder)

=Ticket Triage=


 * Bauman noticed that the build process for the ODD files is broken, because it relies on resources that no longer exist. Bauman will open a new Git Issue for it. [done]

Issue 3

 * Mostly complete, but Gorman will finish the remaining tasks, mainly updating the examples throughout the document.

Issue 5

 * Bauman noted that there are actually 4 options: @key, @seeRef (though not available for all elements), tag URIs (RFC 4151), or private URI/prefixDef. Hawkins added @xml:base. They can be used in combination, as well: a short private URI can be created that expands to a tag URI.


 * Bauman observed that tag URIs have advantage of being externally defined, and hence may be useful in other contexts, while private URI/prefixDef (http://wiki.tei-c.org/index.php/Prefix_Definition_Proposal) is specific to TEI.


 * Recommendation: encoders should use tag URI instead of @key, but may use private URI/prefixDef if it better suits a project's needs, or if other URI schemes prove to be too cumbersome.


 * Hawkins will update the ticket [done]

Issue 8

 * Recommendation: do not change the discussion ofextent> in BPTL. Issue withdrawn.

Issue 15

 * Gorman and Bauman thought that would be useful for texts at level 4. Even though it adds to an already large tagset, it it usefully distinct from existing elements.


 * Recommendation: add to BPTL level 4. Assigned to Bauman.

Issue 18

 * Group discussed which of the two approaches outlines in the ticket would be the lesser evil. Bauman noted that option "A" is not valid TEI. Option B does not improve the upgrade path from Level 1 to 2 or 2 to 3, and may in fact create work in restructuring block-level elements (i.e., fprm pages to paragraphs).


 * Recommendation: do not change existing guidelines.

Issue 24

 * Since event tagging is not provided for in TEI, this Working Group cannot express this proposal as a constraint of TEI.


 * Recommendation: propose this to the TEI Council as a feature request.


 * Hawkins will close the Issue.

Issue 25

 * The group was uncertain what specific action is being requested; is it about adding to the table of MARC/teiHeader mappings? If there are elements in the body that would enhance a MARC record, would they have to be expressed in a new table? Could we even make feasible suggestions (e.g., algorithmically adding s as MARC 6xx or 7xx fields) that would be compatible with RDA?


 * It may be possible to extract a table of contents from a document's structure and, e.g., to create a MARC 505 field. That would not be a recommendation for the teiHeader per se, unless the suggestion is to replicate ToC information in the teiHeader - but then the body and teiHeader could fall out of sync.


 * Hawkins will add a comment to the ticket asking for clarification of this issue. [done]