rationalize content models of org and place and person

TEITechnicalCouncil commented 12 years ago

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.

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 9 years ago

This issue was originally assigned to SF user: jcummings Current user is: jamescummings

TEITechnicalCouncil commented 12 years ago

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

Original comment by: @peterstadler

TEITechnicalCouncil commented 12 years ago

assigned_to: nobody --> jcummings

Original comment by: @jamescummings

TEITechnicalCouncil commented 12 years ago

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)

Original comment by: @jamescummings

TEITechnicalCouncil commented 12 years ago

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 )* )

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 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)

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 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.

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

Original comment by: @jamescummings

TEITechnicalCouncil commented 12 years ago

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?

Original comment by: @kshawkin

TEITechnicalCouncil commented 12 years ago

@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> Some paragraphs about it <note>Some notes about it</note> <idno>An idno</idno> </place>

We can have paragraphs inside <person> but should you be able to have a note, bibl, or idno after those paragraphs?

-James

Original comment by: @jamescummings

TEITechnicalCouncil commented 12 years ago

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.

Original comment by: @martindholmes

TEITechnicalCouncil commented 11 years ago

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  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.

Original comment by: @kshawkin

TEITechnicalCouncil commented 10 years ago

More discussion needed.

Original comment by: @jamescummings

TEITechnicalCouncil commented 10 years ago

Group: AMBER --> RED
Priority: 5 --> 1(low)

Original comment by: @jamescummings

TEITechnicalCouncil commented 10 years ago

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.

Original comment by: @jamescummings

TEITechnicalCouncil commented 10 years ago

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.

Original comment by: @jamescummings

TEITechnicalCouncil commented 10 years ago

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.

Original comment by: @martindholmes

TEITechnicalCouncil commented 10 years ago

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.

Original comment by: @lb42

TEITechnicalCouncil commented 10 years ago

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.

Original comment by: @martindholmes

TEITechnicalCouncil commented 10 years ago

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. ;-) )

Original comment by: @jamescummings

emylonas commented 8 years ago

This should be considered with #562

raffazizzi commented 6 years ago

Council met with Christian-Emil Ore to coordinate work on this very topic. Council subgroup agrees that common parts of -ographies can be grouped into a new model, but we think this is best handled as part of larger reform of modelling of ontologies in TEI and Christian-Emil Ore will provide a report on that. Subgroup suggests moving to Status: Blocked again.

raffazizzi commented 6 years ago

F2F Marked status Go. @sydb to figure out and propose a rationalization.

martindholmes commented 6 years ago

@sydb I suggest we devote one of our Friday meetings to kick-starting this after the next release is out.

martindholmes commented 5 years ago

@sydb We seem to have dropped the ball on this. Shall we address it this Friday?

martindholmes commented 4 years ago

@sydb Ping on this dormant ticket! If we're not going ahead with it, should we just close it?

jamescummings commented 3 years ago

I don't think we should close this ticket but instead revitalise it. Ensuring as much as possible consistency of potential encoding across person/place/org and I would also add event, is a desirable goal. This has been done piecemeal with issues like https://github.com/TEIC/TEI/issues/1756 but we should step back, re-assess what the differences are between them and see how they could be better rationalised.

TEIC / TEI

rationalize content models of org and place and person #367