#366 rationalize content models of org and place (etc)
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
Bugs: #751
Feature Requests: #503
Although I'm personally not fond of it, I think it should be mentioned that there has been some discussion on TEI-ontology-SIG about aligning person, place etc with msDesc. Cf the thread starting with https://sourceforge.net/mailarchive/message.php?msg_id=29144155
James will go away and make up a straw man proposal for rationalization of these to bring back to Council. (Oxford Face to Face 2012-09)
Ok, this isn't a strawman proposal, more like a thin gossamer spider web of a proposal. It is really my notes in thinking about it because it takes me 5 minutes _just_ to get my head around the content models of person/place/org.
The current content models, excluding attributes and attribute classes are:
person: ( model.pLike+ | ( model.personPart | model.global )* )
place: (model.headLike*, ((model.pLike*) | (model.labelLike | model.placeStateLike | model.placeEventLike)*), (model.noteLike | model.biblLike | idno | linkGrp | link )*, (model.placeLike | listPlace )*
org: (model.headLike*, ((model.pLike*) | (model.labelLike | model.nameLike | model.placeLike | model.orgPart)*),(model.noteLike | model.biblLike | linkGrp | link)*, model.personLike*)
and for reference:
model.personPart: model.persStateLike [persName affiliation age education faith floruit langKnowledge nationality occupation residence sex socecStatus state trait] model.persEventLike [birth death event] idno bibl
model.nameLike: model.nameLike.agent [name orgName persName] model.offsetLike [offset geogFeat] model.placeStateLike [model.placeNamePart [placeName bloc country region district settlement geogName] climate location population state terrain trait] model.persNamePart [surname forename genName nameLink addName roleName] idno rs lang
model.labelLike: desc label
model.placeNamePart: [placeName bloc country region district settlement geogName] climate location population state terrain trait
model.placeEventLike: event
model.orgPart: listOrg listPerson listPlace
Everytime I spend 5 minutes trying to untangle this, my head starts hurting. the reason for the grouping in org and place is so you can have either <head> followed by zero-or-more <p> _or_ zero-or-more structure content, and either of those followed by zero-or-more note/bibls/embeddedPlacesOrgs/etc.
Proposal:
person/personGrp: ( model.pLike+ | (model.personPart | model.nameLike | model.global )*) -- i.e. add nameLike and simplify model.personPart or persStateLike so that it doesn't conflict with model.nameLike (e.g. remove idno and others that it will get from model.naming)
place: (model.headLike*, ((model.pLike*) | (model.nameLike |model.labelLike | model.placeEventLike)*), (model.noteLike | model.biblLike | idno | linkGrp | link )*, (model.placeLike | listPlace )*
- i.e. retain head and p vs structured distinction, replace model.placeStateLike by model.nameLike (since this contains it) Problem: idno is in nameLike and here. If we remove it, then you can't do <head> followed by <p> followed by <idno>... but this is what org is like and so would be consistent with that. If we did that (and I'd recommend it) it would look like:
place: (model.headLike*, ((model.pLike*) | (model.nameLike |model.labelLike | model.placeEventLike)*), (model.noteLike | model.biblLike | linkGrp | link )*, (model.placeLike | listPlace )* I don't think there is a backwards compatibility problem really, since we just added it in this very release.
org: (model.headLike*, ((model.pLike*) | (model.labelLike | model.nameLike | model.placeLike | model.orgPart)*),(model.noteLike | model.biblLike | linkGrp | link)*, model.personLike*) - i.e. keep the same.
A more radical proposal would be to make org/place more like name and remove the note/bibl/link things from being allowed with just prose paragraphs. i.e. if you want to do that you must use structured information. Person's content model could do with some expanding to bring it in parallel with org/place (but again without the need for embedded person).
Just thinking aloud, but would welcome any comments.
-James
Regarding expanding the content model of <person> (and <personGrp?) to bring it in line with <org> and <place>, are you thinking of adding model.headLike* to the content model of <person> (and <personGrp>)? Or something else?
@kshawkin: I'm not sure what <head> inside <person> means. (Though I see some lovely opportunities for jokes here...)
I think I was thinking about the alternative between structured and unstructured metadata object records. i.e. with <place> I can have:
<place>
<head>My favourite Place</head>
<p> Some paragraphs about it</p>
<note>Some notes about it</note>
<idno>An idno</idno>
</place>
With <person> you can basically do the same, but don't have the category of information:
( model.noteLike | model.biblLike | idno | linkGrp | link )*,
( model.placeLike | listPlace )*
which can appear after the paragraphs.
We can have paragraphs inside <person> but should you be able to have a note, bibl, or idno after those paragraphs?
-James
Sorry, wasn't subscribed to this ticket.
I think a
<head>inside a<person>is the same as a<head>inside a<place>or<org>: a heading that labels the description of the entity that follows. While in many situations that heading is simply the name, and you could therefore use one of the naming elements, you might have headings that contain something more than a name.Anyway, if we're going to allow
<note>,<bibl>, and<idno>after<p>in<place>, I don't see why you wouldn't also allow this in<person>. For example, a prosopography might give an ID for each person after the prose biographical info about the person, and the encoder might not consider this ID to be part of the paragraph.I wonder if we're edging towards a situation where a larger "entity" class might be useful. The more I think about it, the more person, place, org etc. have in common, even down to birth and death dates (organizations are set up and dismantled; cities may be founded and destroyed). Cities, for instance, can be viewed as both places and (through their municipality or their citizens acting as a group) as agents. Municipalities also fall into groups (the Capital Regional District is an amalgamation of several municipalities around Victoria).
Would it be helpful to have a generic <entity> element, with <entityGrp>, and a simple common structure, on which <person>, <place> etc. can build?
I know we can't really do inheritance in the true object-oriented sense in our system, so maybe this is a feature for P6, but it might be a helpful way of thinking about the problem.
More discussion needed.
At Oxford 2013-11 face-to-face JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
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.
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.
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
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.
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. ;-) )