New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

occupation element should have a type attribute #1600

Closed
sydb opened this Issue Mar 4, 2017 · 69 comments

Comments

Projects
None yet
10 participants
@sydb
Copy link
Member

sydb commented Mar 4, 2017

In a conversation on TEI-L, Antonio Rojas Castro requests an @type attribute for <occupation>.

@sydb

This comment has been minimized.

Copy link
Member

sydb commented Mar 4, 2017

Given that <occupation> is repeatable and could quite reasonably be categorized in any of a variety of ways, I don’t see any reason off the top of my head that it should not be a member of att.typed.

@bansp

This comment has been minimized.

Copy link
Member

bansp commented Mar 4, 2017

I realise that this is off topic but I can't help and reflect that this sort of reasoning (against an argument from ignorance (sic!)) didn't stop the Council removing @type from teiHeader and thus ruining compatibility for some language resources. So good luck with this one, Antonio...

@jamescummings

This comment has been minimized.

Copy link
Member

jamescummings commented Mar 6, 2017

The general rational for whether elements should be considered for att.typed is:
a) are they repeatable
b) is there are general classification to the type of element that is easily evident.

In this case, it is probably the case for most members of model.personPart:
affiliation age education faith floruit langKnowledge nationality occupation persName residence sex socecStatus state trait

Of these, persName, trait, and state all have type. persName for various legacy reasons I think, and trait and state because they are general and need a type attribute to help define what type of trait or state it is.

I think an argument can be made for some of these, others I find harder to think of an easy classification of the type of element.

I think occupation shouldn't be dealt with alone. That all model.personPart elements should be considered at the same time.

@martindholmes

This comment has been minimized.

Copy link
Contributor

martindholmes commented Mar 6, 2017

@jamescummings I know what you mean when you say that all model.personPart elements should be looked at, but this is how a simple request that can easily be answered morphs into two years of bickering about the edge cases. How about adding <occupation> to att.typed first, to make Antonio happy, and then starting the larger examination afterwards?

@jamescummings

This comment has been minimized.

Copy link
Member

jamescummings commented Mar 6, 2017

@martindholmes I understand the potential frustration. It just seems like an opportunity that we shouldn't miss to deal with the others. e.g. education with types of primary, secondary, etc.

I think it could be quite quick to go through all of them and see which should or shouldn't get them. Maybe I'm getting more flexible in my old age though.

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 6, 2017

I would greatly welcome @type on the elements mentioned by @jamescummings . Which ones are hard to imagine? I struggle with <age> but the others spring to mind quite readily.

@martindholmes

This comment has been minimized.

Copy link
Contributor

martindholmes commented Mar 6, 2017

@duncdrum Actually, the remarks on <age> seem to me to make it a good candidate: "As with other culturally-constructed traits such as sex, the way in which this concept is described in different cultural contexts may vary. The normalizing attributes are provided as a means of simplifying that variety to Western European norms and should not be used where that is inappropriate. The content of the element may be used to describe the intended concept in more detail, using plain text." Most of the attributes are numerical or calendar-based, and seem skewed towards representing the concept in traditional European terms; @type and @subtype would be quite useful in cases where "age" is actually something quite different.

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 7, 2017

Good point @martindholmes Chinese baby's are 1 year old at birth so <age type="sui">1</age> makes perfect sense. Any left that remain questionable?

@jamescummings

This comment has been minimized.

Copy link
Member

jamescummings commented Mar 7, 2017

Hi @duncdrum and @martindholmes. Age was one of the ones that I was unsure about. I was also unsure about faith (I usually am ;-) ) in that the type attribute shouldn't classify the type of faith but the type of faith element (i.e. not catholic, muslim, hindu, scientologist). Floruit as well, what different types are there of that as an element? (Not different roles or different ways of analysing it.)

Compare also birth and death, neither of which have att.typed as well. state and train have att.typed particularly because they are light in semantics... the others have that provided quite strongly. birth is repeatable as much as occupation and affiliation... why should one have att.typed and the other not?

I'm just playing devil's advocate here... occupation, affiliation, and education jump out to me as ones where att.typed would be completely reasonable... I'm just trying to figure out what further constraints we should have on our decision tree of whether something should get att.typed or not. In general I'm in favour of adding it where there isn't a good argument against it, but that is fairly weak.

@lb42

This comment has been minimized.

Copy link
Member

lb42 commented Mar 7, 2017

Looking at the OPs use case, wouldn't a better solution be to define a new specialisation of trait called "mainOccupation" ?

