===TEI Council Feature Request assignments (October 2010)===

{| class="wikitable" border="1"
|+
| Group
| ticket(s)
| nuncle(s)
|-
| 1
|
* [https://sourceforge.net/tracker/?func=detail&aid=3060909&group_id=106328&atid=644065 3060909: add attribute for non-numeric characterisation of precision]
* [https://sourceforge.net/tracker/?func=detail&aid=3060919&group_id=106328&atid=644065 3060919: add way of expressing confidence for att.ranging values]
| GB, JN
|-
| 2
|
* [https://sourceforge.net/tracker/?func=detail&aid=3060874&group_id=106328&atid=644065 3060874: @source and @code for <faith>]
* [https://sourceforge.net/tracker/?func=detail&aid=3060867&group_id=106328&atid=644065 3060867: Grouping elements for traitlike, statelike, and eventlike elements]
| SR, LB
|-
| 3
|
* [https://sourceforge.net/tracker/?func=detail&aid=3051750&group_id=106328&atid=644065 3051750: Form of words needs to be proposed (schema langs)]
* [https://sourceforge.net/tracker/?func=detail&aid=2493417&group_id=106328&atid=644065 2493417: Ibid (idno)]
| JN, BB
|-
| 4
|
* [https://sourceforge.net/tracker/?func=detail&aid=2976715&group_id=106328&atid=644065 2976715: resp -> model.respLike in biblStruct. and other things.]
* [https://sourceforge.net/tracker/?func=detail&aid=2987832&group_id=106328&atid=644065 2987832: date within biblStruct]
* [https://sourceforge.net/tracker/?func=detail&aid=2714682&group_id=106328&atid=644062 2714682: biblScope should be in Imprint or not? (biblStruct)]
* [https://sourceforge.net/tracker/?func=detail&aid=2987241&group_id=106328&atid=644062 2987241: <monogr> and <analytic> should be allowed in <bibl>]
* Further recommendations arising from the working paper on bibliographic description
| MH, KH
|-
|rowspan=2| 5
|
* [https://sourceforge.net/tracker/?func=detail&aid=2994685&group_id=106328&atid=644065 2994685: att.global shd be explicit in ODD source]
* [https://sourceforge.net/tracker/?func=detail&aid=1933481&group_id=106328&atid=644065 1933481: @status attribute to indicate deprecated elements]
| JC, SR
|-
| colspan=2|This is a philosophical issue which just needs a vote - is att.global special or not? Making the change is relatively easy, and simplifies lots of code, but it means that a fundamental TEI magic rule is lost
|-
| 6
|
* [https://sourceforge.net/tracker/?func=detail&aid=2724992&group_id=106328&atid=644065 2724992: features for alignment of audio and video]
* [https://sourceforge.net/tracker/?func=detail&aid=2507305&group_id=106328&atid=644065 2507305: alignment and documentation of sound files]
|
|-
| 7
|
* [https://sourceforge.net/tracker/?func=detail&aid=2811239&group_id=106328&atid=644065 2811239: "object" element]
| BB, GB, EP, DP
|-
| 8
|
* [https://sourceforge.net/tracker/?func=detail&aid=2925145&group_id=106328&atid=644065 2925145: generic dating class]
|GB, SR
|-
| 9
|
* [https://sourceforge.net/tracker/?func=detail&aid=2834511&group_id=106328&atid=644065 2834511: make more spanning elements]
|LB, EP, DP
|-
| colspan=2|a) New element <document> to be added to model.resourceLike ; new
element <line> to be added to model.zonePart; new element <patch>
allowed within <surface>

Together with existing <surface> and <zone> elements, these allow theory
neutral transcription of physicality of document

b) several new elements to be added to model.pPart.transcriptional
(<mod>, <modSpan>, <metaMark>, <used>, <undo>, <redo>, <rewrite>,
<transposeGrp>, <transpose>)

These allow more detailed documentation of the writing process than
previously possible

c) New <stageNotes> within the existing <creation> element containing
new <stageNote> elements to document identified "writing stages" in
genesis of a text. New att.staged class to supply @stage attributes for
elements which can be assigned to a given writing stage

These allow marked up elements to be assigned to particular stages in
the genesis of a text, or the writing of a document, or both!
|-

}

User:LouBurnard

2010-04-13T11:15:05Z

LouBurnard: New page: Gosh, I thought I already had a page here but I don't. [http://users.ox.ac.uk/~lou]

Gosh, I thought I already had a page here but I don't.

[http://users.ox.ac.uk/~lou]

Future changes to Best Practices for TEI in Libraries

2010-04-13T10:42:37Z

LouBurnard: /* milestone element */

== milestone element ==

<code><milestone unit="typography" n="******"/></code> -- Is this TEI-conformant? Is there a better way to do this in any case?

[ This is not TEI conformant, unless you think that "*****" is a valid way of naming tsomething (here this particular milestone). I would suggest
<code> <milestone type="separator" unit="nonstructural" rend="stars"/> </code>

Or possibly
<code><space dim="vertical" extent="[whatever]" rend="stars"/></code>

Or you could use <ornament> if you have followed tite in adding it. [[User:LouBurnard|LouBurnard]]]

==The TEI Header==

* consider whether various MARC 1xx and 7xx subfields could be broken out into components of persName. If so, we'll change recommendations for persName@type.

===list of elements deleted and changed by our ODDs===

Syd's list of elements is now on a [[List_of_elements_in_P5_header_module_modified_in_ODDs_for_Best_Practices_for_TEI_in_Libraries|different wiki page]] because this page is meant for things to be addressed once version 3.0 is complete.

===Identifiers for outside metadata?===

Should we have a place in the header to indicate an identifier for an outside metadata record for the item? Examples:
* record number for the source document in the local catalog
* record number for the source document in WorldCat
* record number for this TEI document in the local catalog
* record number for this TEI document in WorldCat
Having such a link would allow a delivery system to provide an unambiguous link to this full metadata without relying on matching other information in the header like a title, ISBN, or call number.
([[User:Kshawkin|Kshawkin]])

Yes, I think we should. How about the spot where the TEI Guidelines recommend putting the code for the classification of the text (in some scheme), <tt><classCode></tt> inside <tt><classDec></tt>, or is that too much of a stretch? (—[[User:Syd|Syd]])

: During the call on 2/10/09, Syd said he no longer thinks use of <tt>classCode</tt> (and a corresponding <tt>classDecl</tt>) is a good idea. Instead, he suggested we createa new element, <tt>otherDesc</tt>, to contain elements from outside the TEI namespace for metadata not covered by the TEI header. The GBP could specify how this element is used. ([[User:Kshawkin|Kshawkin]])

NOTE: we talked about this during our conf call on 2/10/09; we decided to have a sub-group conference call on 2/17/09 to talk in more detail about this. [[User:Emcaulay|Emcaulay]]

: We didn't get to this on 2009-02-17, so we postponed to 2009-03-03. However, few people showed up, so we postponed again. As Syd put it, there are two issues to consider here:

: A. What mechanism should we use to we point from the TEI header to metadata located outside the TEI document? (For example, how do you identify a MARC, METS, or MODS record that provides additional metadata about the TEI document and/or the source document?)

: B. Should we provide a recommendation on storing non-TEI metadata within the TEI document (using a different element namespace)? For example, should we allow Dublin Core elements anywhere in the TEI header?

<hr />

Email discussions in late March 2009 and early April 2009 with Syd, Melanie, Kevin, Michelle and Glen did not reach a conclusion. Tentative plans for the future would do this sort of thing when an element has the @ref attribute:

<pre>
<author>
<persName xml:id="persName_1" ref="http://authorities.loc.gov/cgi-bin/Pwebrecon.cgi?AuthRecID=1563939&v1=1&HC=1&SEQ=20090404152214&PID=wRSbpUQ7Uptm_ypRikIdNPzF">Welles, Gideon, 1802-1878.</persName>
</author>
</pre>

except that in your example there's no @type or other method for describing the relationship between the content of <persName> and the value of @ref. P5 says that @ref "provides an explicit means of locating a full definition for the entity being named by means of one or more URIs", but we are looking for a typology of some sort for these links and need a place to indicate the type of link.

And we'd do this when there's no @ref:

<pre>
<sourceDesc id="sourceDesc_1">
[. . .]
</sourceDesc>
</pre>

for which you'd find elsewhere in the document:

<pre>
<link type="MARCsource" target="#sourceDesc_1 http://mirlyn.lib.umich.edu/F/?func=direct&doc_number=000601789&local_base=MIU01_PUB"/>
</pre>

link elements might be grouped together in one of these places:

* TEI/teiHeader/profileDesc/creation/ab/linkGrp
* 1st child of <text> last child of <text>
* TEI/text/back/div[@type='editorial']/linkGrp

<hr />

UPDATE: We'll probably use <idno> in various header elements: see https://sourceforge.net/tracker/index.php?func=detail&aid=2493417&group_id=106328&atid=644065 . In any case, we'll need to tell people how much metadata to include in TEI header if they will also have external, possibly canonical, metadata sources.

<hr />

While at the Swinburne conference with John I happen to look over his shoulder while he was encoding and I noticed his use of <tt><relatedItem></tt> in the <tt><biblStruct></tt>: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relatedItem.html.
You may have come across this already in your break-out meetings, but at a quick glance, the application seems to fit our needs:
<tt><relatedItem></tt> contains or references some other bibliographic item which is related to the present one in some specified manner, for example as a constituent or alternative version of it. John was using it in conjunction with an embedded <tt><note></tt> to provide additional context. <tt><ptr></tt> and <tt><ref></tt> are also valid within <relatedItem>. (—[[User:Mdalmau|Mdalmau]])

: this element is designed to reference a bibliographic item, not another metadata record or a single piece of metadata. So I don't think it's quite right. ([[User:Kshawkin|Kshawkin]])

<hr />

See [https://listserv.indiana.edu/cgi-bin/wa-iub.exe?A2=ind1001A&L=TEILIB-L&T=0&F=&S=&P=75 Syd's call for participation in a working group].

===extent element===

Instead of

<pre>
<extent>viii, [7]-215 p</extent>
<extent>20 cm.</extent>
</pre>

we might use elements from the msDescription module and do it this way:

<pre>
<extent>viii, [7]-215 p</extent>
<extent>
<height quantity="20" unit="cm"/>
</extent>
</pre>

Had a width been given for this item in the catalog record, in the header it would have been:

<pre>
<extent>viii, [7]-215 p</extent>
<extent>
<width quantity="30" unit="cm"/>
<height quantity="20" unit="cm"/>
</extent>
</pre>

== providing stylesheets ==

providing stylesheets for header-MARC and header-MODS

: [http://www.blackmesatech.com/ Black Mesa Technologies] has undertaken this work for us (gratis)!

== providing tools ==

providing tools for workflows

[[Category:SIG:Libraries]]

Future changes to Best Practices for TEI in Libraries

2010-04-13T10:41:40Z

LouBurnard: /* milestone element */

== milestone element ==

<code><milestone unit="typography" n="******"/></code> -- Is this TEI-conformant? Is there a better way to do this in any case?

[ This is not TEI conformant, unless you think that "*****" is a valid way of naming tsomething (here this particular milestone). I would suggest
<code>
<milestone type="separator" unit="nonstructural" rend="stars"/>
<space dim="vertical" extent="[whatever]" rend="stars"/>
</code>

Or you could use <ornament> if you have followed tite in adding it. [[User:LouBurnard|LouBurnard]]]

==The TEI Header==

* consider whether various MARC 1xx and 7xx subfields could be broken out into components of persName. If so, we'll change recommendations for persName@type.

===list of elements deleted and changed by our ODDs===

Syd's list of elements is now on a [[List_of_elements_in_P5_header_module_modified_in_ODDs_for_Best_Practices_for_TEI_in_Libraries|different wiki page]] because this page is meant for things to be addressed once version 3.0 is complete.

===Identifiers for outside metadata?===

Should we have a place in the header to indicate an identifier for an outside metadata record for the item? Examples:
* record number for the source document in the local catalog
* record number for the source document in WorldCat
* record number for this TEI document in the local catalog
* record number for this TEI document in WorldCat
Having such a link would allow a delivery system to provide an unambiguous link to this full metadata without relying on matching other information in the header like a title, ISBN, or call number.
([[User:Kshawkin|Kshawkin]])

Yes, I think we should. How about the spot where the TEI Guidelines recommend putting the code for the classification of the text (in some scheme), <tt><classCode></tt> inside <tt><classDec></tt>, or is that too much of a stretch? (—[[User:Syd|Syd]])

: During the call on 2/10/09, Syd said he no longer thinks use of <tt>classCode</tt> (and a corresponding <tt>classDecl</tt>) is a good idea. Instead, he suggested we createa new element, <tt>otherDesc</tt>, to contain elements from outside the TEI namespace for metadata not covered by the TEI header. The GBP could specify how this element is used. ([[User:Kshawkin|Kshawkin]])

NOTE: we talked about this during our conf call on 2/10/09; we decided to have a sub-group conference call on 2/17/09 to talk in more detail about this. [[User:Emcaulay|Emcaulay]]

: We didn't get to this on 2009-02-17, so we postponed to 2009-03-03. However, few people showed up, so we postponed again. As Syd put it, there are two issues to consider here:

: A. What mechanism should we use to we point from the TEI header to metadata located outside the TEI document? (For example, how do you identify a MARC, METS, or MODS record that provides additional metadata about the TEI document and/or the source document?)

: B. Should we provide a recommendation on storing non-TEI metadata within the TEI document (using a different element namespace)? For example, should we allow Dublin Core elements anywhere in the TEI header?

<hr />

Email discussions in late March 2009 and early April 2009 with Syd, Melanie, Kevin, Michelle and Glen did not reach a conclusion. Tentative plans for the future would do this sort of thing when an element has the @ref attribute:

<pre>
<author>
<persName xml:id="persName_1" ref="http://authorities.loc.gov/cgi-bin/Pwebrecon.cgi?AuthRecID=1563939&v1=1&HC=1&SEQ=20090404152214&PID=wRSbpUQ7Uptm_ypRikIdNPzF">Welles, Gideon, 1802-1878.</persName>
</author>
</pre>

except that in your example there's no @type or other method for describing the relationship between the content of <persName> and the value of @ref. P5 says that @ref "provides an explicit means of locating a full definition for the entity being named by means of one or more URIs", but we are looking for a typology of some sort for these links and need a place to indicate the type of link.

And we'd do this when there's no @ref:

<pre>
<sourceDesc id="sourceDesc_1">
[. . .]
</sourceDesc>
</pre>

for which you'd find elsewhere in the document:

<pre>
<link type="MARCsource" target="#sourceDesc_1 http://mirlyn.lib.umich.edu/F/?func=direct&doc_number=000601789&local_base=MIU01_PUB"/>
</pre>

link elements might be grouped together in one of these places:

* TEI/teiHeader/profileDesc/creation/ab/linkGrp
* 1st child of <text> last child of <text>
* TEI/text/back/div[@type='editorial']/linkGrp

<hr />

UPDATE: We'll probably use <idno> in various header elements: see https://sourceforge.net/tracker/index.php?func=detail&aid=2493417&group_id=106328&atid=644065 . In any case, we'll need to tell people how much metadata to include in TEI header if they will also have external, possibly canonical, metadata sources.

<hr />

While at the Swinburne conference with John I happen to look over his shoulder while he was encoding and I noticed his use of <tt><relatedItem></tt> in the <tt><biblStruct></tt>: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relatedItem.html.
You may have come across this already in your break-out meetings, but at a quick glance, the application seems to fit our needs:
<tt><relatedItem></tt> contains or references some other bibliographic item which is related to the present one in some specified manner, for example as a constituent or alternative version of it. John was using it in conjunction with an embedded <tt><note></tt> to provide additional context. <tt><ptr></tt> and <tt><ref></tt> are also valid within <relatedItem>. (—[[User:Mdalmau|Mdalmau]])

: this element is designed to reference a bibliographic item, not another metadata record or a single piece of metadata. So I don't think it's quite right. ([[User:Kshawkin|Kshawkin]])

<hr />

See [https://listserv.indiana.edu/cgi-bin/wa-iub.exe?A2=ind1001A&L=TEILIB-L&T=0&F=&S=&P=75 Syd's call for participation in a working group].

===extent element===

Instead of

<pre>
<extent>viii, [7]-215 p</extent>
<extent>20 cm.</extent>
</pre>

we might use elements from the msDescription module and do it this way:

<pre>
<extent>viii, [7]-215 p</extent>
<extent>
<height quantity="20" unit="cm"/>
</extent>
</pre>

Had a width been given for this item in the catalog record, in the header it would have been:

<pre>
<extent>viii, [7]-215 p</extent>
<extent>
<width quantity="30" unit="cm"/>
<height quantity="20" unit="cm"/>
</extent>
</pre>

== providing stylesheets ==

providing stylesheets for header-MARC and header-MODS

: [http://www.blackmesatech.com/ Black Mesa Technologies] has undertaken this work for us (gratis)!

== providing tools ==

providing tools for workflows

[[Category:SIG:Libraries]]

Talk:Best Practices for TEI in Libraries

2010-04-13T10:26:03Z

LouBurnard: /* appInfo and application */

The following are revisions to make to the BP before making an official "release". There is a separate list of [[Future changes to Best Practices for TEI in Libraries]].

= Dependent upon pending revisions to Tite =

== Add Tite as Level 3.5 ==

This was [[Minutes_from_November_14%2C_2009#Harmonizing_TEI_Tite_with_the_Best_Practices:_Is_it_worth_pursuing.3F|strongly recommended by Daniel Pitti]] in Ann Arbor because he felt certain that administrators and funders would be confused about the difference between TEI Tite and the Best Practices ("don't the libraries already have a TEI customization?"); in fact, Kevin has known this same confusion to arise among TEI Council members. While we have a section of the BP discussion its relationship to Tite, by having a Level 3.5, we can be more explicit about mapping between the two.

Naturally we will not be able to describe Tite the way we do other levels -- by simply saying "all the elements in the previous levels, plus the following". Tite uses different element names of all sorts. There's no point in having Syd make an ODD for Tite since one already exists. So what Kevin envisions here is a sort of "sidebar" about Tite, inserted between Levels 3 and 4 that discusses Tite in a bit more detail than we currently have in the beginning of the BP, with particular discussion of mapping between the two.

Would someone be willing to write a first draft of all of this? Two paragraphs are already written for you, and you can pull more information from Tite's discussion of an earlier version of the Best Practices.

== Revise section on hyphenation ==

Revise the section on hyphenation per outcome of the discussion on TEI-L and perhaps also on how this is handled in the ongoing Tite revisions.

= Other issues to resolve before releasing =

== Test ODDs and schemas derived from them ==

Test Syd's ODDs and schemas derived from them: http://bauman.zapto.org/~syd/temp/BestPractices/ . Just go to that URL, download the .rng files, and create a new XML document based on the schema. So if it allows you to insert all the elements you expect to be able to insert. Syd has been asked to make the following changes:

* in header ODD, allow only a structured <publicationStmt>
* lib1.rng: <oXygen/> says "Errors encountered: Probably no start pattern found".
* The only allowed child of front, body, or back *at any level* should be a div.
* note should not be allowed at in Level 1 or Level 2
* ab should be the only child allowed of any div (in both Level 1 and Level 2). This element seems to be missing from the schema.
* floatingText is missing in Level 3 or Level 4 schemas.

== Use of any P5 attributes ==

Determine whether to change the prose of the BP to say that you can use any attribute you find in P5 for elements within <text> (as opposed to in <teiHeader>, where Kevin believes we've settled on using just the attributes given in the BP section on the header).

== Direction of pointing between note references and notes themselves ==

Decide whether to change back to having <ref> point to <note> instead of <note> point to <ref>, as Syd recommended. See this ticket:

https://sourceforge.net/tracker/?func=detail&aid=2796148&group_id=106328&atid=644062

and this change to the Guidelines:

http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=6937&r2=6936&pathrev=6937

or, for the full story, see Kevin's email from Nov. 6 and previous quoted messages.

== meeting element ==

Decide whether to include <meeting> in sourceDesc/biblStruct/monogr/ and/or in titleStmt. (Per a change on 2010-01-15 in SourceForge, meeting is now allowed in titleStmt.) As Kevin discussed in an email sent on Oct. 12, the name of a meeting is usually included in a MARC record, but it's not distinguished from an author or editor in the same way TEI divides up the world. The essential question is: if you digitize a volume of conference proceedings, is the name of the meeting, as opposed to the title of the volume, really important enough to warrant inclusion in the TEI header? If so, we need to wrestle with the questions Kevin brought up on Oct. 12.

== appInfo and application ==

Decide whether to include <appInfo> and <application> in our header recommendations. In email discussions, Syd saw them as useful, but Lisa didn't think we need them.

[Comment from Lou: There is at least one proposal forthcoming for further work on defining the scope and usage of these elements, which have not yet reached the degree of stability desirable for inclusion in a BP document, imho ]

FS2Latex

2009-09-24T09:07:31Z

LouBurnard:

Eric De la Clergerie [http://pauillac.inria.fr/~clerger/] has produced a demonstration conversion tool for transforming files containing TEI ISO Feature Structure notation into LaTeX and thus into printable form, using the conventional matrix layout fpor feature structures. This comprises an XSLT 1.0 stylesheet for rendering the TEI-XML into LaTeX, and a LaTeX style file. The whole suite is downloadable from [[Media:FS2Latex.zip]]

FS2Latex

2009-09-24T09:03:05Z

LouBurnard: New page: Eric De la Clergerie has produced a demonstration conversion tool for transforming files containing TEI IXO Feature Structure notation into LaTeX and thus into printable form, using the co...

Eric De la Clergerie has produced a demonstration conversion tool for transforming files containing TEI IXO Feature Structure notation into LaTeX and thus into printable form, using the conventional matrix layout fpor feature structures. This comprises an XSLT 1.0 stylesheet for rendering the TEI-XML into LaTeX, and a LaTeX style file. The whole suite is downloadable from [[Media:FS2Latex.zip]]

File:FS2Latex.zip

2009-09-24T08:56:55Z

LouBurnard: This zip archive contains a sample TEI XML file, a stylesheet to render it into latex, the outputs produced from that in PDF, and a Makefile to run the whole process.

This zip archive contains a sample TEI XML file, a stylesheet to render it into latex, the outputs produced from that in PDF, and a Makefile to run the whole process.

FStoLatex

2009-09-23T11:27:31Z

LouBurnard: New page: Eric de La Clergerie has made a suite of XSLT stylesheets which transform documents using TEI-ISO Feature Structure annotations into LaTeX for printing in conventional matrix format. The s...

Eric de La Clergerie has made a suite of XSLT stylesheets which transform documents using TEI-ISO Feature Structure annotations into LaTeX for printing in conventional matrix format. The suite can be downloaded here.