Hi Lou (and council and MartinM), I was tasked making a Simple version of person/place/org for inclusion in TEI Simple headers. My proposal is below, but includes one currently non-conformant change: allowing the <name> element in person/place/org (persName/placeName/orgName are allowed respectively). We don't want to add those other forms to TEI Simple, but need some way to provide the standardised name in all of these named entity elements. I wouldn't want TEI to be non-conformant, so it would need to be added to person/place generally -- it is already in org for some reason so doing this would provide more equivalence between the named entity elements. My proposal is interspersed with bits of ODD for Lou to take into the Simple ODD if he agrees. Overall elements I've cut down to what I view as the minimal number elements for providing basic person/place/org information. I added to existing elements: <moduleRef key="namesdates" include="event location state person place org"/> <moduleRef key="corpus" include="settingDesc particDesc"/> <classRef key="model.personLike"/> <classRef key="model.placeLike"/> So that is event, location, state, person, place, and org from the namesdates module, and settingDesc and particDesc (for the place to put these people/place/org) from the corpus module. In most cases specialised elements inside person/place/org can be modelled with note (already in simple) and state. I've provided an exemplum for each of person/place/org. I've also suggested removing the alternation with model.pLike elements. Which would mean if you are doing TEI Simple then you can't just bung a paragraph in, but have to provide at least one element inside (such as <name>). This fits with the TEI Simple idea of trying to only have one way of doing things. Likewise for simple uses I've deemed listPerson, listPlace, listOrg as unnecessary. In the case of attributes, the elements should be a member of whatever att.global classes simple uses, e.g. to get @xml:lang/@xml:id but I would remove att.editLike but retain att.sortable and att.typed (on org/place, people aren't already allowed to be typed... though I might argue against that) I'd retain any locally defined attributes. (e.g. @age/@role/@sex on person, since they can be used instead of some child elements) PERSON <elementSpec xmlns="http://www.tei-c.org/ns/1.0" module="namesdates" ident="person" mode="change"> <!-- It should be a member of whatever att.global classes simple uses, e.g. to get @xml:lang/@xml:id but I would remove att.editLike but retain att.sortable I would retain the locally defined attributes of @role, @sex, and @age --> <classes mode="replace"> <memberOf key="model.personLike"/> <memberOf key="att.sortable"/> <!-- att.global gets too much. All I'd recommend is xml:lang, xml:id, n; ana; cert, resp; corresp; for person/place/org --> </classes> <!-- I would only allow name, bibl, state, event, idno, bibl, and note. Except for name, that is a subset of current content model. I'd remove optional alternation with pLike --> <content> <alternate minOccurs="1" maxOccurs="unbounded"> <!-- name is currently *not* allowed inside <person>, only <persName>. We don't want to add that back, so should we allow <name> in larger TEI? --> <elementRef key="name"/> <elementRef key="bibl"/> <elementRef key="state"/> <elementRef key="event"/> <elementRef key="idno"/> <elementRef key="note"/> </alternate> </content> <exemplum> <egXML xmlns="http://www.tei-c.org/ns/Examples"> <person xml:id="SPQR" age="61" sex="m"> <name type="person"> <name type="forename">Sebastian</name> <name type="forename">Patrick</name> <name type="forename">Quintus</name> <name type="surname">Rahtz</name> </name> <event type="birth" when="1955-02-13"> <ab>13 February 1955</ab> </event> <event type="death" when="2016-03-15"> <ab>15 March 2016</ab> </event> <state type="affiliation" notBefore="1999" notAfter="2012"> <ab>Oxford University Computing Services, University of Oxford</ab> </state> <state type="affiliation" notBefore="2012" notAfter="2015" corresp="#Ox_IT"> <ab>IT Services, University of Oxford</ab> </state> <state type="nationality"> <ab>British</ab> </state> <note>The production and release process for TEI P5 was originally developed by Sebastian Rahtz for the TEI Technical Council.</note> </person> </egXML> </exemplum> </elementSpec> ORG <elementSpec xmlns="http://www.tei-c.org/ns/1.0" module="namesdates" ident="org" mode="change"> <!-- It should be a member of whatever att.global classes simple uses, e.g. to get @xml:lang/@xml:id but I would remove att.editLike but retain att.sortable and att.typed I would retain the locally defined attribute of @role --> <classes mode="replace"> <memberOf key="model.personLike"/> <memberOf key="att.typed"/> <memberOf key="att.sortable"/> <!-- att.global gets too much. All I'd recommend is xml:lang, xml:id, n; ana; cert, resp; corresp; for person/place/org --> </classes> <!-- I would only allow name, bibl, state, event, idno, bibl, location, and note. I'd remove optional alternation with pLike and nesting of org --> <content> <alternate minOccurs="1" maxOccurs="unbounded"> <elementRef key="name"/> <elementRef key="bibl"/> <elementRef key="state"/> <elementRef key="event"/> <elementRef key="idno"/> <elementRef key="note"/> <elementRef key="location"/> </alternate> </content> <exemplum> <egXML xmlns="http://www.tei-c.org/ns/Examples"> <org xml:id="Ox_IT"> <name type="org" notBefore="2012">IT Services, University of Oxford</name> <name type="org" notAfter="2102">Oxford University Computing Services, University of Oxford</name> <location> <address> <addrLine n="street">13 Banbury Road,</addrLine> <addrLine n="city">Oxford</addrLine> <addrLine n="postcode">OX2 6NN</addrLine> <addrLine n="country">United Kingdom</addrLine> </address> </location> <event when="2012"> <ab>Oxford University Computing Services, University of Oxford, merged with two other departments in 2012 to form IT Services.</ab> </event> </org> </egXML> </exemplum> </elementSpec> PLACE <elementSpec xmlns="http://www.tei-c.org/ns/1.0" module="namesdates" ident="place" mode="change"> <!-- It should be a member of whatever att.global classes simple uses, e.g. to get @xml:lang/@xml:id but I would remove att.editLike but retain att.sortable and att.typed I would retain the locally defined attribute of @role --> <classes mode="replace"> <memberOf key="model.placeLike"/> <memberOf key="att.typed"/> <memberOf key="att.sortable"/> <!-- att.global gets too much. All I'd recommend is xml:lang, xml:id, n; ana; cert, resp; corresp; for person/place/org --> </classes> <!-- I would only allow name, bibl, state, event, idno, bibl, location, and note. I'd remove optional alternation with pLike and nesting of place. As with person I would add name --> <content> <alternate minOccurs="1" maxOccurs="unbounded"> <elementRef key="name"/> <elementRef key="bibl"/> <elementRef key="state"/> <elementRef key="event"/> <elementRef key="idno"/> <elementRef key="note"/> <elementRef key="location"/> </alternate> </content> <exemplum> <egXML xmlns="http://www.tei-c.org/ns/Examples"> <place xml:lang="Bristol" type="city"> <name xml:lang="en">Bristol</name> <name xml:lang="ang">Brycgstow</name> <name type="country">United Kingdom</name> <event when="1155" type="foundation"> <ab>Royal charter granted</ab> </event> <location> <num type="geo">51.45, -2.583333</num> </location> <state type="climate"> <ab>Climate data from Bristol Weather Centre 1971 - 2000 shows an average high temperature of 7.5 - 22 degrees celcius, and an average low temperature of 2.9 - 14.3 degrees celcius.</ab> </state> </place> </egXML> </exemplum> </elementSpec> Happy to entertain modifications to this initial proposal. -James

