Council

The TEI Technical Council, often referred to as 'TEI Council' or 'Council' is the elected body that is responsible for maintaining and implementing the TEI Guidelines. Also see the Council section of the TEI-C website for archived documents, and TEI-Council-FAQ for a Council FAQ

F2F meeting - Paris 7-9 Nov. 2011

Location: Inria, 23 avenue d'Italie, Paris

Agenda

Monday 7 - 10.00 - 17.00

• organisational:
  • 9:30: breakfast
  • 12:30: lunch at Pizzeria Via Italia (Pizzeria Via Italia - 21, avenue d'Italie - 01 42 16 97 89)
  • 15:30: coffee break
• topical
  • Review of FRs / Bugs
  • Genetic Work

Tuesday 9 - 9.00 - 17.00

• organisational:
  • 10:00: coffee break
  • 12:30: lunch at restaurant de L'Avant-Goût (L'avant Goût - 26, rue Bobillot - 01 53 80 24 00)
  • 15:30: coffee break
• topical
  • FRs / Bugs
  • EEBO stuff - with Brian L Pytlik Zillig
  • floating objects...

Wednesday 10 - 9.00 - 16.00

• organisational:
  • 10:00: coffee break
  • 12:30: lunch at restaurant de L'Avant-Goût
  • 15:30: coffee break
• topical
  • Wiki access restrictions
  • Magic tokens
  • P4 survey
  • Planning priorities for next year

Minutes from FTF November 2011

Minutes/notes Paris 2011 Meeting November 7 2011

Present: Laurent Romary (LR) Brett Barney (BB) Lou Burnard (LB) Elena Pierazzo (EP) Kevin Hawkins (KH) Piotr Bański (PB) James Cummings (JC) Martin Holmes (MH)

Remote: Stuart Yeates (SY)

LB will record details of decisions on SF tickets, and occasionally implement changes where they're straightforward.

We will do technical work in the mornings and brainstorming in the afternoons.

MORNING: GREEN TICKETS

Review of Green bugs and FRs discussed previously by email:

FRs:

3415411: Split certainty/precision/respons from model.glossLike. Straightforward ticket: LB will do it and close ticket.

3411906: Ticket was already implemented by LR. Ticket now closed.

LR commented that he would like to see many people in the community implement tickets in future, based on OK from Council.

3408683: hyphenation section doesn't reference pc@force. Decided, and MH has already proposed wording. MH will implement and close ticket.

3296398: add hi to figDesc. Looks trivial, but actually quite complicated. SR's comments make sense. LB volunteers to test whether SR's proposal works.

3293070: enhancement of notes and examples in ref-del. EP disagrees with KH's comment; she maintains that there is a difference between <gap reason="deleted"> and <gap reason="cancelled">. So "deleted" needs to be added to the list as well. GB will be asked to implement the proposed changes.

3282689: replace 'file' with 'document'. Even SY agrees that it might not be worth it to implement the ticket; anyone can replace individual usage where they come across it. The ticket will be closed.

3275613: make textLang usable in bibliographies. Proposal now is to move <textLang> to core, and move all the corresponding discussion of the element. LB objects a bit because core is too big, but that's a different issue. JC will actually implement it.

3266021: dictionary entries with a single sense. LR says this is a consistent repeated request from users. LB is unconvinced; PB thinks that much broader changes must be undertaken in the dictionaries module in the future, and is uneasy with this because of his practice of building up markup progressively. Nevertheless, it will be implemented; KH will do it, and will leave in one example of the practice we now deprecate (not using <sense>), so as not to absolutely de-legitimate it.

3210946: examples for digital facsimile. We will defer this until we talk about the genetic module.

3064014: provide suggested values for rs@type. Over objections by SR and LB, the Council agree that it's a good idea in any discussion of @type-like attributes to provide a pointer to an existing ontology or taxonomy. We have a current practice in which syntactic sugar @type values are taken from the names of the corresponding elements; we should express this clearly under @type's explanation. There should also be a comment on the general definition of @type to the effect that we recommend the use of existing taxonomies where suitable. We should also ensure that all our examples in the Guidelines are consistent with this practice, so one example in 3.5.1 needs to be changed ("organization" -> "org"). However, rs defines its own @type, so the same text needs to be added there. The reference to the BBN taxonomy belongs in rs/@type, not the general @type. KH will implement this.

3051750: choice of schema language when using the TEI. The only comments are against the ticket, and KH was initially OK with closing it unimplemented, but the general sense of the Council is that there should be some information about the various advantages and disadvantages of particular schema types. He believes this belongs in 23.3.2. LB points out that there is a basic discussion in the General Introduction. LB suggested a rewording of the second para or 23.3.2, moving the first sentence after the second, and modifying it somewhat. A broader discussion belongs elsewhere, either a wiki page or Roma. The consensus is that it belongs in Roma, on the Generate Schemas page; SY suggests it should take the form of a link to a Wikipedia page. JC will write the sentence, and insert it into Roma.

3046288: allow f to contain pcdata. LR will implement this, getting examples from documents created by the group requesting the change.

3041605: update list of Council members. The Council agrees that the current list of members should be updated, and that a complete list of current and former Council members should be maintained and included in the Guidelines. KH will collect info from LB and elsewhere to create the list, and MH will then take over to create a more robust and formal collection of info based on a <listPerson>; a template <person> can be sent out to TEI-L. LB reminds us about privacy concerns.

BUGS:

343221: i18n revision due. Deferred in favour of a broader discussion of translations.

3400295: Inconsistent definitions for some elements. MH will provide LB with examples of <label> used to mark topic transition in prose text.

3304622: invalid xml:lang= values. EP and PB: We must use two-letter codes where they exist, and where they don't, three-letter codes can be used; locations should be in upper-case. PB will recheck Syd's list and fix all bad examples.

3289073: many missing references in guidelines. SY will implement; KH will handle the three references he added.

3285020: irregularities in <gram> syntatic sugar variants. LR suggests that we create a new attribute class for dcr:datcat, apply it to all the model.gramPart elements, and then wait for other requests for the same attribute. PB will implement this, and make a list of other elements that might also want it (in collaboration with the linguistic sig).

3223544: use of head and p within figure. Solution: remove "Figure 1: " from the second example, to reduce confusion. LB has implemented and closed the ticket.

General discussion: Who should assign colours to tickets? At the moment it's LB who assigns colours, but others could/should. The submitter shouldn't, but the first commenter perfectly well could. For clarification:

GREEN: It's clear what needs to be done, or is being requested. AMBER: It's not yet clear what action is requested. RED: It's completely unclear what's being requested or suggested.

AFTERNOON: AMBER TICKETS

3423687: a general purpose <description> alongside traits/states. LR, PB: The proposal for a new <description> element is rejected. However, there is still an issue to deal with. <trait> and <state> are essentially the same, the only difference being ontological (essential vs incidental). The content model is the same, and they are both timed. In the long run, we would want to keep <trait> only, and when you need to differentiate essential and incidental, you rely on the @type attribute, and the possible temporal attributes you may use to limit applicability. Should we deprecate <state> in favour of <trait>; or use the Guidelines text to explain that if you're confused about the difference, use <trait>, and that <state> is syntactic sugar for <trait type="state">? We recommend that <trait> is the default element to represent semantics of properties etc.; this will require an adjustment to the definition of <trait> to make it broader, so that it can be used for temporally-bounded characteristics. After some discussion, we decided that <state> makes a more obvious default, because it can handle both temporal and non-temporal properties. So: in immediate response, we will suggest <state> as the default choice, purify the <trait> examples in the Guidelines to remove the temporal attributes, check all the <trait> examples to see which need to be changed to <state>, and raise a new ticket to consider the merging of model.traitLike into model.stateLike. During this discussion, LB admitted to disagreeing with PB by pure reflex, with no justification whatsoever. He later agreed with him without justification as well, to redress the balance.

3412198: JC, MH: make listPerson and listOrg member of model.personLike. We should add <listPerson>, <listPlace> and <listOrg> to <org>; and add <listOrg> to <particDesc>. LB suggested creating a new model.orgPart, which would make the changes to <org> simpler, and adding <listOrg> to the content model of <particDesc>. LB will implement it.

3408897: KH, EP: @role for <publisher>. To deal with this ticket, we should allow <respStmt> within <imprint>. We would then have ways to handle more than just publisher-like roles within <imprint>. This requires broadening the definition of <resp> and <respStmt> to allow them to apply to organizations. We should also consult with the workgroup who looked at physical bibliography for more guidance on requirements in this area. LB objected that there was little distinction in the past between the functions we now distinguish (printer, bookseller etc.>); EP objected that this is certainly not the case for early printed books, and gave examples. The Council decided that KH & EP's solution should be implemented, and MH will implement it.

3311604: att.coordinated language. BB, LB: Point 2 is agreed: we need more examples of @start. Point 1: should be rejected because we can think of good use-cases where both may be required; Point 3: We can't really make much sense of the comment, except that we do need more examples of the use of @points. MH will look for (or create) more examples of @start and @points.

3086675: Expand note on <availability>. Assigned to MH to finish implementation.

3113682: make ptr & ref member of att.internetMedia. Assigned to MH to finish implementation.