@lb42

This comment has been minimized.

Copy link
Member

lb42 commented Mar 7, 2017

(or one called "otherOccupation", if you prefer!)

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 7, 2017

@jamescummings of the top of my head <faith type="convert | practicing | clandestine"/>. I was thinking of specifying how floruit is determined, via @type but if you prefer a different way I m not so sure. <birth> and <death> could take different types with fictional characters some hatch from eggs, others are generated by spells…who knows. Deaths can be assumed, declared, or inferred...

@lb42 the problem is that with large prosopographies the number of traits becomes massive, nested in e.g. multiple <socecStatus> which starts straining the human-readble part. Adding type to model.personPart would help to declutter this.

@jamescummings

This comment has been minimized.

Copy link
Member

jamescummings commented Mar 7, 2017

@duncdrum While I perhaps overuse it many of those kinds of classification are what I would think of analysis and thus use the ana attribute to point to a taxonomy. However, the types of death are more persuasive to me because they are about the nature of the element rather than the nature of its contents.

@lb42

This comment has been minimized.

Copy link
Member

lb42 commented Mar 7, 2017

@duncdrum I don't see why you think that having <xxxx type="yyy"> (for large numbers of values for yyy) is any less cluttered than having <XXXyyy>. Is it because you don't look at attribute values?

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 7, 2017

@lb42 this is only partially me playing devils advocate, but based on my experience with a prosopography of Chinese persons in TEI.

Let's say, for the sake of argument, the OP and I have good cases for wanting @type on all the model parts. Your solution is what is close to what I'm currently doing to the whole list looks like this:

…
<trait type="occupation" subtype="yyy">xxx</trait>
<trait type="faith" subtype="yyy">xxx</trait>
<trait type="education" subtype="yyy">xxx</trait>
etc.

thats two more words per element to the human reader compared to:

<occupation type="yyy">xxx</occupation>
<faith type="yyy">xxx</faith>
<education type="yyy">xxx</education>

it also raises the question of what the following might mean:

<occupation>teacher</occupation>
<state type="mainOccupation">violinist</state>

is violinist-teacher a thing? are you teaching something, but earn money via music? Are you teaching violin in your spare time as a professional musician?

Lastly, it makes one wonder if it really is intended that cases conforming to one cultural norm have an age <age> but everybody else has traits <trait type="age">

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 7, 2017

@jamescummings <socecStatus> is a good example using @scheme for full fledged taxonomies, but for cases with few types, eg. <age type="western | sui"> a full taxonomy seems overkill.

@lb42

This comment has been minimized.

Copy link
Member

lb42 commented Mar 7, 2017

@duncdrum, I think you are missing my point. Forget about human readers: what counts is the software that's going to process this stuff. If it has to do with a gazillion different attribute values, how is that different from having to deal with a gazillion different element names? That said, the "sugared" variants (occupation etc.) were introduced (tis true) to simplify life for those preferring an explicit element to a generic element+type value. The price of that simplification is of course the kind of oddness your violinist/teacher example exemplifies.

BTW, my suggestion of "mainOccupation" was not intended as a @type value but as an additional element name. So you would say

<occupation>teacher</occupation>
<my:mainOccupation>violinist</my:mainOccupation>

to show that this person was primarily a violinist, but also did some teaching on the side. What they are teaching is not specified. It might additionally say <occupation>rat catcher</occupation>if times were hard. ... Note here the use of the my: prefix, necessary since this is not (yet) a valid TEI element. But that's another consideration.

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 7, 2017

@lb42 I heard you:

Forget about human readers:

still my examples stand its a gazillion vs a gazillion -1

private prefixes are indeed a different topic. But they don't address my comment about inherent cultural assumption <age> vs <my:age>.

The sugared variants are valid TEI, allowing for @type would greatly help to signify the cultural differences they supposedly encompass.

@sydb

This comment has been minimized.

Copy link
Member

sydb commented Mar 7, 2017

  1. I think @jamescummings is right, quite a few other elements could usefully be members of att.typed.
  2. I think @martindholmes is right, don’t want the perfect to be the enemy of the good.
  3. I do not think a specialization of <trait> (whether <trait type="mainOccupation"> or <mainOccupation> or <duncdrum:mainOccupation>) is better than <occupation type="main">. (Especially since IMHO an occupation is a <state> :-)
  4. So my proposal is that we try to develop the list of which members of model.personPart should be in att.typed here, but only for 1 week. If we can’t agree on a list to propose to Council in < 1 week, we just send <occupation>.
