TEI Technical Council F2F Meeting in Buenos Aires, 6-8 October 2024

Meeting Times (Approximate)

Sunday Oct 6: 10.30 am to 6 pm

Monday Oct 7: 10am to 5 pm

Tuesday Oct 8 morning: Rectorado bldg (half day / tickets) 9:30am to 1pm

Present

Special Guest (Sunday and Monday)

Hugh Cayless

Council Members involved in conferences/workshops

RV (Tuesday morning) HBS, MT, TOC (Tuesday all day) EBB, MS, GR (Tues afternoon)

Action points for Council members

Action points resulting from tickets and issues discussed below

Collection of Topics

TEI by Example (message from Lou / Melissa Terras)

Review of Status Pending decision

(from Paderborn F2F minutes):

TEI Lite 2

TEI Website: review of our plans from Guelph: What do we wish to change / implement differently on the new website?

Guidelines PRs

Large Issues and Tickets requiring full group discussion

Ticket Triage: for small group discussion

[These are "regular" tickets, old and new, that we can discuss in small groups and then reconvene for full Council discussion later on

Triage Groups
A: TOC, HC, MS

B: RV, JT, TR

C: SB, SS, EBB

D: TEI Lite2: MT, GR, HBS

Ticket number Council Group Ticket title Discussion notes
#2345 C MS SIG request (2022): msIdentifier should be changed to allow only an idno or msName Agree with JC: we should remove the schematron constraint so that it's possible to have just an <idno>. The prose explanation of <msIdentifier> should be much clearer to indicate that an <msIdentifier> should have sufficient information for a scholar to locate the manuscript. If we apply the requested change, it will invalidate the need for #2258 (we can close that one if we proceed). Council discussion: Since MS SIG presented this, it seems reasonable (also considering we're in the age of OrcIDs etc.
#2084 and #2086 A TEI XPointer Schemes / SATS and Uber ticket for SATS HC: I contend these are done.
#2119 B teidata.interval problems [Discussed in Guelph, did not return to it in Paderborn. See Sabine's summary comment] Subgroup thinks we should move to xsd:duration (constraining the number to be positive) and deprecate old values (-1, regular, irregular, unknown). Action on RV (hence set to Pending) to write to TEI-L about removing @unit and just using @interval as xsd:duration Will require writing to TEI-L and if no major objections, setting a long deprecation period. Consider changing the explanation in the Guidelines even before the depreciation period.
#2436 C standOff should be allowed to contain xenoData Already closed
#2332 A How are we to refer to an <egXML>? (Or <figure> or <table>?) TOC: EBB has recently added guidance to TCW 24 that resolves this issue. Council subgroup agrees with using <ref> and <ptr> to point to examples. Ticket closed.
#2341 B New <entity> and <listEntity> elements are needed Subgroup likes the idea of <entity> and <listEntity> and we think there are other positive comments towards that. Is it time to have someone start working towards a proposal? We also think <listEntity> should contain other entity tags (person, etc). Remaining questions include: How is it modeled? (E.g. should it be such that more specific entities (person, event, etc.) could be mapped backwards.) Suggestion for <bioName> on ticket: subgroup disagrees because it looks like they’re trying to replicate a use case for <taxonomy> with <name type=”...” subtype=”...”>. Discussion: Should we find ways to encode <entity> that mirror what we have for <person>? What are the components of an entity? (What you need are events, states, and traits.) Is <list> and <item> (as in a generic list) what we want rather than <listEntity> or do we want/need a new list element? (Added TR to the ticket, to work with HBS and EBB on developing a content model.) Action on TR, EBB, JT and HBS to initiate this for upcoming release (+ answer the initial ticket). TOC added Council decision on ticket. Revisited by Council on 08/10: Discussion on the categorisation of <entity>. We have a <relation> element, could that be used instead of <listEntity> to hold <person>, <bibl>, <org>, <object>? Objective of <listEntity> is to convey the complexity of the novel/world etc which challenge conceptual frameworks that underpin categorisation. JT: Important consideration to keep in mind when developing the content model - is it a union of all entities? Keep entity simple: (main child elements) idno, entityName (or just name?), state, trait, event, relation, Possibility of <entity> requiring location, climate, dimensions etc. Could it contain another list for example? We'll probably have to review the different listography models Action on TR: summarize and comment in ticket. JT volunteers to work on ticket.
#2479 C 3D coordinate system by adding attributes to att.coordinated Opened Oct 23, but has not been discussed. Subgroup C likes the idea. We possibly need a new attribute class for 3D coordinates. Approach the requestors and ask how they would like to model 3D coordinates, the sequence etc., and we will work with a proposal from them. We need to understand what they need to model 3D space. (JT added to the ticket) Action on SB or EBB to write on the ticket. [Completed by EBB]
#2350 A Guidelines need a 'Cite This' or similar button on every page. Agreed. Make green. In addition to this, we should open a Stylesheets issue. Discussion: Create a related Stylesheet ticket to link to this ticket. Should this be handled by the website? (or may have implications for the website as well as epub, pdf, delivery in a declarative manner) JT added a comment to the ticket about his Zotero translator--and he can be in contact with Zotero. (Zotero button generates a citation from a TEI Guidelines page.)
#2355 B teidata.numeric values (requests a comma separator for decimal datatype) Subgroup thinks we should not allow comma in the datatype. The datatype is meant to render the value in a standardized form and float values in most programming languages are represented with dots. The rendering is typically handled by localization. If the goal is to capture how a number is written on the source, that can be handled as a text node. For example <num value="10.10" xml:lang="it">10,10</num> has all the information needed to record the source and provide localization. We don’t think it's a good idea to add bloat with a less predictable datatype and an additional attribute needed to interpret it. XSLT provides easy number formatting functions for example that always only accepts floating numbers in dot notation. SB: I agree with subgroup B, but do want to point out that implementing this is not as bad as the original poster says (and subgroup B implies by agreeing). There would be no need for an attribute to differentiate which occurrences of teidata.numeric use comma vs dot as the decimal separator. Because xsd:decimal always uses the dot as the decimal separator, and neither xsd:decimal nor the regular expression that allows for fractions uses a comma, one need only examine the value: if it has a comma, it uses comma as the separator; if it has a dot, it uses dot as the separator; if it has both, it is in error; if it has > 1 of either it is in error; if it has neither you don’t know, but don’t care. Council discussion: The declaration of teidata.numeric which can be double, decimal, or a pattern. `teidata.numeric = xsd:double
#2361 C drop the last sentence ("recommendation on atomic values") of 18.5 Subgroup ultimately agrees with Piotr's recommendation, that the simplest solution is to remove the statement, because the original restriction/caution does not matter now. Discussion: Updated to Status Go. Council agrees to implement this ticket.
#2358 A definitions in the text: markup and handling HC: <gloss> doesn’t have @ref but it does have @target. Subgroup determines that Council needs to decide on a set approach for consistency first and then implement it to resolve this issue. Discussion: We should identify all the different ways in which terms are marked (<soCalled>, etc) or pseudo-marked ("...") throughout the Guidelines. MS and SS are making a list of elements being currently used to markup definitions and terms. Issue is determining the correct approach to apply consistently. Do we use <term> and <gloss>. Potential complications: What happens when we use the same term in different contexts where contradictory glosses arise from the same terms being used in different chapters. Also what happens when the glosses and terms are taken away from the necessary context required to understand them (taken out of the chapter and displayed as an independent glossary as the OP requested). Review the use of <term> and how we are using it currently. <name> is also being used. Lots of <ident>s also. In the end, a termography will be desirable. Might not be worth glossing but it is certainly useful to review how we have encoded terms. It is an editorial question rather than an encoding question. Action: Review our usage and add guidance on TCW 24 and 20 on marking up terms and definitions consistently. MS opened ticket #2602 on outdated phrasing of (last paragraph of) the note in term.
#2367 B "typographic" (lb) vs. "topographic" (line) Subgroup thinks that “topographical” is intentional and adequate in the context of <sourceDoc> and <facsimile>. We agree that “typographical” for <lb> should be changed (because it seems too limited to print-related terminology). We think <lb> is ‘dimensionless’ and marks the semantic beginning of a new line (which may or may not be expressed topographically). Maybe we need to discuss with the group what is a LINE BEGINNING in a non-topographical way. The act of beginning writing after a constraint such as physical space running out, or a conscious decision of starting something new while continuing the text in a different location without beginning something conceptually different such as a <paragraph> or <ab>. Food for thought: https://gams.uni-graz.at/o:tei2019.180/sdef:TEI/get?context=context:tei2019.papers Discussion: <line> element to mark where it is physically lined up (the positioning on the page). Simply add "or written" to the definition of the <lb> : "typographical or written". Drop the parentheses and add “a new typographic or written line”. Drop the parenthesis and the term typographic already. Need to gloss the term topographic to clarify our meaning (the physical layout on the page). Topographic should be reserved for those using the <surface> or <zone> approach. Action on TOC: Rephrase the desc of <lb> (thanks to Gerrit): "Marks the beginning of a new topographic line" Need to update the outdated prose in the third line of note and the example in <lb> "This element is intended to be used for marking actual line breaks": change to "This element is intended to be used for marking the line beginning" JT found 14 instances of “line breaks” throughout the Guidelines after (Find search, have not searched Specs yet) MS opened ticket #2603 to update <pb>;, <cb>, <gb> and <lb> and assigned TOC and TR. Action on TOC to rewrite the note for <line> for extra clarification, since the note specifically states to not use <line> for encoding a poem yet the first example provided is of a poem being encoded using <line> (and it uses the term ‘linebreaks’).
#2363 C consistency of facsimile-model (vs sourceDoc) #2360 prevents textual content inside a line or zone. <formula> and <media> is inappropriate within <facsimile>; maybe also <front> and <back> is also irritating, but we should do some investigation of the history of why we permitted <front> and <back> . Why are <ellipsis> or <writing> allowed in this content model? The use of model.global here is suspect. Discussion: Action on SB and GR: Look at model.global and its subclasses in order to help us with this problem of being overly permissive. No need to deprecate the change if the guidelines clearly explained we shouldn't include transcriptional material. EBB has updated the ticket so it is about this work to review or revise model.global. <front> and <back> appear to have been present from the original content modeling of <facismile>, so we should not remove them. Consider a possibility of different element names for inside <facsimile> if we can't prevent transciptional elements from showing up here.
#2369 A Need to clarify the relationship between classSpec/@generate and classRef/@expand Per discussion in full Council on 2024-10-6, RV, JT, and SB will work on sorting this out as part of the <interleave> implementation. Suggest making green and letting them get on with it.
#2469 B samplingDecl gloss seems too partial to corpora [inspired by a TEIMEC 2023 paper] This was fixed a while back, but we forgot to close the ticket. We closed it.
#2463 C classes/memberOf should be ordered (att.global first, then alphabetical) SB is commenting on the ticket: Okay for JT to proceed, but we'll need a Schematron rule.
#2462 A Role taxonomies, better examples for respStmt Subgroup A decides that this is Status Go, but that we need to make it clear that different systems can be used because the examples provided use the CRediT taxonomy and MARC relator, there should be a note to resolve this prefix definition elsewhere in the document.
#2374 B make model.listLike available in front Subgroups agrees that if it’s in <back>, it should be in <front> too. RV thinks it should not be in back either and that was a mistake (except <list> and <table>).
#2373 B reconsider model.listLike Subgroup wonder if model.listLike may be split into lists that are textually list-like (e.g. listBibl, list, table as a stretch). And things that are grouping of entities so more listEntityLike. More like database tables (listPerson, listPlace, and potentially listEntity). listBibl potentially belongs to both. (see also the minutes on #2341).
#2460 C Allowing <address> inside <div> Subgroup likes permitting <address> inside <div> under certain controlled circumstances. But there may be problems with how to add it to <div>if we choose to do so with model.common. We can try adding model.common to model.frontPart (which is used by <back> and <front>).
#2459 C <address> should become member of att.typed Subgroup: Of course it should!
#2451 A place and org should claim membership of att.datable Subgroup A agrees to give James Cummings the green light to implement.
#2357 A Schematron to avoid contradictory use of @require and @except This is already green.
#2140 C Example needed to model attList for delimiting alternative groupings of attributes (EBB: I need to implement this--related to #2378)?
#2392 A Add att.canonical to <bibl> Status pending. Tasks in comment still need to be completed. It is not clear to Subgroup A why Ch3.12 needs to be moved earlier.
#2376 A Add a charters module Subgroup A suggests requesting a short proposal with descriptions of related elements and accompanying examples so that we can understand exactly what is wanted, shorter more concise descriptions of related elements rather than lengthy descriptions for each element (like how we define/describe an element in the TEI)
#2425 A Example of <desc> (as a child of non-documentation elements) is unclear Subgroup A decides to review and rewrite the definition of <desc> and to review the examples to ensure that <desc> is being used consistently.
#2434 A rephrasing of gloss and description of <msName> Subgroup A agrees with James Cummings’ proposed rewriting of the description and SB’s comment about gloss. Updated status to “Go” to correct the gloss of <msName> according to SB’s guidance and to use JC’s updated description.
#2438 A Do lit review and update examples in 20.5, non-XML-based approaches Subgroup agrees the chapter is stale and could use a revisit. Can a group be tasked to work on it? That should be a new issue!
#2601 C Ruby: additional features? Subgroup: The encoder should try nested ruby structures for the multiple translations.