Some draft uncompiled notes of the TEI Prosopographical Meeting 2006-04-27 Lou Burnard(LB), Sebastian Rahtz(SR), James Cummings(JC), Elaine Matthews(EM),John Bradley(JB), Gabriel Bodard(GB), Fiona Oliver(FO), Eva Wedervang-Jensen(EW),Matthew Driscoll(MD -- Chair) The day started with a discussion of the agenda. MD and LB discussed two approaches of either reviewing the paper by EW, or gathering more concrete evidence of what the various projects around the table do and what needs they might have from a TEI prosopographical module. JBs and LB discussed how much the meeting should be influenced by non-TEI and non-XML things, like CIDOC. LB suggested that outside uses of prosopographical data were certainly useful to bring to the table to see what TEI might need to include. MD summarised that we here there to discuss the marking up of biographical and prosopographical data in TEI. Would like to improve what the TEI can offer and take into account outside projects. EM queried the scope of the meeting, pointing out that SR was working on the LGPN, which is interested in names, more onomastics than prosopography and the interface between the two. From the LGPN perspective the study of names has nothing to do the people who bear them. This not acknowledged in discussions she's heard. MD confirmed that the meeting was more interested in persons than names, that TEI has a skeleton person tagset but that this needs fleshing out. SR did point out that there is no place to relate names back to ideal names that are separate from persons. LB mentioned that until P5 the tagset allowed people to say 'there is a name here' but didn't really stray in to formal onomastics, since part of the TEI's mission is in marking up text. And that this causes confusion and concern that there is nothing to mark up the things which the name applys to. What does exist originates in the need to record specialised linguistic metadata for corpora. JB wondered what the best thing to do with TEI person information was, i.e. whether to store in header or in external document. The sense in most non-TEI projects was that people point to outside the document. The problem with storing this in the header is that it gets large quickly, so pointing to an outside generally preferred. MD confirmed that this is often placed in a second document; JB commented that these documents would themselves be in some ways related to onomastics since this could be just about names instead of people. MD noted that people should keep receipts for expenses. And the group expressed their thanks to Elaine for organising the meeting. SR wondered what MD wanted to get out of the meeting to take back to the TEI council. MD confirmed that he wanted a concrete proposal for all aspects of persons, marking up a body of text, tagging the names, and pointing to something which provides you information about those persons. But he confirmed he has manuscript-based needs for this and wanted to see what other projects need. This includes hearing what can't be done in onomastics in TEI already, but that the need to record person information should be a priority. JB wondered what the structure of this other document one points to would look like. LB confirmed that all linking is done via URIs, but JB meant that if it is a TEI document, does it have text elements etc., what is its overall structure. LB believed that it was up to you, but use of listPerson as paragraphs is one option. Personography as we called it for awhile was modeled on bibliography. MD asked LB to refresh all of us about what the person element contains and how it is used. LB explained that in the header you can put listPerson element in profileDesc, and it contains either a bunch of paragraphs or similar, or person or personGrp elements. The person element has role/sex/age attributes and xml:id/xml:lang MD explained how xml:id was useful for multiple people with same name. LB continued that within person you can have prose description or model.personPart. Affiliation, bibl, birth, death, education, firstlang, langknown etc. Some are heavy-duty and useful but others have accumulated over time. MD pointed out the history using the lack of a death element as an example. He also pointed out that @age was not useful for recording information about scribes. LB explained that @age was a shortcut for general age group for linguistic purposes and a shortcut for avoiding processing child elements MD wondered about multiple roles using the example of someone who was a scribe but also a manuscript owner. SR expressed concern about pointing to multiple roles at different times. At one point role A at another role B. MD agreed that this needs more thought. LB agreed that the current system was not exhaustive but a generalisation and simplification of the information you wanted to record. Ovid was a poet, farmer and father, but @role would probably be recorded as poet. JB noted the difference between document analysis and a prosopography which is historical construction of a person. LB reiterated that this exists as a quick and dirty solution and will make Guidelines explicit that these attributes are summary. GB noted that if we want exhaustive content then it must be as child elements, not attributes. MD discussed the use of the sex attribute and the ISO standard values. SR joked that it was good to see that we can have multiple births and deaths since there may be different attestations to these. JC wanted to confirm that person elements could be used for real persons as well as fictional/mythical characters. LB agreed that it could be used for both and wondered if we should have a mechanism for distinguishing them MD pointed out there was a need to distinguish between the two (though this could be done by a child role/trait element) since real persons appear in fiction and then do stuff which they did not do in real life. JB wondered if a project as a whole should decide. LB wondered if one would want to distinguish mythical vs historical? Most present agreed yes. MD: occupation=god SR: socecstatus=god JB commented that whatever the method it needed to be a class and so be easily extendable. LB reminded us that this is not an objective fact. But what we've identified is a need for something different from role, whether this is a historical, mythical, etc. GB/JB felt it should have structure itself, not just an attribute. JB mentioned that status was a name used in PASE but included extra info. GB felt that role might change over time, so needs to be element content. LB agreed that there were people who became divine then fictional. JB comment that places and locations are often different between projects, one needs the structure another finds that in structuring the person they are forced to structure the place. MD reminded us that interoperability is central to standards. define location so that in it you can fit both needs. JB argued that the historians involved aren't necessarily interested in adhering to standards. MD believed that it does need to be flexible, but need to preserve some hope of interoperability and steered discussion back to the person element. LB used Ovid as an example In doing so it was noted that: xml:lang should be en on first and la on second, Publius not Publus and the Death dates are not valid. LB showed the various elements in model.personPart SR felt that if we were defining person in so much detail, the other names, orgName and placeName should be equally defined so that we can point to these. MD agreed that person/place/org types of names need to be similarly handled. EW pointed out that families need to be catered for, but LB suggested personGrp could be used for this. MD wondered about names of artifacts, swords e.g. 'excalibur', and LB suggested name/@type="sword". GB wondered about the nestability of personGrp and using it hierarchically. LB skipped over bibl and note quickly. LB explained the nesting of names and dates inside of birth and what att.dateable provided. GB wondered why @date isn't part of the dateable class? JB wondered about extending birth/date etc,. for other events, like marriage. LB pointed out we'd be discussing that later. LB continued to look at things in person, especially the linguistic things. Education, FirstLang, LangKnown, nationality, occupation... the latter of which is slightly different in that you are able to add a classification code to the description. (according to rg scheme accountant is 'at'). JB and MD wondered about whether occupation was dateable and felt it should be. LB continued persName... residence also datable. socecStatus... almost identical to occupation (SR noted it has same attributes) MD pointed out that person as it is comprises a person in a language interaction+death. LB discussed linking: There is a particLinks element which allows you to point to elements or use relations active/passive/mutual mutual=like sibilings GB wondered about whether Father and son were active and passive? LB: yes. mutual. MD felt that particLinks name must change. SR wondered about the missing certainty of relation. in LGPN making an assertion. almost all these consistently need certainty/datable/resp, etc. on each. LB wondered if this should go on particLinks or on relation itself? MD: We have certainty attributes already, question is just where to put them. LB: not straightforward on how you use them. You probably only want to use it where you were pretty clear. GB felt that you might want to add this completely uncertain about the data, and only make such judgements after you had finished. By structuring it, you find out how certain you are. SR felt there needs to be a way to have an authority (bibl?) for each of these, lou says you are the father, I say gaby is the father, how certain are these and who is making the assertion. MD asked the group to sum up existing problems with the model? Not just lacks. FO and MD agreed that @age attached to persons not useful, while LB reminded us that @age is 'age group'. FO mentioned that prosopography looks at people throughout their lives rather than a particular age in them. SR wondered about, if having event, then having a summary event which gave lifelong summary information. MD was in favour of removing attributes from person, GB wanted to see them usable as element content as well, JC wondered about renaming @age to be @ageGrp. FO&EW wondered who uses @age and how one defines the different ages. MD felt that any attributes on person should be usable by 90% of people. SR didn't want to use attributes in one case and elements as another. Age attribute attachable on child elements as well, like event for age-at-event? MD felt that @sex was not controversial. but reiterated that one needs a way to define if a person is fictional/mythical or real. LB felt that ageGrp is universal and social class but MD believed ageGrp is irrelevant for many people. LB reiterated that yes, many potential users will be looking at people over all of life. But, there is a large community we would like to help which needs to record participants in a language interaction. GB felt that we shouldn't be having any attributes which were not universally applicable, and that if they weren't they should be element children in an extensible manner.. LB wondered about having no attributes and only have events which include the inclusion in that record. SR wondered about summaries vs. more structure in person. Event children, multiple resident children etc. Some sort of structure inside person. GB: How is that better over having multiple datable residence child elements? SR: Don't know. Want to associate residence and occupation together inside the event. MD wondered if we had reached any agreement? SR: Role... isn't that usable for human/divine Much rather have role as an element so that you can have internal markup. LB: remember these are summaries, not detailed analysis. Use occupations JC felt that roles were not occupations. MD agreed role: ms owner vs scribe. How do you point to jon johnson as scribe rather than owner. (xml:id on different ?) Want to pull out only the owner not the scribe. LB felt that this was currently not possible. These are summary simple things, not detailed information. Indeed lacking this possibility, can reference person. JB wondered about pointing the other way. In person, point to all the places where this is used. MD noted that it was a lot more complicated, but would work. LB reminded use that the other way to do it would be Stand Off. linkGrp point to the instances. MD noted that what they did was put scribe and owner in the individual name @role owner to allow filtering there. Lou used to not like role on name. There was discussion about the use of @type on persName and MD felt that they wanted some form of @role on name. But SR pointed out that you could just use a complex pointer (in @key) to point to the person and then bits of information underneath that. LB said the main thing was not to confound the name with the person, which is a fundamental thing. SR prefers Point to person and use xpointer to use a child element. MD and SR agree that role needs to be repeatable and databl GB wonderd about non-existent relations (i.e pointing to someone not in the list) SR felt that he didn't use relation because of this. They had a son called fred, but you want to record this. GB: This person is a widow, so must have had a husband. LB warned that this can lead to many redundant people. MD wondered if should be kept as an empty element. SR: Allowing it to have content isn't enough, it would need more work. MD: Perhaps need prose description, etc. needs to point and also be a description of that relation. LB: I'd prefer to keep it how it is, but have another structure to have a less formal way to discuss relations. MD: if we are changing the name from particLinks to something else. relation, relationGrp, individual relation have pointers in different directions, but could also have descriptions. SR: rename relation to relationLink instead to make its purpose more clear. Have relation with relationLink as a child. MD wonderd why not just do this on the same element? JB: Formal way to say date compared to a text-based way to say it. Isn't this the same. MD: Need to be able to link and describe. GB: Both ways need to be possible. LB: person elements we are describing are not existing in pre-existing texts. MD: Ok, but just as MSDescription we might take a DNB entry and make a to describe the same information. MD: firstLang and langKnown, should be put in some sort of linguistic area. GB: just use a @type=first SR: I don't want to see them, unless I load linguistic/corpus module. MD: Knowing what language someone spoke would be useful. JB: 3 of our projects listed language at start, but at the end found they put almost nothing in it. MD: Some element with optional languages SR: why pick on language, not dress sense. GB: SR's point is that we need a mechanism to say something general about people generally. MD: GB might argue nationality is a generic thing. LB: Don't want to end up with everything a seg, i.e. seg/@type=nationality JB: Two projects uncomfortable with nationality MD: Difference between nationality and citizenship? nationality/religion/languageUsage LB felt these were all part of a class. MD: What is the list of things you aren't allowed to ask people to at a job interview? Race/creed/colour/sexpref/etc. GB: Do we have a generic statement about people, of which these are specific instances? LB: Two ways to solve: add a generic personClassification element or extend personPart class. Which isn't the same as occupation. MD: Any other obvious problems? SR: I'm not seeing many ways to group these... want them all together. MD wondered about lifeEvent? LB points out that events different from classification. JB: involve multiple people SR: personal event versus general event. GB: the two are different whether it is primarily your event or not. LB: The wedding as an event is different from the event of marriage. MD: This is why we'd want to distinguish between life events and historical events, even though there is an overlap. LB: historical events are things like placenames which we have a name for. Difference between events and classifications. Events happen to you whereas classifications are things other people put on you. JB: event where you become a knight is different from the change in status. LB: You becoming king ... SR: where do you record the kingship status LB: Unruly serf, event happens, gains another status. SR: how to link that change in status to event which caused it. LB: Event causes classification vs classification causes event. GB: what do we gain by dividing up into classes. LB: 2 things: clarity in our minds about what these things are. Also easier for extension. SR: Chances are a good class can be used in multiple places. MD: Are we agreed that birth/death aren't the same kind of events of marriage/knighthood. Shall we propose lifeEvent (dateable) of which birth and death are special cases. Gb: but worthy of keeping as separately. JC: multiple birth info? MD suggested including all in single birth element. Don't think you need multiple births. but proposing lifeEvents in between birth and death. SR: relationship between events and classifications... someone comes from a particular island, is that event or classification. GB: born of athens, citizen of athens, but being granted citizenship elsewhere. SR: so you can have untimed events? or are those classifications. GB: event and classification tied together. LB: relationship between event and classification, MD: lifeEvents imply change of status... but need means of linking the two together. LB: the thing which links them together is an assertion. MD: GedcomXML list of event types. Ev: birth/death/marriage as vital type events MD: this is the sort of list of things we might want to cover when talking about lifeEvents FO: floruit: period at which a pserson flourishes. LB: dating of lifeEvents MD: group birth/death/activePeriod. MD: tribe subgroup of ethnicity FO: tribe, subtribe, family group LB: You are classed as this, you can't learn to be. FO: Relax affiliation use that LB agreed that affiliation good idea. Member of Oxford and a MicMac Indian. Fi: ParticDesc ... rename persDesc? MD agreed that we need to change this. FO felt we needed something for personal/physical traits. (eyecolour/hair/etc.) Reconvene: 14:00 (1.5 hours.) SR wondered What will a prosopography module NOT cover? MD: Decide as we go through those things we need to see. JC: linking of bibl and any of these items. SR: Not elegant to say with bibl inside as source. MD: Certainty/resp from att.editLike (probably needs new name). @resp pointer to bibl or use dates. GB: Things that happen at the same time aren't necessarily related though. Ev: HEML has something like this. LB felt we should now go through the points of discussion (pfd) in Eva's document. MD: Yes, I thought it would be useful to ascertain where we are to start. But, sure. 3.1 Pfd: we've already talked about this. But look at terminology. lifeEvent/event. SR: Tying to time-based thing if we say 'event'. That's why I say assertions Gb: can events occur inside assertions SR: person/assertion/event can role appear at any of these three levels. MD: Can you tell us what you mean by assertion. SR: There is a unit of information about this person, factoid, but not necessarily a fact, so assertion. LB: Why not present the LGPN stuff. SR: Look at person worked out example. person with sex/id -various names - 3 things, last bibl. correctly child of person here as single source for each one of these. - birth and death, normalized date in attribute -siblings to this I'm asserting something to do with a place or a name. i.e. an alternate form of their name/place. There could be a bibl inside this. but this contains a placePrt with a key. So new elements are: assertions, placePtr. GB/SR: persName outside, but could be inside assertion if differnet. LB: all markup is an assertion SR: Grouping MD: What is the benefit of assertions SR: Mostly the grouping, allows you to record the bibl for that assertion even when they disagree. LB: assertion/@mode=name is just persName, isn't it? SR/GB: It is used then for grouping. This is extensible based on attributes. GB: How tie together a relationship/name/place/ etc. SR: Eponymous Archon in 493BC... GB: Still need something to wrap it, but @mode limits it. LB: Not saying you shouldn't have a wrapper, but that assertion isn't it. Any of the children of person should be a wrapper for any of the others. GB: Got married to this person and inherited this title. is this an event, with assertions, or an assertion with events or 3 events. Lb: the main thing is the wrapper, so use event as wrapper, etc. SR: The benefit of the wrapper is that you can make it dateable instead of all the other things (persName, place, etc.) call it div instead of assertion. MD: What is model for assertion, where does it come from. EW: 3 options of similar things. GEDCOM. SR: In long example there is 3rd name on second page. Funny variant where it is mis-spelt, a ostraka. Used to vote for someone who is going to be exiled. assertion/desc: f. MD: why not put note inside persName GB: with the wrapper you know this is a note on this name. MD: But if not inside persName you'd know this as well. GB: how do you tell if this is the bibl to the event versus of this event. MD: all you need in persName is lang, resp, etc. LB: Or you have to invent another wrapper namingEvent or something. SR: either you attach baggage to existing element, or you invent wrappers for each of them, or you invent one generalised wrapper. Gb: wrapper with a type/mode attribute. LB: understand this need to provide a wrapper. Attach note to inside of persName. SR: But that is mixed content and so hard to process, etc. So you are agreeing there is a level between Person and persName. GB: If use element as wrapper, then for a 4way thing there are 4 completely different ways to do it and processor has to look for it. relationship attached to status but not event. Someone has a title because of his friendship with emperor, but not because of a specific event. LB: It is a relationship. MD: don't you need to repeat a lot of information then if you want each of these. SR: Base it all on
so nest all the things on the early bits of my life. LB: not sure why you want to group things inside person. SR: Might have 5 events which share a bibl. LB: Outer div which hs bibliography and 4 inner divs GB: or inner element. SR: I'm not in favour of having an event, just another div/@type. GB: person can have all sorts of statements/lifeevents etc. and some of these are going to want to be tied together in some way. LB: I'm not sure of that. example before us is just of more types of names. SR: wanted to avoid inventing new tags, and overloading existing one. a) invent event b) relationship c) certainty. GB: need to invent wrappers for all the types of things so traits/classifications/events/ etc. Can't put a bibl inside an event, because event might be writing a book. LB: expecting markup to convey facts and what you want to say about them personClass/citizenship=USA + bibl or ptr. back to residence element. two assertions being made. 1) person resided in New York 2) Person has US citizen. and third assertion if you want to indicate the relationship. Gb: Could be just one assertion from one source. LB: In practice you are reading source. If your primary concern is citizenship you'll use that, if primary concern is New York, you'd choose that. GB: 10 statements I want to make, group them. or ID one and then link them together. LB: Oh, I see you just want to group them together. What are semantics of it? GB: They are related, not one causes another. LB: It is a relationship. SR: What if they aren't related, just have same bibl. LB: That's the relationship. SR: But that isn't really a relationship. you just want to group them for the source. LB: what is the purpose for grouping them causal, or source, etc. SR: simplest case there is no grouping if we just put everything in person. Can we abandon socecstatus? JC: Rename it to status/@type="socec"? MD: We've agreed 3 types of information classification events relationships, names. possibility of conflicting information for these four things. SR: Then need wrapper for each of these things. MD: Name/classifications/lifeEvents/Relationships Do the linking only apply within these things, or between them as well? GB: Events will have classifications inside as well. SR: Difference between change and dated state. Why are relationships difference from traits? LB: They have a name and target. SR: Except that a relationship is also an event. JB: a source might assert the relationship but not the event. SR: some will have loads of events, or relationships or classifications. Each one is datable, certainty, and resp'able. Attestation that someone was there, not is born there. SR: I think maybe classification is the wrong word, since it needs to be datable. a state? state has a beginning and an end. state as opposed to event instead of classification. GB: Grouping in this way you have specific examples of each one, but forms a class of concrete elements. EW: Person moving around hard to pin down where they live. MD: Permanent things, sex, ethnicity, ... SR: If one state then put it in person. MD: Have one at a time. Fundamental difference between ethnicity and occupation. LB: These are judgements made upon a person but occupation? GB: They are just more obviously changeable thing. SR: State might not be the best name. Stay with Classification. MD: I'm not necessarily suggestion these need grouping elements, but jsut that these are conceptually linked. eventList, Relationships, but don't have something for the classifications. Can classification type elements come inside events? Another section is bibl. SR: are my assertions just events? SR: Lou was repeating an assertion from Laurent that in metadata you should be able to attach notes and bibls. LB: If you can assert there is a foo here, there is a need for fooGrp with bibl/note/comment. MD: And why not put in? LB: avoid mixed content, Gb: you could link it, but that is annoying. - coffee - 3.2 pfd: authorised name. persName/@type but avoid saying this is the 'real' form of the name, since this isn't necesarily thename they used in their lifetime. SR: preferred name and name in idealised form. EM: Other Classification theophoric names (based on gods), atested in 3 or four different parts of word. Distinction between orthographic and dialectal variations. all facts about names that you want to get to and relate. LB: Names that contain elements of divine names, or someone named after someone else. All different ways of catagorising names. EM: The way people look at names. For example Greek names that reflect non-Greek language. LB: So a morphological judgement on the name EM: Yes. Sitting on border of onomastics and prosopography... LGPN gives each example of names. A person becomes just an attestation of the name. Adding classifications to the name is something we might be interested in doing. SR: Other things you know about a placename, other than its modern geopgraphical name. EM: They really want to know how common, where found, used in what periods. SR: persName is only a link between name and person. LB: att.personal. general type. MD: name/@reg SR: doesn't that point to the person. MD: no that is @key. Lb: name/@reg no longer exists: consequence of war on attributes. Gb: My names don't separate out into forename/surname. but I use @key to point out to a database. SR: So we want a way of putting back @reg and a container for names called listName. SR suddenly takes keyboard at this point and writes: ------ ... A name Theophoric name ------- (presumably to remind him of something.) GB: I use just name inside persName. and use type to distinguish between name which points to person and that which points to a name database. MD: reinstate @reg with a different content model? GB: @key is right name, but need way to point to names or persons. LB: nameLink SR: anderson you don't tag 'son' as nameLink LB: roleName example, roleName is part of persName but really is a 'trait'. removing these from persName. MD: let's return to Eva's report. LB: Do have a method to distinguish between authorised and others. Should we have a ? EM: Romans were unique in having a family name. Greeks only had a name. Ev: Mexico Different names if they are masculine or feminine. GB: want a generic name under name, currently use persName/name/@type LB: Decision for the TEI is that names needs overhaul. Should we be introducing something more generic or less generic. More generic possibly better. -ExistDate/useDate SR: We'd use events. MD: Person was called this for so long, then called this otherwise. Fi: Contemporary and overlapping names. MD: how do you indicate the times of names. SR: Have to put it in a subdivision, that division is dateable. Emperor Caracalla as example as he has a full title with many elements. GB: titles which fall out of use as well as into use. EM: Names related to events when name changes from event. MD: translations- xml:lang SR/LB: Distinction between transliterations and translations. SR: My data has that example, different transliterations of the same. LB: These are not translations /xml:lang because the glyphs don't mean that in english. All in unicode. -chinese name represented in roman alphabet in two different ways. so change of writing system SR: so in mine I need to do el-perseus GB: Confucius is a translation. MD: Lou is saying we already have an acceptable method but we need to document it better. MD: Deal with initials as a separate unit. Ev: need for initials as separate to the name so SPQR LB: Use abbr, nothing particularly difficult with initials GB: What is Sturluson.... SR: Patronymic. LB: since they are the name you get from your father, that is equivalent to a surname. MD: It is in Denmark, but NOT in Iceland. LB: Should we have a 'Patronymic' element. MD: Now accepted by the LoC; are not surnames. LB: Not really for discussion here ... if needed abbr is an option. 3.4.1 Persons floruit dates. lifeevents. discussed. Relating life events to historical events? (volcano, marriage, etc.) Gb: lifeEvent is their death, and put event of eruption next to this. MD: listEvent LB: Outside our scope. LB/MD: We'll have to do this eventually....On your event horizon... (*sigh*) We know this needs to be done, but will be done later. SR: If you start doing all the event stuff you start replicating CIDOC. 3.5 - We should have lifeEvent. SR: Maybe importing HEML file and say they know how to do this. like SVG. 3.11 - Categorisation, legal status, functions, occupations and activities. co-hyponyms don't have to have the same parents. JB: Are bishops an occupation or a function? MD -characteristics, agreed we need something like this. -EAC 'environment' LB: setting/locale MD: I don't think we need that. MD: Religion, we've talked about that. MD: LangKnown LB: Education could be subdivided. 3.12 We want to have relation descriptions. --done--- (sorry for increasing incoherence). -- Dr James Cummings, Oxford Text Archive, University of Oxford