On 15/07/16 20:25, Lou Burnard wrote:

Thanks for this James. All very clear, and moderately easy to slide into the current draft.

Thanks. Sorry for the delay in getting back to you.

However:

1. Do we REALLY want to include event, state, note as well as name ? I would have thought just name and note was enough. Otherwise, we need to explain when you use note, when event, and when state.

I would have agreed if note was datable (which, to be honest, I can see an argument for...). To me these are very different semantic categories. Naming of something, recording something happened, and recording its state, with notes for anything else. I could see an argument that we don't need event and state. (If you accept that <state type="birth" when="1955"/> makes sense.)

2. The current doc for Simple mentions only @when @calendar and @period of the datable attributes. Do we REALLY want @notBefore and @notAfter and @from and @to as well?

Interestingly, I would have got rid of @calendar and @period -- one can document in prose in the header that one is using the Julian or Mayan calendar... if you are using multiple ones in a single document then your encoding needs aren't 'Simple' in my mind. I would have said @when, @notBefore/@notAfter. Where things need @from/@to I'd probably had done something else.

3. Adding name to the content models for person etc. is, strictly speaking, a non-conformant extension. I suggest you raise a feature request so we can slip it into the next release as part of the ongoing work to rationalise the content models of ography-elements (they all currently have idno, so why not idno|name ?)

I might just raise it then. I think it makes sense as part of that general desire to rationalise them.

4. Your example is a nice way of paying respect, but I think the most likely use case envisaged for these elements in Simple-land would be to document info about fictional characters in plays etc. I'd prefer to replace the current example of the rev Opimiam etc. with the same thing done with person.

Sure, I only made it up, during a keynote at DH2016, rather than go find an actual example. As long as there is an example showing simple method for dated events, states/traits, etc. -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

