#240 Grouping traitlike, statelike, and eventlike elements

GREEN
closed
1(low)
2013-06-17
2010-09-07
No

I have been constructing a TEI template for prosopographical records. Each record relates to a single individual. According to TEI P5 13.3.1 (Basic Principles), "Information about people, places, and organizations, of whatever type, essentially comprises a series of statements or assertions relating to ... traits, ..., states, ..., and events." I would like to use this organisational principle for each record and would therefore like to be able to group traits, states, and events within <person>, <place>, and <org> elements.

Accordingly, I request that the <list> element be allowed as a child of <person>, <place>, and <org> elements, and to allow traitlike, statelike, and eventlike elements to be children of <list>. (By the way, there is already a <listEvent> but it is not allowed as a child of <person>. )

Discussion

  • Anonymous - 2010-09-08

    I suggested <list> but another possibility would be grouping elements, say, <traitGrp>, <stateGrp>, and <eventGrp> with useful attributes such as att.canonical. Then I could do something like this:

    <person>
    ...
    <stateGrp>
    <occupation>Tinker</occupation>
    <occupation>Tailor</occupation>
    </stateGrp>
    ...
    </person>

    Another possibility would be to allow traitlike, statelike, and eventlike elements to contain themselves:

    <occupation>
    <occupation>Soldier</occupation>
    <occupation>Sailor</occupation>
    </occupation>

     
  • Lou Burnard

    Lou Burnard - 2011-03-20
    • milestone: --> 871209
     
  • Lou Burnard

    Lou Burnard - 2011-11-07

    Add listState as child of person, place, or org: with content model of model.stateLike|model.traitLike +

     
  • Lou Burnard

    Lou Burnard - 2011-11-07
    • assigned_to: nobody --> bansp
     
  • Lou Burnard

    Lou Burnard - 2011-11-07
    • status: open --> pending
     
  • Piotr Banski

    Piotr Banski - 2012-04-19

    Not so easy: there is no model that holds just state and trait. There are three separate models:

    * http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.orgStateLike.html
    [state]
    * http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.persStateLike.html
    [persName affiliation age education faith floruit langKnowledge nationality occupation residence sex socecStatus state trait]
    * http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.placeStateLike.html
    [placeName bloc country region district settlement geogName climate location population state terrain trait]

    each of them specialized (well, the 1st one is rather thin). And Tim does not want to just use state and trait for the three groupings, so aren't we actually looking at

    listOrgState
    listPersState
    listPlaceState

    ?

    I am not sure I like the direction in which this is going, but it seems to me that this would keep to the overall organizational principles of the Guidelines, would it not?

    Note also that, semantic considerations aside for a moment, these three models cannot be grouped together, because then the resulting schema is not deterministic (state comes from three different branches).

     
  • Piotr Banski

    Piotr Banski - 2012-04-19

    I've tried to implement this but now I'm going to withdraw all the changes, leaving Specs/listState.xml but removing all references to it, pending discussion.

     
  • Piotr Banski

    Piotr Banski - 2012-04-21
    • status: pending --> open
     
  • Piotr Banski

    Piotr Banski - 2012-04-22

    So what I would like to know is:

    * whether the naming listOrgState, listPersState, listPlaceState is OK with everyone
    * whether I have green light for making listEvent a child of person, place, and org

    Alternatively: do we take this to the next telco?

     
  • James Cummings

    James Cummings - 2012-09-19
    • milestone: 871209 --> GREEN
    • status: open --> open-wont-fix
     
  • James Cummings

    James Cummings - 2012-09-19

    Council feels that <link> and <linkGrp> pointing to @xml:id's on the <person> children provide a cleaner solution (with potential for conflicting lists). We should add link/linkGrp to <place> and <org> for consistency. (Oxford Face to Face 2012-09)

     
  • Piotr Banski

    Piotr Banski - 2012-10-25

    The addition of the linking elements checked in as 11013 and 11015. Ticket ready to close.

     
  • James Cummings

    James Cummings - 2013-06-17
    • status: open-wont-fix --> closed
    • Priority: 5 --> 1(low)
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks