Council

Face to face meeting - Lyon 1-3 April 2009

Local organisation - programm of the seminar

Meeting in Lyon Available abstracts under: [1]

Draft Agenda

link 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"

(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 (DS)
• Projects
• Perspective workshop on TEI for the next decade
  • Dagstuhl
  • ESF [2]
• SIGs
  • Scientific bibliographies
• 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)

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...