Another and much easier proposal : Simple only allows you to put <p> (or <ab>) inside your <person>, <place>, <org> elements. That way you can include <name> if you want, and add as much additional waffle as you like. On 16/07/16 17:56, Lou Burnard wrote:

On 16/07/16 15:32, James Cummings wrote:

...

1. Do we REALLY want to include event, state, note as well as name ? I would have thought just name and note was enough. Otherwise, we need to explain when you use note, when event, and when state.

I would have agreed if note was datable (which, to be honest, I can see an argument for...).

The trouble is that if NOTE were datable, I'd assume that the dating related to the act of annotation, not the content. Or at the very least that it was ambiguous. A note might well contain a whole lot of chronologically distinct matters. By and large datable things are events and states, not discussions of same.

...

To me these are very different semantic categories. Naming of something, recording something happened, and recording its state, with notes for anything else. I could see an argument that we don't need event and state.

That (not going the extra mile to include event and state) was indeed my proposal. I agree that it's useful to record a name distinctly for a thing, but I am proposing that in Simple all we allow is for a bunch of notes. Of course those could be typed to distinguish ones about states from ones about events, if you like.

...

(If you accept that <state type="birth" when="1955"/> makes sense.)

Err, no it doesn't. With the possible exception of elephants, birth is not a state but an event.

...

...

2. The current doc for Simple mentions only @when @calendar and @period of the datable attributes. Do we REALLY want @notBefore and @notAfter and @from and @to as well?

Interestingly, I would have got rid of @calendar and @period -- one can document in prose in the header that one is using the Julian or Mayan calendar... if you are using multiple ones in a single document then your encoding needs aren't 'Simple' in my mind. I would have said @when, @notBefore/@notAfter. Where things need @from/@to I'd probably had done something else.

OK, happy to remove calendar and add notb4 and notAfter if that works better. @period is useful so you can say e.g. <date period="2ndEmpire"> when you dont want to be any more precise.

On name vs persName etc. see the comment I am about to add to the ticket.

If you're using <p> or <ab> you are ipso facto not structuring your data. So you can't. If you're lucky enough to have a richer <person> around, then you probably don't want to dumb down to Simple anyway. Or you will have to do the same sort of conversion as you do when formatting your <person> for display etc. Sorry, silk purses don' make very good sow's ears. On 21/07/16 19:34, James Cummings wrote:

I'm favourably inclined to this proposal. How would you recommend, inside that <ab> that one does structured data (e.g. converting from a richer <person> with <birth> <death> <event> <state> etc.)? I'm not saying one can't do it, but we should recommend if you had a <person> with a <state> or <occupation> or similar inside it, this is what you should do in Simple.

-James

On 16/07/16 17:17, Lou Burnard wrote:

...

Another and much easier proposal : Simple only allows you to put <p> (or <ab>) inside your <person>, <place>, <org> elements. That way you can include <name> if you want, and add as much additional waffle as you like.

On 16/07/16 17:56, Lou Burnard wrote:

...

On 16/07/16 15:32, James Cummings wrote:

...

1. Do we REALLY want to include event, state, note as well as name ? I would have thought just name and note was enough. Otherwise, we need to explain when you use note, when event, and when state.

I would have agreed if note was datable (which, to be honest, I can see an argument for...).

The trouble is that if NOTE were datable, I'd assume that the dating related to the act of annotation, not the content. Or at the very least that it was ambiguous. A note might well contain a whole lot of chronologically distinct matters. By and large datable things are events and states, not discussions of same.

...

To me these are very different semantic categories. Naming of something, recording something happened, and recording its state, with notes for anything else. I could see an argument that we don't need event and state.

That (not going the extra mile to include event and state) was indeed my proposal. I agree that it's useful to record a name distinctly for a thing, but I am proposing that in Simple all we allow is for a bunch of notes. Of course those could be typed to distinguish ones about states from ones about events, if you like.

...

(If you accept that <state type="birth" when="1955"/> makes sense.)

Err, no it doesn't. With the possible exception of elephants, birth is not a state but an event.

...

...

2. The current doc for Simple mentions only @when @calendar and @period of the datable attributes. Do we REALLY want @notBefore and @notAfter and @from and @to as well?

Interestingly, I would have got rid of @calendar and @period -- one can document in prose in the header that one is using the Julian or Mayan calendar... if you are using multiple ones in a single document then your encoding needs aren't 'Simple' in my mind. I would have said @when, @notBefore/@notAfter. Where things need @from/@to I'd probably had done something else.

OK, happy to remove calendar and add notb4 and notAfter if that works better. @period is useful so you can say e.g. <date period="2ndEmpire"> when you dont want to be any more precise.

On name vs persName etc. see the comment I am about to add to the ticket.