TEIWiki - User contributions [en]

March 6, 2017

2017-03-09T06:56:33Z

James R. Griffin III: The next meeting time should be GMT-4 (EDT)

=Attendees=
* Kevin S. Hawkins (University of North Texas Libraries) (KH)
* Andrew Rouner (Washington University Libraries) (AR)
* Elli Mylonas (Brown University Library) (EM)
* Syd Bauman (Northeastern University) (SB)
* James R. Griffin III (Lafayette College Libraries) (JG)

=Ticket Triage=
*[http://wiki.tei-c.org/index.php/BP_revision_ticket_triage BP revision ticket triage]
*[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues GitHub Issues]

==Issue #45==
* Mylonas assigned
* If added to all numbered <div>’s, needs to be an attribute class
* Asking Bauman
* Adding att class in lib.header
* Note in header...want it to be inherited by other ODD’s
* <div>s can be members of/inherit using this class
* Hawkins:
* Main driver ODD instead? And just inherited?
* Bauman:
* Would be happy to create lib.common
* Mylonas:
* Does it have a spec.?
* Bauman:
* Getting the spec out of it before processing it is hard
* Hawkins:
* Common would label things
* Bauman:
* We already have things like this in header
* Mylonas:
* Schematron has rules: don't apply here to the header, want to be inherited by everything else
* Should this be a class? Otherwise just repeat
* Bauman:
* Would need to be repeated at least 21 times?
* Mylonas:
* Decided to make an attr class
* Will be with in lib.header.odd
* Bauman:
* Name?
* att.bptl.divstype
* It's specific to <div> types
* Trust Bauman's judgement for the name

==Issue #53==
* New issue regarding transcriptional omissions
* Created by Bauman 2 weeks ago
* 3.2 Regarding prose is confusing...some ambiguity
* <samplingDecl> elements
* Make the appropriate adjustments in the ODD's and header table
* Mylonas:
* <samplingDecl> takes <ab> and <p>
* Hawkins:
* Follow the practices for other elements wth prose within the them
* <editorialDecl> also takes <p>'s
* <projectDesc> also uses <p>'s
* Use <p> again for consistency
* Separate issue for using <ab>'s instead of <p>'s?
* Bauman:
* <p> would be useful...paragraph of prose
* <ab> doesn't require an entire sentence
* Hawkins:
* Suggest that we remain with <p>
* Prose statement should be the recommendation for the content of the <p>'s
* Probably should restrain the spec. for this
* Uncertain if the other header elements are similarly constrained

* (Rouner had to drop off)

==Issue #3==
* Hawkins assigned
* No progress since last month

==Issue #42==
* Hawkins assigned
* No progress

==Issue #51==
* Mylonas created the ticket
* Not clear what the purpose is
* Hawkins investigated
* Started as a list of all attributes which could be used within text
* Mylonas: Should remove this issue
* Hawkins: Agrees, ODD's have been modified appropriately
* Bauman: Agrees
* Hawkins:
* Renumber appendices as needed
* Mylonas will address

==Issue #37==
* (Related to #2)
* Bauman:
* Created an issue for TEI-C
* Nobody responded, many might not care
* TEI documentation elements are invalid in TEI schematron reporters
* Must wait on the Council
* Hawkins:
* Will delay until feedback is received
* Mylonas:
* Will update the label to "postponed"

==Issue #7==
* Assigned to Hawkins
* No progress

==Issue #9==
* Assigned to Bauman
* Started this some time ago
* http://paramedic.wwp.neu.edu/~syd/temp/BPTL/
* Look within this for the <editorialDecl> usage
* "?? SHOULD THIS BE HERE ??"
* These flags indicate that there are discussion points
* Hawkins:
* Leave the question marks
* Will consult with a cataloger colleague for the MARC field references
* Bauman:
* Don't do interpretative markup any longer
* Hawkins:
* Can remove
* Bauman:
* Also, <interpretation>, <segmentation>, <stdVals>: does anyone use these?
* Mylonas:
* Agrees, at most <segmentation> would only be in Level 5
* Hawkins:
* Row for <editorialDecl>
* Just discuss elements in rows below
* Remove the bulleted items
* Bauman has added new rows...hence, some of those bullets are no longer valid
* Last two bulleted items should be removed

==Issue #13==
* Hawkins will propose to meet with the cataloger
* Unfamiliar with the TEI

==Issue #47==
* Mylonas
* Left this for last after finishing #45

==CSS for the BPTL==
* (No GitHub Issue Reference)
* Bauman
* Still addressing CSS for default rendition of elements
* Consequence of updates to the TEI
* Hawkins:
* Did the HTML output get hacked at some point?
* Regardless, needs to be fixed in the source

==Issue #36==
* Mylonas:
* Responded on the Issue
* Recommended some changes
* Hawkins:
* Can move forward based on these comments

==Issue #14==
* Hawkins:
* No progress

==Issue #17==
* Bauman:
* Schema code has been written
* Prose is also finished
* Schema processing doesn't handle these updates gracefully
* Prefer that processing of ODD offers a limited number of options depending upon the encoding level
* Will update the Issue on GitHub
* Can release without fixing this in pure ODD
* oXygen parses the ODD and should offer the appropriate list of values in a dropdown
* Hawkins:
* Should add a comment indicating that it doesn't work in pure ODD processing
* Close the Issue as resolved

==Issue #10==
* Assigned to Bauman and Rouner
* Rouner couldn't fix sound issues
* Bauman fixed the schema
* Will leave to Rouner to finish
* Bauman:
* <langKnowledge> or <langKnown> should be in there
* Believes that these shouldn't be there, but didn't reference the notes
* Rouner decides whether or not these should be removed

==Issue #11==
* Assigned to Bauman
* Uncertain as to what should be implemented
* Mylonas:
* Adding it to Levels 1 and 2
* Bauman:
* Level 1 doesn't have a <note> element (?)
* Hawkins:
* Confirms that it doesn't
* Level 2 also does not have a <note>
* Bauman:
* <note> is found in Level 2
* Hawkins:
* Not mentioned in the table of elements
* Bauman:
* Level 2: model.global permits <note>'s everywhere
* They are also in model.global for Level 1
* Hawkins:
* People might want XML comments or processing instructions (as opposed to <note>'s)
* No change to make on @sameAs
* Discovered <note> is erroneously allowed for Levels 1 and 2
* Recommends that Bauman remove this
* Bauman:
* It looks as if this was purposely done when originally implemented
* Hawkins:
* <note> is definitely permitted in the header
* It must be constrained from being used on the body in Levels 1 and 2

==Issue #12==
* (Blocked by #52)
* Decided what is to be implemented
* Unassigned
* Proposes that this be delayed until the next call
* Mylonas:
* Big header table does indicate what is required
* Hawkins:
* Proposes to focus first upon #52
* Work related to modal expressions work is quite complex

==Issue #16==
* Mylonas:
* Not really an ODD question
* Focuses upon best practices (requires prose)
* Hawkins:
* Warns of complexity
* Example: Level 2 Serials
* Might need some extra elements
* Treating a whole volume using <div1> or <div> or each volume
* Searching for authors within the structure of the <div>'s

=Scheduling for the Next Meeting=
* April 3rd, 2017 13:00 GMT-4

[[Category:Workgroup to revise the Best Practices for TEI in Libraries]]
[[Category:SIG:Libraries]]

Workgroup to revise the Best Practices for TEI in Libraries

2017-03-09T06:51:29Z

James R. Griffin III: Linking to the minutes captured from the meeting held on March 6, 2017

== Background ==

[https://list.indiana.edu/sympa/arc/teilib-l/2015-11/msg00006.html Invitation to participate] in revision of ''[http://purl.oclc.org/NET/teiinlibraries Best Practices for TEI in Libraries]''

== Logistics ==

First Monday of each month

9–10 a.m. Eastern Time in North America (14:00–15:00 UTC in winter in North America, 13:00–14:00 UTC at other times of the year)

People with email addresses listed below will have hangout link sent to them for each meeting. We can do up to 10 people with a regular hangout. If we get more people, we'll find someone with a Google Apps for Education account who can support up to 15(?).

: Actually, you can only invite up to 5 people to a Hangout. Beyond that, you need to just share a link. We'll plan to share the link on teilib-l shortly before each meeting.

If you can't make it, follow along by reviewing minutes (linked below) and/or watching [https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues issues on GitHub] (click "watch" after logging in) and adding comments there.

[https://drive.google.com/open?id=0B13gonNAATNSSmtJMk14VHpzazQ Our Google Drive folder]

== Members ==
* Kevin Hawkins (kevin.s.hawkins@gmail)
* stuart yeates ()
* stefanie gehrke (stefanie.gehrke9@gmail.com)
* Elli Mylonas (elli_mylonas@brown.edu)
* James Griffin (griffinj@lafayette.edu [or jrgriffiniii@gmail.com])
* Lisa McAulay ()
* Martin Mueller (martinmueller@northwestern.edu)
* Michelle Dalmau ()
* Antonio Rojas ()
* Paul Schaffner (pfspfs@gmail.com [or pfs@umich.edu])
* Peter Gorman (peter.gorman@wisc.edu)
* Andrew Rouner (andrew.rouner@gmail.com)
* Syd Bauman (s.bauman@northeastern.edu)

== Suggested meeting procedure ==

# Appoint notetaker, creating a new Google Docs file in our Google Drive folder.
# Resume discussions postponed from last meeting.
# Go through issues not yet discussed in order of [[BP revision ticket triage]]. For each issue, someone volunteers to summarize the issue:
## If the issue is straightforward and there's immediate consensus, ask for volunteer to record consensus as a comment on the issue, wait 7 days for objections, and then implement*.
## If issue is complicated, ask for volunteer to examine issue more closely after the meeting to propose a solution (either rejecting suggestion or changing prose and/or schema to implement*). Volunteer will post proposed solution as comment on the issue at least 7 days before our next meeting and lead discussion at next meeting.
### If there is consensus, volunteer implements* after the meeting.
### If there are any adjustments to proposal at that time, volunteer records in a comment on the issue and waits another 7 days for objections before implementing*.
# After meeting, those present review the minutes in the next 48 hours. Notetaker then announces minutes on TEILIB-L.

<nowiki>*</nowiki> Change may be implemented either by committing to the master branch or making pull requests. The advantage of a pull request is that it forces a second set of eyes to review changes. This is especially important for changes to content models in the ODD (rather than simply to prose).

== Meeting minutes ==

* [[Minutes for February 1, 2016|February 1, 2016]]
* [[March 7, 2016]]
* [[April 4, 2016]]
* [[May 2, 2016]]
* [[June 6, 2016]]
* [[July 11, 2016]]
* [[August 1, 2016]]
* [[September 12, 2016]]
* [[October 10, 2016]]
* [[November 14, 2016]]
* [[December 12, 2016]]
* [[January 9, 2017]]
* [[February 13, 2017]]
* [[March 6, 2017]]

[[Category:Workgroup to revise the Best Practices for TEI in Libraries]]
[[Category:SIG:Libraries]]

March 6, 2017

2017-03-09T06:50:31Z

James R. Griffin III: Adding the notes captured by Griffin from the meeting held by the WG on 03/06/17

=Attendees=
* Kevin S. Hawkins (University of North Texas Libraries) (KH)
* Andrew Rouner (Washington University Libraries) (AR)
* Elli Mylonas (Brown University Library) (EM)
* Syd Bauman (Northeastern University) (SB)
* James R. Griffin III (Lafayette College Libraries) (JG)

=Ticket Triage=
*[http://wiki.tei-c.org/index.php/BP_revision_ticket_triage BP revision ticket triage]
*[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues GitHub Issues]

==Issue #45==
* Mylonas assigned
* If added to all numbered <div>’s, needs to be an attribute class
* Asking Bauman
* Adding att class in lib.header
* Note in header...want it to be inherited by other ODD’s
* <div>s can be members of/inherit using this class
* Hawkins:
* Main driver ODD instead? And just inherited?
* Bauman:
* Would be happy to create lib.common
* Mylonas:
* Does it have a spec.?
* Bauman:
* Getting the spec out of it before processing it is hard
* Hawkins:
* Common would label things
* Bauman:
* We already have things like this in header
* Mylonas:
* Schematron has rules: don't apply here to the header, want to be inherited by everything else
* Should this be a class? Otherwise just repeat
* Bauman:
* Would need to be repeated at least 21 times?
* Mylonas:
* Decided to make an attr class
* Will be with in lib.header.odd
* Bauman:
* Name?
* att.bptl.divstype
* It's specific to <div> types
* Trust Bauman's judgement for the name

==Issue #53==
* New issue regarding transcriptional omissions
* Created by Bauman 2 weeks ago
* 3.2 Regarding prose is confusing...some ambiguity
* <samplingDecl> elements
* Make the appropriate adjustments in the ODD's and header table
* Mylonas:
* <samplingDecl> takes <ab> and <p>
* Hawkins:
* Follow the practices for other elements wth prose within the them
* <editorialDecl> also takes <p>'s
* <projectDesc> also uses <p>'s
* Use <p> again for consistency
* Separate issue for using <ab>'s instead of <p>'s?
* Bauman:
* <p> would be useful...paragraph of prose
* <ab> doesn't require an entire sentence
* Hawkins:
* Suggest that we remain with <p>
* Prose statement should be the recommendation for the content of the <p>'s
* Probably should restrain the spec. for this
* Uncertain if the other header elements are similarly constrained

* (Rouner had to drop off)

==Issue #3==
* Hawkins assigned
* No progress since last month

==Issue #42==
* Hawkins assigned
* No progress

==Issue #51==
* Mylonas created the ticket
* Not clear what the purpose is
* Hawkins investigated
* Started as a list of all attributes which could be used within text
* Mylonas: Should remove this issue
* Hawkins: Agrees, ODD's have been modified appropriately
* Bauman: Agrees
* Hawkins:
* Renumber appendices as needed
* Mylonas will address

==Issue #37==
* (Related to #2)
* Bauman:
* Created an issue for TEI-C
* Nobody responded, many might not care
* TEI documentation elements are invalid in TEI schematron reporters
* Must wait on the Council
* Hawkins:
* Will delay until feedback is received
* Mylonas:
* Will update the label to "postponed"

==Issue #7==
* Assigned to Hawkins
* No progress

==Issue #9==
* Assigned to Bauman
* Started this some time ago
* http://paramedic.wwp.neu.edu/~syd/temp/BPTL/
* Look within this for the <editorialDecl> usage
* "?? SHOULD THIS BE HERE ??"
* These flags indicate that there are discussion points
* Hawkins:
* Leave the question marks
* Will consult with a cataloger colleague for the MARC field references
* Bauman:
* Don't do interpretative markup any longer
* Hawkins:
* Can remove
* Bauman:
* Also, <interpretation>, <segmentation>, <stdVals>: does anyone use these?
* Mylonas:
* Agrees, at most <segmentation> would only be in Level 5
* Hawkins:
* Row for <editorialDecl>
* Just discuss elements in rows below
* Remove the bulleted items
* Bauman has added new rows...hence, some of those bullets are no longer valid
* Last two bulleted items should be removed

==Issue #13==
* Hawkins will propose to meet with the cataloger
* Unfamiliar with the TEI

==Issue #47==
* Mylonas
* Left this for last after finishing #45

==CSS for the BPTL==
* (No GitHub Issue Reference)
* Bauman
* Still addressing CSS for default rendition of elements
* Consequence of updates to the TEI
* Hawkins:
* Did the HTML output get hacked at some point?
* Regardless, needs to be fixed in the source

==Issue #36==
* Mylonas:
* Responded on the Issue
* Recommended some changes
* Hawkins:
* Can move forward based on these comments

==Issue #14==
* Hawkins:
* No progress

==Issue #17==
* Bauman:
* Schema code has been written
* Prose is also finished
* Schema processing doesn't handle these updates gracefully
* Prefer that processing of ODD offers a limited number of options depending upon the encoding level
* Will update the Issue on GitHub
* Can release without fixing this in pure ODD
* oXygen parses the ODD and should offer the appropriate list of values in a dropdown
* Hawkins:
* Should add a comment indicating that it doesn't work in pure ODD processing
* Close the Issue as resolved

==Issue #10==
* Assigned to Bauman and Rouner
* Rouner couldn't fix sound issues
* Bauman fixed the schema
* Will leave to Rouner to finish
* Bauman:
* <langKnowledge> or <langKnown> should be in there
* Believes that these shouldn't be there, but didn't reference the notes
* Rouner decides whether or not these should be removed

==Issue #11==
* Assigned to Bauman
* Uncertain as to what should be implemented
* Mylonas:
* Adding it to Levels 1 and 2
* Bauman:
* Level 1 doesn't have a <note> element (?)
* Hawkins:
* Confirms that it doesn't
* Level 2 also does not have a <note>
* Bauman:
* <note> is found in Level 2
* Hawkins:
* Not mentioned in the table of elements
* Bauman:
* Level 2: model.global permits <note>'s everywhere
* They are also in model.global for Level 1
* Hawkins:
* People might want XML comments or processing instructions (as opposed to <note>'s)
* No change to make on @sameAs
* Discovered <note> is erroneously allowed for Levels 1 and 2
* Recommends that Bauman remove this
* Bauman:
* It looks as if this was purposely done when originally implemented
* Hawkins:
* <note> is definitely permitted in the header
* It must be constrained from being used on the body in Levels 1 and 2

==Issue #12==
* (Blocked by #52)
* Decided what is to be implemented
* Unassigned
* Proposes that this be delayed until the next call
* Mylonas:
* Big header table does indicate what is required
* Hawkins:
* Proposes to focus first upon #52
* Work related to modal expressions work is quite complex

==Issue #16==
* Mylonas:
* Not really an ODD question
* Focuses upon best practices (requires prose)
* Hawkins:
* Warns of complexity
* Example: Level 2 Serials
* Might need some extra elements
* Treating a whole volume using <div1> or <div> or each volume
* Searching for authors within the structure of the <div>'s

=Scheduling for the Next Meeting=
* April 3rd, 2017 13:00 GMT-5

[[Category:Workgroup to revise the Best Practices for TEI in Libraries]]
[[Category:SIG:Libraries]]

Workgroup to revise the Best Practices for TEI in Libraries

2017-02-15T13:51:37Z

James R. Griffin III: Linking to the minutes captured from the meeting held on February 13, 2017

== Background ==

[https://list.indiana.edu/sympa/arc/teilib-l/2015-11/msg00006.html Invitation to participate] in revision of ''[http://purl.oclc.org/NET/teiinlibraries Best Practices for TEI in Libraries]''

== Logistics ==

First Monday of each month

9–10 a.m. Eastern Time in North America (14:00–15:00 UTC in winter in North America, 13:00–14:00 UTC at other times of the year)

People with email addresses listed below will have hangout link sent to them for each meeting. We can do up to 10 people with a regular hangout. If we get more people, we'll find someone with a Google Apps for Education account who can support up to 15(?).

: Actually, you can only invite up to 5 people to a Hangout. Beyond that, you need to just share a link. We'll plan to share the link on teilib-l shortly before each meeting.

If you can't make it, follow along by reviewing minutes (linked below) and/or watching [https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues issues on GitHub] (click "watch" after logging in) and adding comments there.

[https://drive.google.com/open?id=0B13gonNAATNSSmtJMk14VHpzazQ Our Google Drive folder]

== Members ==
* Kevin Hawkins (kevin.s.hawkins@gmail)
* stuart yeates ()
* stefanie gehrke (stefanie.gehrke9@gmail.com)
* Elli Mylonas (elli_mylonas@brown.edu)
* James Griffin (griffinj@lafayette.edu [or jrgriffiniii@gmail.com])
* Lisa McAulay ()
* Martin Mueller (martinmueller@northwestern.edu)
* Michelle Dalmau ()
* Antonio Rojas ()
* Paul Schaffner (pfspfs@gmail.com [or pfs@umich.edu])
* Peter Gorman (peter.gorman@wisc.edu)
* Andrew Rouner (andrew.rouner@gmail.com)

== Suggested meeting procedure ==

# Appoint notetaker, creating a new Google Docs file in our Google Drive folder.
# Resume discussions postponed from last meeting.
# Go through issues not yet discussed in order of [[BP revision ticket triage]]. For each issue, someone volunteers to summarize the issue:
## If the issue is straightforward and there's immediate consensus, ask for volunteer to record consensus as a comment on the issue, wait 7 days for objections, and then implement*.
## If issue is complicated, ask for volunteer to examine issue more closely after the meeting to propose a solution (either rejecting suggestion or changing prose and/or schema to implement*). Volunteer will post proposed solution as comment on the issue at least 7 days before our next meeting and lead discussion at next meeting.
### If there is consensus, volunteer implements* after the meeting.
### If there are any adjustments to proposal at that time, volunteer records in a comment on the issue and waits another 7 days for objections before implementing*.
# After meeting, those present review the minutes in the next 48 hours. Notetaker then announces minutes on TEILIB-L.

<nowiki>*</nowiki> Change may be implemented either by committing to the master branch or making pull requests. The advantage of a pull request is that it forces a second set of eyes to review changes. This is especially important for changes to content models in the ODD (rather than simply to prose).

== Meeting minutes ==

* [[Minutes for February 1, 2016|February 1, 2016]]
* [[March 7, 2016]]
* [[April 4, 2016]]
* [[May 2, 2016]]
* [[June 6, 2016]]
* [[July 11, 2016]]
* [[August 1, 2016]]
* [[September 12, 2016]]
* [[October 10, 2016]]
* [[November 14, 2016]]
* [[December 12, 2016]]
* [[January 9, 2017]]
* [[February 13, 2017]]

[[Category:Workgroup to revise the Best Practices for TEI in Libraries]]
[[Category:SIG:Libraries]]

February 13, 2017

2017-02-15T13:50:01Z

James R. Griffin III: Cleaning and adjusting some of the markup (for consistency and legibility)

=Attendees=
* Kevin S. Hawkins (University of North Texas Libraries) (KH)
* Andrew Rouner (Washington University Libraries) (AR)
* Elli Mylonas (Brown University Library) (EM)
* Syd Bauman (Northeastern University) (SB)
* James R. Griffin III (Lafayette College Libraries) (JG)

=Ticket Triage=
*[http://wiki.tei-c.org/index.php/BP_revision_ticket_triage BP revision ticket triage]
*[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues GitHub Issues]

Summarize EM ticket work:
==Issue #21==
*Made fix to the pull request (PR) request suggested by KH
*Closed
*Can make a new PR - or perhaps the old pull request will incorporate the latest changes.

==Issue #45==
*EM made a <valList> for <div> based on notes in the Issue.
*EM: should we be abbreviating the values?
*KH: no abbreviations
*EM: Does each ODD have to be updated separately?
*KH: No ODD cascade exists
*(SB arrives)

*EM noticed Appendix A of Attribute Values ([http://www.tei-c.org/SIG/Libraries/teiinlibraries/main-driver.html#index.xml-body.1_div.6 Best Practices for TEI in Libraries, Version 3])
*EM: Doesn’t seem helpful, doesn't specify which elements they belong to, which are mentioned in the Best Practices for TEI in Libraries (BPTL) and which are “favorites”
*KH: Didn't come from version 2.1
*EM: Try to remove this or link to element specs
*Action on EM: Create the issue

==Issue #3==
*KH: Would take this over from Peter Gorman
**Hasn't made any progress
**SB: Clarifies that this is actually labor-intensive

==Issue #42==
*KH: No progress

==Issue #37==
*SB:
**TEI needs to address this schematron issue
**Need to address the issue of possibly leaving the TEI rather than the BPTL
**Will be submitting a ticket to the TEI

==Issue #7==
*KH: No progress

==Issue #9==
*SB:
**Ticket for the schema or for the prose?
**The schema component is finished
*KH: If changes for both are required, they are kept in the same ticket
*SB:
**Prose should be changed
**Needs to finish, issues a call for participants
*KH: Enumerates all of the elements available through the TEI P5, but not all are used by the BPTL
*SB: Some elements are difficult to address (e. g. <stdVals>)
*KH: Should only scope this issue for elements included on this list now

==Issue #13==
*KH: A cataloger colleague in the UNT University Libraries is addressing this
*No update

==Issue #47==
*EM: No progress
*SB: Most of this was what was intended by the BPTL WG
*EM: Just needs to be reviewed
*KH: Lou noticed these after running a comparison
*EM: Changing content models might have unforeseen consequences
*Will review and check for questions

==Issue #36==
*KH: Written comments to be reviewed by EM

==Issue #14==
*KH: Needs to implement

==Issue #17==
*EM: SB changed the <schemaRef> and updated the examples
*SB and EM will finish collaboratively

==Issue #31==
*EM: This issue was just closed
*Pull request was opened for discussion
*KH will attempt to merge the PR

==Issue #10==
*KH:
**Indicating interviewers and interviewees
**Discussed in September, but this was postponed
**This was a suggestion for using the <listPerson> element
**Should be added to Level 4 (already some discussion for oral history)
**Add <listPerson> to the schema and documentation
**Discuss the usage of @role on person
*AR volunteers
*KH: clarifies that the prose changes can be addressed first
*SB: volunteers to address the schema changes
*SB: Birth and death should be specified
*KH: But, this would require that this information be found after the encoding has been undertaken
*KH: Rouner can either add comments to the Issue or modified the prose of the ODD

==Issue #11==
*Page breaks within notes
*KH:
**Discussed this in September
**Should include <pb> within the note
**Should use the attribute for pointing
**Should update the prose
*EM: Use a @sameAs on the page break
*KH: The note element first is referenced in level 3
*SB: Suggests including an example
*Found 200 examples using grep

*KH: Regenerating output of the ODD's
*SB: What remains is the generation of the large table (this is almost unreadable)
*Otherwise, everything seems to be properly generated
*KH: Current release of the BPTL document is found at http://www.tei-c.org/SIG/Libraries/teiinlibraries/main-driver.html
*Also, requests that SB publish a rendered version on the WWW

==Issue #12==
*No discussion of bibliographic metadata for TEI Documents
*Can use <listBibl>...
*Going to recommend the usage of this at Level 3
*Just have a <listBibl> with each entry using <bibl> without marking the components
*For Level 4 where components of entries are encoded...
*How much detail should be expected?
*SB: Title, author, and date should be prescriptive
*EM: Level 4 is full-blown, can't imagine telling users what to encode for a bibliography
*Bibliographies are so varied...but title, author, date
*KH: Emphasize use cases
*Sending this data into a separate, hosted service for parsing
*SB: Also, sorting as a use case
*EM: <bibl> contains just text within Level 3
*Level 4 has a full <bibl>
*KH: Author, title, and date are required
*<pubPlace>, <publisher>, <editor>...the remaining elements are optional
*KH: Maybe <editor> should be required
* Schema change and additions to the table are required to resolve this
*JG: Should dates be formatted using a standard?
*SB: The formatting specified by the @when attribute should be used

=Scheduling for the Next Meeting=
*March 6th, 2017 13:00 GMT-5

[[Category:Workgroup to revise the Best Practices for TEI in Libraries]]
[[Category:SIG:Libraries]]

February 13, 2017

2017-02-15T13:43:54Z

James R. Griffin III: Adding the notes captured by Griffin from the meeting held by the WG on 02/13/17

=Attendees=
* Kevin S. Hawkins (University of North Texas Libraries) (KH)
* Andrew Rouner (Washington University Libraries) (AR)
* Elli Mylonas (Brown University Library) (EM)
* Syd Bauman (Northeastern University) (SB)
* James R. Griffin III (Lafayette College Libraries) (JG)

=Ticket Triage=
*[http://wiki.tei-c.org/index.php/BP_revision_ticket_triage BP revision ticket triage]
*[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues GitHub Issues]

Summarize EM ticket work:
==Issue #21==
*Made fix to the pull request (PR) request suggested by KH
*Closed
*Can make a new PR - or perhaps the old pull request will incorporate the latest changes.

==Issue #45==
*EM made a <valList> for <div> based on notes in the Issue.
*Q: should we be abbreviating the values?
*KH: no abbreviations
*EM: Does each ODD have to be updated separately?
*KH: No ODD cascade exists
*(SB arrives)

*EM noticed Appendix A of Attribute Values ([http://www.tei-c.org/SIG/Libraries/teiinlibraries/main-driver.html#index.xml-body.1_div.6 Best Practices for TEI in Libraries, Version 3])
*Doesn’t seem helpful, doesn't specify which elements they belong to, which are mentioned in the Best Practices for TEI in Libraries (BPTL) and which are “favorites”
*KH: Didn't come from version 2.1
*EM: Try to remove this or link to element specs
*Action on EM: Create the issue

==Issue #3==
*KH: Would take this over from Peter Gorman
*Hasn't made any progress
*SB: Clarifies that this is actually labor-intensive

==Issue #42==
*KH: No progress

==Issue #37==
*SB:
*TEI needs to address this schematron issue
*Need to address the issue of possibly leaving the TEI rather than the BPTL
*Will be submitting a ticket to the TEI

==Issue #7==
*KH: No progress

==Issue #9==
*SB:
*Ticket for the schema or for the prose?
*The schema component is finished
*KH:
*If changes for both are required, they are kept in the same ticket
*SB:
*Prose should be changed
*Needs to finish, issues a call for participants
*KH:
*Enumerates all of the elements available through the TEI P5, but not all are used by the BPTL
*SB:
*Some elements are difficult to address (e. g. <stdVals>)
*KH:
*Should only scope this issue for elements included on this list now

==Issue #13==
*KH: A cataloger colleague in the UNT University Libraries is addressing this
*No update

==Issue #47==
*EM: No progress
*SB: Most of this was what was intended by the BPTL WG
*EM: Just needs to be reviewed
*KH: Lou noticed these after running a comparison
*EM: Changing content models might have unforeseen consequences
*Will review and check for questions

==Issue #36==
*KH: Written comments to be reviewed by EM

==Issue #14==
*KH: Needs to implement

==Issue #17==
*EM: SB changed the <schemaRef> and updated the examples
*SB and EM will finish collaboratively

==Issue #31==
*EM: This issue was just closed
*Pull request was opened for discussion
*KH will attempt to merge the PR

==Issue #10==
*KH:
*Indicating interviewers and interviewees
*Discussed in September, but this was postponed
*This was a suggestion for using the <listPerson> element
*Should be added to Level 4 (already some discussion for oral history)
*Add <listPerson> to the schema and documentation
*Discuss the usage of @role on person
*AR volunteers
*KH clarifies that the prose changes can be addressed first
*SB volunteers to address the schema changes
*SB: Birth and death should be specified
*KH: But, this would require that this information be found after the encoding has been undertaken
*KH: Rouner can either add comments to the Issue or modified the prose of the ODD

==Issue #11==
*Page breaks within notes
*KH:
*In September
*Should include <pb> within the note
*Use the attribute for pointing
*Should update the prose
*EM:
*Use a @sameAs on the page break
*KH:
*The note element first is referenced in level 3
*SB: Suggests including an example
*Found 200 examples using grep

*KH: Regenerating output of the ODD's
*SB: What remains is the generation of the large table (this is almost unreadable)
*Otherwise, everything seems to be properly generated
*KH: Current release of the BPTL document is found at http://www.tei-c.org/SIG/Libraries/teiinlibraries/main-driver.html
*Also, requests that SB publish a rendered version on the WWW

==Issue #12==
*No discussion of bibliographic metadata for TEI Documents
*Can use <listBibl>...
*Going to recommend the usage of this at Level 3
*Just have a <listBibl> with each entry using <bibl> without marking the components
*For Level 4 where components of entries are encoded...
*How much detail should be expected?
*SB: Title, author, and date should be prescriptive
*EM: Level 4 is full-blown, can't imagine telling users what to encode for a bibliography
*Bibliographies are so varied...but title, author, date
*KH: Emphasize use cases
*Sending this data into a separate, hosted service for parsing
*SB: Also, sorting as a use case
*EM: <bibl> contains just text within Level 3
*Level 4 has a full <bibl>
*KH: Author, title, and date are required
*<pubPlace>, <publisher>, <editor>...the remaining elements are optional
*KH: Maybe editor should be required
*Schema change and additions to the table
*Date format handling
*@when attribute should be used

=Scheduling for the Next Meeting=
*March 6th, 2017 13:00 GMT-5

[[Category:Workgroup to revise the Best Practices for TEI in Libraries]]
[[Category:SIG:Libraries]]

December 12, 2016

2016-12-14T14:05:30Z

James R. Griffin III: Migrating the notes captured using a Google Document

=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=
*[http://wiki.tei-c.org/index.php/BP_revision_ticket_triage BP revision ticket triage]
*[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues GitHub Issues]

==Issues 21 (and 31 by reference)==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/21]
* Mylonas was assigned this issue
* Wanted clarifications in order to fix it
* Last comment regarding <pc> 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 <pc> with or without @force
* Otherwise just use <milestone> with or without @break="yes" or @break="no"

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

* Mylonas: Only care about <pc> 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 <milestone>

* Hawkins: References the 4 cases in the thread

* Mylonas: Also appropriate for #31

==Issues 43 (and 9 by reference)==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/43]
* 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==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/45]
* Mylonas assigned to this
* Adding to the issue the values which bring it all together
* Then will select which are preferred

==Issue 3==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/3]
* 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==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/42]
* Hawkins: Previously, <idno> could be a child of <biblStruct>. Council has since cleaned up the content model to no longer allow this. Now it's only allowed within <analytic>, <monogr>, or <series>
* Clarifies that <biblStruct> does require at least a <monogr> child.
* In a standard catalog record any value that would be put into <idno>, like a call number, refers to the whole bibliographic entity (the <monogr>).
* Any <note> in a record also refers to the entity as a whole.
* Reiterates that the TEI has eliminated the option to have <idno> rendered outside of <monogr>
* Hearing no objections, Hawkins will implement this.

==Issues 37==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/37]

* Item 3 from Bauman’s comment on June 6th is still unresolved
* Bauman: <gi> and <att> 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==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/7]
* 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 <xenoData> 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==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/13]
* Hawkins: Still hopes to have collaboration from a cataloger at UNT Libraries.

==Issue 27==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/27]
* 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==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/38]
* Mylonas: Is this complete?
* Bauman: Addressing the broken build process

==Issue 47==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/47]
* 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==
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/36]
* 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 <note> 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 <note> element itself [actually, you can!], so there would need to be a <ref> within the <note> 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 <ref> 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 <ref> for the prose
* Nothing stated about what to do for the symbol within the <note>
* Can use <ref>
* @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 <note>].

* 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 <ref> (implies that the siglum is right there, as the content of the <ref> element) or a <ptr/>; 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 (https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues/34)
* 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 <ref> and additional mechanisms

* Hawkins: At Level 3, leave the note where it occurs in the layout on the page, encoded the siglum in a <ref>
* 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 <label>.

[[Category:Workgroup to revise the Best Practices for TEI in Libraries]]
[[Category:SIG:Libraries]]

May 2, 2016

2016-05-05T13:35:50Z

James R. Griffin III: Fixing the broken reference

=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=
[http://wiki.tei-c.org/index.php/BP_revision_ticket_triage BP revision ticket triage]
[https://github.com/kshawkin/Best-Practices-for-TEI-in-Libraries/issues GitHub Issues]
==First Category (Ease of Implementation)==
===Issue #20===
* Mylonas is still going to handle this.

===Issues #30 and #33: milestones at <div> boundaries===
* Hawkins: The question in issue 30 actually applies not just to <milestone/> elements but also to milestone-like elements such as <pb/>. Issue #33 created to address the same question for <pb/>.
* We had previously reached consensus that you should always put <pb>s within the lowest level of the text division. However, Martin Mueller brought this topic up for discussion on TEI-L<ref name="empty elements within or between structural elements">[https://listserv.brown.edu/archives/cgi-bin/wa?A2=TEI-L;96293b6.1604 "empty elements within or between structural elements"]</ref>. Hawkins prefers to take the initial approach (our previous consensus), but he summarized the views offered in response to Mueller’s post:
* Holmes: <pb/> at the highest level of the tree consistent with division (e. g. between <div>’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 <p> or <head>—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 <div>'s. This recommendation was driven by ease of processing: we thought that enough people use systems which extract entire <div>'s at once. Putting all <pb/>’s inside a <div> 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 <div> (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 <pb/> should be inside the first <div> 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 <editorialDecl> is where such things go. Mylonas confirms this.
* Hawkins: We could, for example, allow users to specify here whether they have put <pb/>s inside the lowest or highest possible <div>.
* Hawkins: What we currently specify in <editorialDecl> 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 <pb/>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: <pb/>s should be put within the lowest-level <div>. This is just an improvement of wording, not a schema change. [Myllonas would like to see facility for documenting divergence of practice in <editorialDecl>. 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 <ref> or as an attribute value on a <ptr/> or an <ref>).
* 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 <pb/> within the <note> even though a <pb/> 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.'''

==Second Category (Ease of Implementation)==
===Issue #3: rewriting discussion of <rend> and <rendition>===
* 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 <ab>. Proposal is to clarify which this was chosen over <milestone/> or <space/>) and to add style= to the example. However, last month Martin Mueller raised the possibility of using <pc>. 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 <ref>. 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 <ref> is preferred
* Adding whole RDF graphs, need something else...but <ref> 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 <ref> 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, <ref> 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 <ref> 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 <extent>===
* Hawkins: The <extent> 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 <width> and <height> from the msdescription module as children of <extent>.
* If we recommend that these be used, it would make <extent> more machine-processable.
* Mylonas: Clarifies that the msdescription module includes not only <width> and <height> but also <depth> and <dimensions>, 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 <dimensions>
* <extent> contains <dimensions>; <height>, <width>, and <depth> are siblings
* <extent> can also encode information for pagination
* Hawkins: In the BPTL currently, we say to include two <extent> 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 <extent> 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 <height> and <width>, should there be some form of a wrapper for these, to separate them from other extent information?
* Mylonas: Confirms that <extent> does not have a type= in P5.
* Hawkins: P5 has an example where <extent> has two <measure> elements with @unit attributes. Maybe we need to consider this.
* Mylonas: Can put <dimensions> as a sibling for <measure>.
* '''Hawkins: I think I need to review and revise this approach. I might explore using <measure>.'''
* Mylonas: I think we want only one <extent> element but more than one <measure> and multiple <dimensions>.
* Hawkins: Right, <measure> has unit= and quantity=, which could be useful.

=Deadline for Minutes=
* <strike>Mylonas: 1 week for feedback</strike>
* 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.
<references/>

May 2, 2016

2016-05-05T13:19:51Z

James R. Griffin III: Publishing the notes captured and formatted for the meeting held on 05/02/16

Workgroup to revise the Best Practices for TEI in Libraries

2016-02-01T14:35:34Z

James R. Griffin III: /* Members */ Adding griffinj@lafayette.edu for "James Griffin"