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 <distinct> 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 <distinct> 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 <name>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 <heads>, 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]