@sydb

This comment has been minimized.

Copy link
Member

sydb commented Mar 7, 2017

(And it would be good to have a few sample values or an example of each.)

@martindholmes

This comment has been minimized.

Copy link
Contributor

martindholmes commented Mar 7, 2017

I like @sydb's point about sample values, and in fact I think having @type without sample values is a bad thing.

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 7, 2017

I ll have a shot at it:

  • <affiliation type="sponsor | recommend | discredit | pledged">
  • <age type="western | sui || subjective | objective"> this has pretty broad application and could go in the guidelines as a good example.
  • <education type="primary | secondary | apprenticeship">
  • <faith type="practicing | clandestine | patrilineal | matrilineal | convert">
  • <birth type="accretion | secretion | exNihilo | rebirth">
  • <floruit type="calculated | claimed"> not so sure here.
  • <death type="proclaimed | assumed | announced">
  • <langKnowledge type="active | passive | oral | written">
  • <nationality type="birth | naturalised | self-assigned">
  • <occupation type="main | not-main"> see OP
  • <residence type="permanent | temporary">
  • <sex type="explicit | implicit"> I’m thinking of cases where the depiction of deities change gender over time, see here
  • <socecStatus type=""> already accepts @scheme and @code @type would be a less rigorous version for cases where a full blown taxonomy is overkill?
@martindholmes

This comment has been minimized.

Copy link
Contributor

martindholmes commented Mar 7, 2017

On this one:

<langKnowledge type="active | passive | oral | written">

these are two different types (hmm) of classification. If we're talking about skills, presumably we'd include listening, speaking, reading, writing; listening and reading are normally classified as passive skills and speaking and writing as active, although this is I think rather simplistic. You might have:

@type=active|passive; @subtype=listening|speaking|reading|writing

with some Schematron constraints on co-occurrence. But I'd be more inclined just to have the four skills as suggested values for @type.

@jamescummings

This comment has been minimized.

Copy link
Member

jamescummings commented Mar 7, 2017

