please allow @normal for <part/>

[cannedit]

My use case for this: I intend to use the following tagging:

<persname>
           <part localtype=”firstname”>Ludovicus</part>
           <part localtype=”lastname”>Broecken</part>
           <part localtype=”residence”>Bergen op Zoom</part>
           <part localtype=”role”>overledene [which is Dutch for “deceased”]</part>
           <part localtype=”deathdate”>30 november 1916</part>
</persname>

but unfortunately I can’t normalise the date like this:

<persname>
           <part localtype=”firstname”>Ludovicus</part>
           <part localtype=”lastname”>Broecken</part>
           <part localtype=”residence”>Bergen op Zoom</part>
           <part localtype=”role”>overledene [which is Dutch for “deceased”]</part>
           <part localtype=”deathdate” normal=”1916/11/30”>30 november 1916</part>
</persname>

[rockivist]

I’ve been thinking a bit more about your suggestion. I remain reluctant to adopt the specific solution you suggest for a few reasons.

1) I agree with Regina’s argument that any attribute on an element should be applicable to most use cases for that element, not a specific subset. <part> is explicitly for identifying a substring in a controlled term – it’s not specific to dates. 2) We moved away from the@normal attribute in EAD3. The only date elements where it is allowed is <date> and <unitdate> - this was specifically to accommodate legacy usage of @normal as requested by Kerstin Arnold. Otherwise we shifted toward the EAC-CPF model of using @standarddate, @fromdate, and @todate wherever possible. I’d be reluctant to introduce a new use for the old date normalization model. 3) It would introduce a difference between the use of <part> in EAC and <part> in EAD3 – they are quite similar currently.

That said, I see a strong use case for allowing date strings in name authorities to be machine actionable. My current thinking is that the best solution would be to add <date> as an optional sibling to <part>. This would give you the option to use @normal for date segments, would prevent changes to <part>, and would still prevent mixed content in access term elements.

[cannedit]

Ok, I see your point (and Regina’s and Ruth’s ☺). So let’s not discuss this any further and go for this. Then the current example of the EAD3 tag library for <part/> would be like this, right?

<persname encodinganalog="600" relator="creator" rules="RDA" identifier="http://viaf.org/viaf/23746712">
<part localtype="surname">Casey</part>
<part localtype="givenname">Silas</part>
<part localtype="dates"><date @normal="1807/1882">1807-1882</date></part>
</persname>

That would be fine with me, because then we can still re-use the part of our code which runs on “old fashioned” date normalization, which was probably what Kerstin Arnold was aiming at :-).

[rockivist]

Wim,

I was thinking of making <date> an optional sibling of <part>, not a child. so something more like this:

`

Casey Silas

<date @normal="1807/1882">1807-1882 `

Would that work? I'm reluctant to change <part>'s mixed content model, but I'd need to think about it some more.

When we are in a position to make changes to EAD3 we can revisit this, so we'll keep the issue open.

[cannedit]

So actually making <date/> a child of <persname/> instead of a child of <part/>?

Ehmm, sorry, no, that doesn't work, because I would like to have more <part/>'s including dates within a <persname/> (and <corpname/> and <famname/>), like for instance having as @localtype "birthdate", "marriagedate" and "deathdate" (and others).

[rockivist]

@cannedit Ah yes, I hadn't thought of that. Then I agree the best solution will be adding <date> as an optional mixed content child of <part>.

[rockivist]

Closing - replaced with #505