#366 rationalize content models of org and place (etc)

RED
open
1(low)
2014-01-26
2012-06-19
BODARD Gabriel
No

As discussed in ticket http://purl.org/TEI/FR/3440977, the content models of <place> and <org> are unnecessarily messy, and would benefit from being rationalized by the creation of a model.placePart and model.orgPart respectively (along the lines of model.personPart).

It might even be the case that some subset of the overlap of these three models could be defined as a smaller model (entityPart?) that all such elements would inherit (containing, e.g., idno), so that any new entityLike element in future can inherit them as a quick start.

While we're at it, we should look at whether we can also create *Part models for the elements <object>, <event> and <nym>, all of which arguably want to inherit <idno> for the same reason as person and place; all can have names, bibliography, relations, etc.

Related

Bugs: #624
Feature Requests: #503

Discussion

<< < 1 2 (Page 2 of 2)
  • James Cummings
    James Cummings
    2013-11-19

    • Group: AMBER --> RED
    • Priority: 5 --> 1(low)
     
  • James Cummings
    James Cummings
    2014-01-26

    Just adding a note that as part of this rationalization perhaps org and place should get att.datable? It seems strange to me that it is difficult to say that this organisation existed from X to Y.

     
  • Martin Holmes
    Martin Holmes
    2014-01-26

    A thousand times yes. And before anyone protests that placeName and orgName are att.datable, this is a different thing: an org may exist from 1950 to 1990, and have different names from 1950 to 1960, then from 1960 to 1990. We need both. Ditto for places.

     
  • Lou Burnard
    Lou Burnard
    2014-01-26

    Making them datable or not seems of lesser importance to me than getting their content models straightened out. For the record, I believe the decision to make org, person, place NOT datable was a conscious one: they are grouping elements, and you would look at their child elements (all of which are datable) to decide what the relevant dates should be. An org that is founded in 1860 should have an <event type="founding"> for example. Likewise, if you allow <person> or <place> to be datable you introduce the possiblty of a contradiction between the dates on it and (say) on birth and death children. And anyway it's nonsense: a person entity does not cease to exist when they die -- you might still give them a new name, for example.

     
    Last edit: Lou Burnard 2014-01-26
  • Martin Holmes
    Martin Holmes
    2014-01-26

    I would see the addition of att.datable as a simple, clean alternative to the often-unwanted overhead you would have to invoke to handle this stuff with event elements and similar things. There are always convoluted ways to do things, but simple and easily-comprehensible ones are also worth having.

    As far as the person issue goes, it's a quasi-religious issue to decide whether a person continues to exist after they die, but assuming for the moment that they do cease to exist, how does that prevent you from giving them a new name with dates subsequent to their demise? I don't see any contradition.

     
  • James Cummings
    James Cummings
    2014-01-26

    Hrmmm. Maybe the att.datable for person/place/org should be a separate ticket then. (While I like it for convenience sake, it shouldn't get in the way of rationalising the content models of person/place/org to be more coherent which is what this ticket was about. Just occurred to me while writing up some TEI exercises and thought I'd note it down somewhere. ;-) )

     
<< < 1 2 (Page 2 of 2)