- Tei-council - lists.tei-c.org

Minutes Doc
by Hugh Cayless 28 May '15

28 May '15

https://docs.google.com/document/d/1V7RB54nYMKeXPqPAGxjbKmXwViz0vLFfwzGo4Ql… <https://docs.google.com/document/d/1V7RB54nYMKeXPqPAGxjbKmXwViz0vLFfwzGo4Ql…> Stefanie, ping me on skype when you’re able to join in. /** * Hugh A. Cayless, Ph.D * hugh.cayless(a)duke.edu * Duke Collaboratory for Classics Computing (DC3) * http://blogs.library.duke.edu/dcthree/ **/

3 4

DTW-Ann Arbor ride
by Lou Burnard 28 May '15

28 May '15

Anyone else arriving about 18h15 (or as the Americans say "6.30 pm") in DTW next Weds? Interested in sharing a cab rather than waiting for the 19h45 bus (or bemoaning the departure of the 18h02 one)?

12 46

Stand-off proposal
by Martin Holmes 27 May '15

27 May '15

Very minor niggle on the stand-off spec: <https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof…> If the intention is to create a new module in TEI rather than add the new elements to an existing module, the module ident should be "standoff" rather than "stand-off", to align with existing modules ("namesdates", "textstructure"). Cheers, Martin

1 1

TEI Simple: Executive summary
by James Cummings 27 May '15

27 May '15

Dear Council, Please find attached an executive summary of the work of TEI Simple project and its proposal to Council. (The proposal really being the proto-ODDs on the github website.) Best wishes, James -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk Academic IT Services, University of Oxford

1 0

Agenda for F2F
by Hugh Cayless 27 May '15

27 May '15

Hi all, I’m putting together a draft agenda at http://wiki.tei-c.org/index.php/Council_Agenda_2015-05 <http://wiki.tei-c.org/index.php/Council_Agenda_2015-05>. Items for discussion are to be found in the Minutes Google Doc at https://docs.google.com/document/d/1V7RB54nYMKeXPqPAGxjbKmXwViz0vLFfwzGo4Ql… Please add any additional business items you have to that list. I’ll be working more on it and the agenda today and tomorrow. Martin had proposed talking about how to build the Oxygen plugin. Do we have any other possible technical talks? Anything for TEI Simple or Pure ODD, for example? Looking forward to seeing you on Thursday! Hugh

2 1

UVic Jenkins temporarily down
by Martin Holmes 27 May '15

27 May '15

Just for info: the UVic Jenkins machine is currently down because it's being cloned to create a new Jenkins build server for other projects. Should be up again soon. Cheers, Martin

1 0

Release of the Oxygen plugin
by Martin Holmes 26 May '15

26 May '15

Hi all, After some more testing with Ron, I've just released a new version of the Oxygen plugin, incorporating the latest Stylesheets release (7.35.0) and some changes to the plugin codebase that we had had to back out of before Oxygen 17 was released because they depended on Stylesheets changes which hadn't been released at that point. If you're subscribed to this version of the plugin, please let me know if you see any problems. One of the confusing issues I'll talk about when I do my little show-and-tell on the Oxygen plugin in Michigan will be version numbers. Right now, the plugin filename is derived from the P5 and Stylesheets versions incorporated in it: teioxygen-2.8.0-7.35.0.zip = P5 2.8.0 and Stylesheets 7.35.0. However, there also has to be a true version number for the plugin, which is inserted into the updateSite.oxygen XML file that handles the plugin updates for users. Oxygen's system only allows a version number consisting of three dotted digits: 1.2.3 Our practice up to now has been to name the plugin release after the P5 release on which it's based, so this would be: 2.8.0 but because the last one was already 2.8.0, I've had to increment it: 2.8.1 If we now go ahead and release a minor P5 update, which would be 2.8.1, we would confusingly have to increment the plugin version number to 2.8.2. So I'd like to suggest that we detach the plugin versioning count entirely from the P5 version, and simply increment it independently; but with the second and third digits representing collapsed versions of the P5 and Stylesheets versions on which it's based: 3.280.7350 This would mean that we could have meaningful plugin version numbers simply incrementing in position 1, and still record the versions of P5 and the Stylesheets on which they're based. Any see any problem with this? We could make the change at the same time that we switch the file naming from teioxygen to oxygen-tei, as we've discussed before. Cheers, Martin

7 14

Building (e.g. TEI All schema)
by Hugh Cayless 26 May '15

26 May '15

Can someone explain to me like I’m an idiot how to use the Stylesheets to generate, say, a TEI All schema using the Guidelines specs? I’m afraid the documentation doesn’t give me enough to go on. I thought I understood it, but I don’t. My understanding is that you use the transformtei script, but what inputs do you give it? Thanks, Hugh

6 12

Re: [tei-council] ROMA does not work
by Martin Holmes 26 May '15

26 May '15

Once the build process has gone through on Jenkins successfully, I'll test my new oxygen-tei plugin build script by doing "ant release" to see what happens. :-) Cheers, Martin On 15-05-26 09:09 AM, Sebastian Rahtz wrote: > Roma should be working again now. I made a new Stylesheets release and deployed it around. > > Many apologies for that. > > Sebastian Rahtz > Chief Data Architect > University of Oxford IT Services > +44 1865 283431 >

1 0

bad date example
by Syd Bauman 26 May '15

26 May '15

We have a single example (used twice with slight differences) that shows use of dating attributes in a way I think may be inappropriate: <residence from="1857-03-01" notAfter="1857-04-30">From the 1st of March to some time in April of 1857.</residence> I don't like the combination of @from and @notAfter. As I understand (or at least imagine) it: @from and @to: indicate a range of dates during which something happened -- the thing happens during the entire range. <persName from="1940-10-09" to="1969-04-21">Lennon, John Winston</> <persName from="1969-04-22" to="1980-12-08">Lennon, John Winston Ono</> or <occupation from="1991" to="1994">Provost, Duke University</> For the *entire period* from 09 Oct 40 to 21 Apr 69 his name was "John Winston Lennon", and for the *entire period* from the day he legally changed his name (22 Apr 69) to his death (08 Dec 80) his name was "John Winston Ono Lennon". Similarly, Tommy Langford was Provost from 1991 to 1994. We don't know what day he became Provost or what day he stepped down, so the values of @from and @to are given only to year precision. Fair enough. (If we knew more, we could provide more precision.) @notBefore and @notAfter: indicate the earliest and latest endpoints for a single event to have occurred. Typically, but not at all necessarily, that event is measured in the precision of a single day. E.g. <death notBefore="1831" notAfter="1840"/> indicates that Mary Clarke [nee Carr] died sometime between those dates. She died on one day[1] during those days, she did not spend all 9 years in the throes of death. I think these notions of @from and @to indicating a *duration* during which something happened continuously, and @notBefore and @notAfter indicating endpoints within which range something happened at a given point, is borne out by the definitions in the tagdocs: - notBefore: specifies the earliest possible date for the event - notAfter: specifies the latest possible date for the event - from: indicates the starting point of the period - to: indicates the ending point of the period Thus my unease with the example <residence from="1857-03-01" notAfter="1857-04-30">From the 1st of March to some time in April of 1857.</residence> To me, the @from indicates that she lived there for a 1-2 month long period starting 01 March; but the @notAfter (at least, taken alone) implies that she lived there for one day[2] some day before 01 May. So I'm sure I don't like this, although I'm not sure how to solve the problem, i.e. how this information should be indicated. Possibilities include: * State explicitly in the prose what @from & @notAfter or @notBefore & @to mean. (To wit, an entire duration of vague length, specified by one endpoint and a point over which the duration did not extend.) * Indicate the duration with a start point and a duration, then indicate the (lack of) precision of the duration: <residence xml:id="R" from="1857-03-01" dur="P46D"> From the 1st of March to some time in April of 1857. </residence> <precision target="#R" match="@dur" atLeast="31" atMost="61"/> Don't like this as it sits, because it only works because we presume the unit @atLeast & @atMost refer to is days. Makes sense for this case, but if the dur= were "P1M15D" it would be less obvious. I presume if it were "P1.5M", one would have to use atLeast=1 atMost=2; i.e. the precision attrs apply to the lowest order component. So I guess we could make this work by making that the rule. * Fix <precision> so that it allows representation of precision (meaning the unit or number of significant digits to which a value may be measured reliably) rather than just precision (meaning vaguely how exact or accurate). Then <residence xml:id="R" from="1857-03-01" to="1857-04-15"> From the 1st of March to some time in April of 1857. </residence> <precision target="#R" match="@to" dur="P15D"/> or whatever. * Create new attributes (egads!) to mean exactly what we want. E.g., @fromAfter and @toBefore. * Don't fix it. Caveat encoder. People tend to know what you mean. Besides, what possible automated processing will handle this stuff? Notes ----- [1] Actually one second, but let's not go nuts. [2] Or only one second, but let's not go nuts.

5 8