2834511: Add more elements to att.spanning with schematron constraint. LR, JC: This introduces a parallel method of doing spanning for elements (<add>,

) which already have a method (<addSpan> and <delSpan>), so it's unlikely that anyone would have a need for it right now, unless we implement it for all of model.pPart.transcriptional. Everyone likes the longer-term vision of implementing spanning through att.spanning being added to many elements, but is unwilling to implement only a part of it that gives us nothing new. A working group of GB, BB and LB will go away and a) check which elements they believe should be included, and b) write an explanation of what it means when these spans cross element boundaries such as

. 2925145: Generic dating class. MH, KH: This ticket has a detailed implementation strategy, which was only waiting on the implementation of two other tickets before it could proceed; those have now been done, so it should be implemented. The new objection by ianrons is basically that up to now, people have been abusing @calendar because @datingMethod did not exist, so these two attributes may be confused; our response would be that now @datingMethod will be available, there is no need to abuse @calendar, and existing abuses can be fixed, or not, at the discretion of their perpetrators. Assigned to GB to implement. 3060867: Grouping traitlike, statelike, and eventlike elements. LB, PB: We should create a new <listState> element, to be added to the content models of <person>, <place> and <org>, and which would have a content model of model.stateLike (assuming that's the one we recommend in the other ticket). Assigned to PB for implementation. 3393244: simplify content model of <subst> to add and del only. EP, BB: This ticket arose out of an old ticket which was previously discussed and assigned to JC, but was not implemented. The proposal is to deprecate the current model of <subst> (model.pPart.transcriptional); create a new content model that allows only <add>, and milestone elements (starting with adding the milestones, removing model.pPart.transcriptional and replacing it with the individual elements, and then removing the others at the expiry of the deprecation period); and create <substJoin> to allow the grouping of a range of elements. The Council gradually came round to the view that we should actually remove model.pPart.transcriptional elements now, and avoid the deprecation period, because the original inclusion of those elements was wrong, and therefore this is a bug and should be fixed. GB suggests we should actually use this as an exercise to work out how we should do deprecation. In the end we came down in favour of implementing it right now. GB will implement it.

F2F meeting - Chicago 11-13 April 2010

Agenda

Most of the three days will be dedicated to expediting SF tickets. In between we have the following items to consider for discussion.

• Automating guidelines production (Presentation by Sebastian, Tuesday morning)
• Presentation on editing the Guidelines (Lou cf. http://www.tei-c.org/Activities/Council/Working/tcw20.xml)
• TEI and Google: report from Martin M. and strategy
• TEI for publishing - next steps (reports from Lou (revues.org+PUC), Kevin for TEI PUB SIG?)
• deprecation, beta, etc.

• automatic generation of feeds/twitts from SF tickets (new ones; solved ones)

From the ongoing discussion, we may also want to discuss the following issues:

• usage of floatingText within other constructs: sp, quote, etc.

Notes

TEI and Google

very bare TEI with adequate but sparse functionalities for structural and linguistic annotation

MM: When we worked on the MONK project and prepared the various TEI P4 versions for linguistic annotation, it became immediately apparent that nobody had ever given any thought to the problems of tokenization that arose for the sqirrely ways of recording or not recording words that break at lines or pages. But the question "What should an annotatable text look like?" is an important question.

LR: cf. Kernkodierung in TextGrid - minimal token annotation (<w>)

SY Gate is a really good flexible framework that includes tokenisation, but only pretends to do XML: ( http://thread.gmane.org/gmane.comp.ai.gate.general/5257 )

KH: cf. http://purl.oclc.org/NET/teiinlibraries

Item for further consideration

• Stable URIs to discrete bits of the guidelines
• Council FR assignments

F2F meeting - Dublin 28-30 April 2010

Thursday: 9:30 - 17:00; Friday: 9:30 - 15:00 (catered lunches 12:30-13:30, coffee breaks mid-morning and mid-afternoon)

Agenda

Thursday morning

• Welcome, overview of agenda
• Wrap-up from Symposium
• First SF session (see [1])

Thursday afternoon

• Manuscript (genetic editions)
• Second SF session
• 4 p.m.: biblStruct

Friday morning

• hyphenation
• ODD - (r)evolutions
• Third SF session

Friday afternoon

• remaining issues
• prospective

Topics for discussion

• Deprecating mechanisms
• Pointing and keying - can one absorb the other? (key?, target/targets)

Minutes

Minutes of the Dublin meeting for reference

Ad-hoc committee on encoding of bibliographic citations

Ad-hoc committee on encoding of bibliographic citations

Telko October 2009

Connexion details

Call information:

Conference Room: 1349998

Skype (free): +9900827041349998

Telephone numbers:

• Domestic*

USA USA 1-201-793-9022 Canada Canada 1-201-793-9022 Long distance costs apply

• International*

Austria Austria 0820 401 15470 Belgium Belgium 0703 57 134 France France 0826 109 071 Germany Germany 01805 00 9527 Ireland Ireland 0818 270 968 Italy Italy 848 390 177 Spain Spain 902 885 791 Switzerland Switzerland 0848 560 397 United Kingdom United Kingdom 0870 0990 931

Agenda

• SF
• reworking the generic TEI-to-HTML stylesheets
• HTML5
• valList and content
• report to TEI MM

Face to face meeting - Lyon 1-3 April 2009

Local organisation - programm of the seminar

Meeting in Lyon Available abstracts under: [2]

Draft Agenda

Minutes of the October meeting for reference

• Bug and features - SF
• Focussed technical discussions
  • Placement of schematron constraints in ODD - Sebastian Rahtz
  • Discussion of "canonical way of referencing TEI element definitions"
  • Wider debate: the future of ODD

(SourceForge item 2411994) and related issue of permanent URLs for TEI documentation - David Sewell SF ID: 2411994

• • Reporting on stylesheets (SR, DOD)
    • Evolution towards XSL 2.0
      • main advantages (features) provided by a switch to 2.0
      • consequences on the TEI infrastructure; maintenance of one or two sets of stylesheets?
      • how much of this should be known by the TEI community?

• Getting started (PB)
• Projects
  • TEI - ISO
• Perspective workshop on TEI for the next decade
  • communities
    • role of TEI in research infrastructures (AC)
  • event
    • Dagstuhl
    • ESF [3]
• SIGs
  • TEI in library SIG - TEI Tite status
  • New SIG: Scientific bibliographies [4]
  • Report: TEI Manuscript[5]
• Misc.
  • Necessary work on www.tei-c.org (further rationalization of structure,

etc.)

• • In particular, status of TEI vault

http://www.tei-c.org.uk/Vault/Vault-GL.html (LB)

http://quod.lib.umich.edu/t/tei/ (Chris Powell)

Chris Ruotolo: For now, you can find older versions of the Guidelines at http://www.tei-c.org.uk/Vault/Vault-GL.html, We are in the process of moving these archival files to the current website.

Syd: They used to be at

http://www.tei-c.org/Vault/GL/P1/  [source only]
http://www.tei-c.org/Vault/GL/P2/  [source only]
http://www.tei-c.org/Vault/GL/P3/index.htm  [source in P3X/]

But I don't know where old stuff went when we moved to the new website. In any case, there are copies of P3 at:

http://quod.lib.umich.edu/t/tei/
http://etext.virginia.edu/standards/tei/teip3/

Council Telco - 21 August 2008

Minutes of the last meeting: http://www.tei-c.org/Activities/Council/Meetings/tcm39.xml

Issues for next Telco - Oct 2008

• update on SF bugs and features (Oxford)

• report to TEI MM

• naming releases/versions (tei vs. P5)

Peter Boot: tei.full - tei.components

This refers to my (PB's) question on the council list (http://lists.village.virginia.edu/pipermail/tei-council/2008/009971.html) about identification of releases and the following discussions. The difference between the two packages (tei.full - tei.components ) on SF has been clarified. Sebastian has added version numbers to generated schema’s.

Issues that remain

- do we use the SF news mechanism (a project where the latest news item dates from a year ago doesn't seem very dynamic)

- Roma shows a version number of the software, not of the TEI release that is being used

• update on SIGs + responsabilities

• placement of Schematron rules in ODD

http://lists.village.virginia.edu/pipermail/tei-council/2008/010033.html

Note to be produced by SR

• update on '"getting started"', see https://USER@tei.svn.sourceforge.net/svnroot/tei/trunk/Documents/GettingStarted (replacing 'USER' with your SourceForge username) and Getting Started

Looking for candidates:

• • 6. Choosing and installing an editor
  • 9. Getting this to work on sample of own text
  • 11. Where to go from here

Issues for next F2F

• Discussion on ODD and its evolution--Romary 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

• Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

• should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

Highlights to be brought to the TEI MM 2008

Topics (could be moved up to one F2F or Telco meeting

• Stable reference to TEI objects

(For original source of these comments, see tei-council thread Quoting a TEI Object from September 2008. DS has created a new wiki page for discussing stable references.)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e. http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page: http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we might want to consider adopting one or another of the standard systems for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to register the DOIs with one of the national registries, but some more extensive costs in human time to set up a good system for mapping from our existing nomenclature to a set of DOI identifiers. (Publishers typically use DOIs to identify individual books or journal articles, but they can be more granular: every reference page in the Guidelines could have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using DOIs for citations could simply cite a DOI. So instead of the reference for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver. (Many journal DOIs are mostly numeric but the syntax allows more human-readable names).

If we seriously want to consider an option like this, we should put out a call to the librarians/metadata gurus in our community for assistance with implementation.

Misc.

For general information concerning the council see TEI-Council-FAQ page and category reserved for use by TEI Council...