Almost all the suggestions ppl have made seem great to me. (And yes I don't think we should ever provide suggested values for subtype as TEI-C that is for individual projects.)

@lb42

This comment has been minimized.

Copy link
Member

lb42 commented Mar 7, 2017

Don't forget that all these elements are datable as well as repeatable. So there's no need to use considerations of temporaility when defining the typology: indeed to do so is to invite confusion.

I cannot say that I find the proposed typology for <age> very persuasive: I looked up "sui" to find out what it meant and realised that it is but the tip of a complex iceberg when dealing with East Asian materials (see https://en.wikipedia.org/wiki/East_Asian_age_reckoning#Chinese) . Opposing it simply to "western" doesn't make a lot of sense to me, but then using this element at all seems needlessly complicated when you have a datable <birth> element.

@jamescummings : why do you object to supplying examples for @subtype, but not to supplying some for @type? Seems to me this is a sauce for goose/gander situation.

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 7, 2017

@lb42 exactly because it is the tip of an iceberg is why @type comes in handy. If i want to calculate a dateable event from a statement of age I need to know what kind of age the text is using. So to get to birth from a statement like this: <p> i was <age>5</age> when i joined the school at the missionary, Mr. X was <age>50</age> at that time</p> Means that I was born 4 years before the account, but Mr. X was born 50 years ago.

I m not trying to say that sui | western is exhaustive, just that there are many texts in which sui counting appears, and probably more with even other means of counting.

@martindholmes

This comment has been minimized.

Copy link
Contributor

martindholmes commented Mar 7, 2017

Don't forget that we also use person for fictional and fantastical entities, so age and birth are not necessarily in a calculable relationship with each other. Doctor Who is presumably an example; he could be a thousand years old but born a million years before the present.

@raffazizzi

This comment has been minimized.

Copy link
Contributor

raffazizzi commented Mar 13, 2017

I agree with @jamescummings that biblFull should not have a @type as its strict model makes it of just one type IMO.

I do not have an objection to adding @type to other elements in the list that @sydb kindly collated.

@sydb

This comment has been minimized.

Copy link
Member

sydb commented Mar 13, 2017

direct members of model.personPart

element has @type suggested values yes no comments
birth no accretion, secretion, exNihilo, rebirth JC, SB, MH, MS?, EB LB why a member of att.naming and att.canonical?
death no proclaimed, assumed, announced, fragmentation, dissolution JC, SB, MH, MS, EB LB why a member of att.naming and att.canonical?
idno YES ISBN, ISSN, DOI, URI, VIAF, ESTC, OCLC

via model.biblLike

element has @type suggested values yes no comments
bibl YES also has @status
biblFull no JC, SB, RV, MH, LB, MS, EB has @status
biblStruct YES
listBibl YES
msDesc YES

via model.eventLike

element has @type suggested values yes no comments
event YES also a member of att.naming and att.canonical
listEvent YES

via model.persStateLike

element has @type suggested values yes no comments
affiliation no sponsor, recommend, discredit, pledged JC, SB, MH, MS, EB LB also a member of att.naming and att.canonical
age no western, sui, subjective, objective, inWorld, chronological, biological, psychological, functional JC, SB, MH, MS, EB LB
education no primary, secondary, apprenticeship, residency, undergraduate, graduate JC, SB, MH, MS, EB LB also a member of att.naming and att.canonical
faith no practicing, clandestine, patrilineal, matrilineal, convert JC, SB, MH, MS, EB LB also a member of att.canonical
floruit no calculated, claimed ? attested? JC, EB SB, LB, MH values: rapper, actor, politician ? really should be an @as ptr to an <occupation> then, eh?
langKnowledge no listening, speaking, reading, writing JC, SB, MH, MS, EB LB
nationality no birth, naturalised, self-assigned JC, SB, MH, MS, EB LB also a member of att.naming and att.canonical
occupation no primary, other, paid, unpaid JC, SB, MH, MS, EB LB also a member of att.naming and att.canonical, and has @scheme & @code
persName YES also a member of att.naming and att.canonical
residence no permanent, temporary, primary, secondary JC, SB, MH, MS, EB LB also a member of att.naming and att.canonical
sex no explicit, implicit JC, SB, MH, MS, EB LB
socecStatus no atBirth atDeath dependent inherited independent JC, SB, MH, MS, EB LB also a member of att.naming and att.canonical, and has @scheme & @code
state YES also a member of att.naming and att.canonical
trait YES also a member of att.naming and att.canonical
@sydb

This comment has been minimized.

Copy link
Member

sydb commented Mar 16, 2017

I’m hoping @raffazizzi , @lb42 , and @martindholmes will add their initials into the “yes” or “no” column for each entry that doesn’t already have @type in the table above.

@lb42

This comment has been minimized.

Copy link
Member

lb42 commented Mar 16, 2017

I don't think I have a vote. If I do, it's No in each case.

@sydb

This comment has been minimized.

Copy link
Member

sydb commented Mar 16, 2017

@lb42 : True, you no longer get a vote on Council’s final decision, but this is just a ticket with interested parties expressing their opinion.
But can you explain why you’re against @type on the various elements above, particularly <occupation> (about which you were at least not against, if not in favor, 9 days ago).

@lb42

This comment has been minimized.

Copy link
Member

lb42 commented Mar 16, 2017

I said I was cool with it, which is not quite the same as voting for it. My opinion is that most of these elements are already typed, and nearly all of the use cases proposed for further typing are entirely imaginative.

@martinascholger

This comment has been minimized.

Copy link
Contributor

martinascholger commented Mar 23, 2017

I added my initials to the columns. @birth: I can't figure out what 'accretion' and 'secretion' means in the context of birth. Can anyone enlighten me?
In addition, for @education, I would suggest the values 'informal' and 'formal'. Should we consider values for persName, e.g from epidoc: attested, emperor, divine, consul, other?

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 23, 2017

@martinascholger inspired by Marta Weigle Creation and Procreation: Feminist Reflections on Mythologies of Cosmogony and Parturition 1989 p. 9. Her typology of how the world comes into being, also applies to the differences between members of pantheons (for lack of a better word) more general.
Think of it as the more colorful version of the catholic obsession with maculate/ immaculate binary 😉

@ebeshero

This comment has been minimized.

Copy link
Contributor

ebeshero commented Mar 23, 2017

I've just walked through the list and added my initials, too. I also tentatively supplied some @type values for socecStatus in model.persStatsLike. Do these seem plausible?
atBirth atDeath dependent inherited independent

I, too, scratched my head initially at secretion and accretion, but I like @duncdrum 's cosmogenic explanation, and I have lists of mythic figures and archetypes in one or two of my projects that might benefit from such markup. The more connections with theories of classification we can make, the better. But the values we have listed for death don't seem to match conceptually. What about dissolution and fragmentation there?

@jamescummings You mentioned you'd rather not see "controversial" values, but I will say that one particularly helpful application of the Guidelines and our sample recommended values and explanations is in expanding conventional frames of reference, as I believe these values do. In other words, the Guidelines should be theory-inflected and imaginative of wide-ranging use-cases.

@martindholmes

This comment has been minimized.

Copy link
Contributor

martindholmes commented Mar 23, 2017

@ebeshero I'm not sure atBirth and atDeath are types of socecStatus; they specify the time at which a particular status was current. The element is datable, so this sort of thing should probably be done with dates if possible, but I see the problem if you know that X died in poverty but you don't know the date of death.

@jamescummings

This comment has been minimized.

Copy link
Member

jamescummings commented Mar 23, 2017

@ebeshero You are right, of course, that it is good to highlight things that people might not have considered in their narrow frames of reference. I guess what I mean is that I'd prefer the TEI not recommend any values that are currently hotly debated as to their existence or not. That is, we shouldn't be taking sides in current debates (in the same way that the TEI is an apolitical organisation). However, including suggestions that are accepted but marginal or ignored (especially in western culture) I'm all in favour of doing. So I agree it should be imaginative and wide-ranging in its suggested use-cases, but also make suggestions that people will understand and coalesce around.

Part of the reason for sample or suggested values is to promote convergence on people using the same terms which helps interchange. (If you are using the 'name' element for personal names, why not put a type attribute of 'person' on it like the TEI recommends). Another reason is to make the use and semantics of the element and its attributes clearer to people, so suggestions as part of pedagogy. I'm only keen that our suggested values do one or both of these. ;-)

I think the use of the 'birth' element and typing it for the creation myth forms is something I'd never do, but understand that some might. Would other possible values of this type attribute on birth be: 'natural'(whatever that means), 'caesarian', etc? As someone who was "from his mother's womb. Untimely ripped." a birth of type="caesarian" seems reasonable to me. With maybe more accurate terms available: http://blog.johnsonmemorial.org/blog/what-type-of-birth-is-right-for-you-and-your-baby

@ebeshero

This comment has been minimized.

Copy link
Contributor

ebeshero commented Mar 23, 2017

@martindholmes Good points--I was about to add "atFloruit", but yes--those are all when conditions. In the case of socecStatus, it's a puzzle to consider what you would put in a @type attribute that would modify and extend the text node content. We'd want something that is a condition of the status being defined. And socecStatus is something I'd imagine would shift for many persons through the course of their lives, so I thought we might try something to suggest a plurality of statuses...

@ebeshero

This comment has been minimized.

Copy link
Contributor

ebeshero commented Mar 23, 2017

@jamescummings I'm definitely in favor of "caesarian" as a type on birth, so I hope we'll add that to the list.

Of course, vis a vis "the personal is the political" I don't think we are every going to succeed in being apolitical--as even studied neutrality and silence are political positions. And the attribute values we apply in personographies are perhaps always going to be political groundworks, no matter how uncomfortable that makes us. I think if we are honest with ourselves about that, perhaps what we are really after here is not a-politicality, but a politics of inclusiveness.

death puzzles me a little because the use of @type here might seem to beg a one-word label for cause of death, though I think that is semantically different for kind of death: physical or abstract. Thinking of mythical deaths, with "dissolution", I was trying to gesture to the cosmogonists and thinking of poor Hyacinth or Osiris or one of the accounts of Pan--the shredding-into-bits sort of mythic death that precedes reincarnation...

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Mar 23, 2017

@ebeshero for the cases that i m working with birth/death just don't have symmetrical typologies. For death a prominent question is if someone is transcending (i.e. reaching nirvana) or reentering the cycle of rebirth. But if you have cases where dissolution is a type the more the merrier.

I would like to differentiate between floruit dates which are claimed within some text, and those that I calculate based on some formula. But beyond that I struggle with good examples.

@martindholmes

This comment has been minimized.

Copy link
Contributor

martindholmes commented Mar 23, 2017

I think there might be an argument for @cause or @reason on <death> to ensure that @type isn't used for that. But it has a rich content model so there are lots of ways to elaborate on cause, location, and so on.

@jamescummings jamescummings added this to the Guidelines 3.2.0 milestone Mar 23, 2017

@sydb

This comment has been minimized.

Copy link
Member

sydb commented Apr 4, 2017

I agree that @type of <death> is not for the cause or reason. There really are two types of (human) death: "clinical" and "brain". (And, if I understand correctly, the latter can be further sub-classified by whether or not the brain stem is functioning.)
Other values that jump to my mind are "natural", "unnatural"; "presumed", "verified".

@bansp

This comment has been minimized.

Copy link
Member

bansp commented Apr 4, 2017

May I suggest that the TEI stick to providing frames for expressing typologies rather than typologies themselves? Or, to rephrase: how about sticking to what we have expertise on rather than venture into areas where it takes a single expert to prove us naked?

@lb42

This comment has been minimized.

Copy link
Member

lb42 commented Apr 4, 2017

For once, I entirely agree with Piotr.

@martindholmes

This comment has been minimized.

Copy link
Contributor

martindholmes commented Apr 4, 2017

These need not be formal suggested values; they could be shown in examples or suggested in the remarks. But most of the discussion around these values has been concerned with demonstrating that @type makes sense for these elements because plausible values exist, hasn't it?

@PFSchaffner

This comment has been minimized.

Copy link
Member

PFSchaffner commented Apr 4, 2017

For every spiritual second death (see Targum Jer.51.17 or Rev. 21:8), there is a spiritual second birth (or, in Wesley's case, third.) Then there are more metaphorical spiritual deaths ("that day he died as a writer"). When exactly did Dracula 'die'? As for ages, there are emotional and lexile ages too, the latter at least quantifiable.

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Apr 4, 2017

@martindholmes exactly. It looks that all but floruit have passed the test of either experts or wikipedia searchers.

@sydb

This comment has been minimized.

Copy link
Member

sydb commented Apr 11, 2017

I agree that @type of <death> is not for the cause or reason. There really are two types of (human) death: "clinical" and "brain". (And, if I understand correctly, the latter can be further sub-classified by whether or not the brain stem is functioning.)
Other values that jump to my mind are "natural", "unnatural"; "presumed", "verified".

@duncdrum

This comment has been minimized.

Copy link
Contributor

duncdrum commented Jun 5, 2017

@sydb status: go?

@sydb

This comment has been minimized.

Copy link
Member

sydb commented Jun 10, 2017

I went ahead and changed all those agreed upon above as listed below. In each case I put the values into an open value list, such that they are merely “sample values”, not even “suggested”, in the tagdoc.

I made these changes locally, and have not checked them in yet. If someone would tell me how to say to git “Yeah, I know I made these changes in the dev branch, but I want to check them into a new branch” I would do so. In the meantime, I have generated P5 from them and put the tagdocs in question up on my basement server.

An * means that I glossed the value.

element suggested values from above what I put in comments
affiliation sponsor, recommend, discredit, pledged sponsor, recommend, discredit, pledged SAME
age western, sui, subjective, objective, inWorld, chronological, biological, psychological, functional western, sui, subjective, objective, inWorld*, chronological, biological, psychological, functional SAME
birth accretion, secretion, exNihilo, rebirth caesarean*, vaginal*, exNihilo*, incorporated, founded, established
death proclaimed, assumed, announced, fragmentation, dissolution proclaimed, assumed, verified, clinical, brain, natural, unnatural, fragmentation, dissolution
education primary, secondary, apprenticeship, residency, undergraduate, graduate primary, secondary, undergraduate, graduate, residency, apprenticeship SAME
faith practicing, clandestine, patrilineal, matrilineal, convert practicing, clandestine, patrilineal, matrilineal, convert SAME
floruit calculated, claimed ? attested? NONE majority opposed @type
langKnowledge listening, speaking, reading, writing listening, speaking, reading, writing SAME
nationality birth, naturalised, self-assigned birth, naturalised, self-assigned SAME
occupation primary, other, paid, unpaid primary, other, paid, unpaid SAME
residence permanent, temporary, primary, secondary primary, secondary, temporary, permanent SAME
sex explicit, implicit explicit, implicit SAME
socecStatus atBirth atDeath dependent inherited independent atBirth, atDeath, dependent, inherited, independent SAME

What do folks think? Right values? Which, if any, need a gloss or description? If & when this seems close to OK to us, I can check it in for real.

sydb added a commit that referenced this issue Jun 23, 2017

Add @type to several children of of <person>
Addresses #1600, see discussion there.
@sydb

This comment has been minimized.

Copy link
Member

sydb commented Jun 23, 2017

Committed change described above (06-10 16:34) at eadbf47.
Just waiting to see that Mr. Jenkins is OK before closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment