June 6, 2016
June 6, 2016
- Kevin S. Hawkins (University of North Texas Libraries)
- Syd Bauman (Northeastern University Libraries)
- Peter Gorman (University of Wisconsin–Madison Libraries) (recorder)
- 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]
- Mostly complete, but Gorman will finish the remaining tasks, mainly updating the examples throughout the document.
- Bauman noted that there are actually 4 options: @key, @seeRef (though not available for all elements), tag URIs (RFC 4151), or private URI schemes (creating a "prefix definition"). 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 schemes (creating a "prefix definition") is specific to TEI.
- Recommendation: encoders should use tag URI instead of @key, but may use a private URI schemes (creating a "prefix definition") if it better suits a project's needs, or if other URI schemes prove to be too cumbersome.
- Hawkins will update the ticket [done]
- Recommendation: do not change the discussion of <extent> in BPTL. Issue withdrawn.
- 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. [done]
- 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.
- 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. [done but has reopened following further conversation]
- 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 <div> structure and <head>s, 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]