Add <date> as mixed content child of <part>

[rockivist]

I'm logging a new feature request to replace #504 - the original feature request changed significantly in discussion and I thought it better to close that issue and open a fresh one that clearly states the current proposal.

@cannedit advocated for some mechanism to provide normalized dates within controlled access terms. His original proposal was to add @normal to <part>, but after discussion we resolved that the best option would be to add <date> as an optional, repeatable, mixed content child of <part>. That way the semantics of normalizing a date are not added to part, which is by definition a generic element, but as needed dates from a chronological segment of an authorized term could be normalized for indexing purposes (as needed by APE).

I support making this change as soon as possible.

[rockivist]

Implemented in branch issue_505. Wait for final approval to merge.

[rockivist]

@cannedit @SJagodzinski @noahgh221 @BillStockting2 As I just mentioned in an email to the EAD Subteam, I am eager to reach consensus on this issue so that we can make a recommendation to TS-EAS and move ahead with community review.

During our January conference call we briefly discussed this issue. We all agreed that it was appropriate to accommodate the date element within the data structure of the controlled access elements (persname, subject, genreform, etc.). We did not agree on whether we should allow date as a mixed content child of part, or if date should be allowed as an optional sibling of part within those elements.

I remain in favor of the former: allowing date as an optional mixed content child of part. One of the things we tried to do with EAD3 was mitigate the number of elements that can be used in both block and mixed content contexts. Adding date as a sibling of part would create another instance of block/mixed content conflation. Also, in my opinion, it is preferable to have the semantics associated with part, namely the identification of a given part of a term via the localtype or encodinganalog attributes, always be associated with the part element. This is more predictable from a data processing point of view. Adding date as a sibling of part will require developers to anticipate the presence of date - keeping date as a mixed content child of part will allow for date to be ignored when processing it is not relevant.

What do you think? If possible, please comment by the end of this week (Friday, 17 February).

[BillStockting2]

Mike,

That makes sense to me!

Bill

[Royal Crest]

Bill Stockting | Archives Manager | Royal Archives Windsor Castle | Berkshire | SL4 1NJ DDI: (78) 2260 | Ext: (78) 2260 www.royal.ukhttp://www.royal.uk [cid:image002.png@01D285E3.AF4AA1E0] http://www.facebook.com/thebritishmonarchy [cid:image003.png@01D285E3.AF4AA1E0] http://twitter.com/royalfamily [cid:image004.png@01D285E3.AF4AA1E0] http://www.youtube.com/user/theroyalchannel [cid:image005.png@01D285E3.AF4AA1E0] http://www.flickr.com/photos/britishmonarchy [cid:image006.png@01D285E3.AF4AA1E0] https://www.instagram.com/theroyalfamily/

From: Michael Rush [mailto:notifications@github.com] Sent: 12 February 2017 04:08 To: SAA-SDT/EAD3 Cc: Bill Stockting; Mention Subject: Re: [SAA-SDT/EAD3] Add as mixed content child of (#505)

@cannedithttps://github.com/cannedit @SJagodzinskihttps://github.com/SJagodzinski @noahgh221https://github.com/noahgh221 @BillStockting2https://github.com/BillStockting2 As I just mentioned in an email to the EAD Subteam, I am eager to reach consensus on this issue so that we can make a recommendation to TS-EAS and move ahead with community review.

During our January conference call we briefly discussed this issue. We all agreed that it was appropriate to accommodate the date element within the data structure of the controlled access elements (persname, subject, genreform, etc.). We did not agree on whether we should allow date as a mixed content child of part, or if date should be allowed as an optional sibling of part within those elements.

I remain in favor of the former: allowing date as an optional mixed content child of part. One of the things we tried to do with EAD3 was mitigate the number of elements that can be used in both block and mixed content contexts. Adding date as a sibling of part would create another instance of block/mixed content conflation. Also, in my opinion, it is preferable to have the semantics associated with part, namely the identification of a given part of a term via the localtype or encodinganalog attributes, always be associated with the part element. This is more predictable from a data processing point of view. Adding date as a sibling of part will require developers to anticipate the presence of date - keeping date as a mixed content child of part will allow for date to be ignored when processing it is not relevant.

What do you think? If possible, please comment by the end of this week (Friday, 17 February).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/SAA-SDT/EAD3/issues/505#issuecomment-279195467, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVi3JlPYgwVXodD20JQ8c1YHg4JuuInbks5rboWkgaJpZM4LIe0P.

Royal Household Legal Disclaimer - This message and any attachments should only be read by those persons to whom it is addressed and be used by them for its intended purpose. The Royal Household cannot accept liability for statements made which are clearly the sender's own and not made on behalf of the Royal Household. Replies to this email address may be subject to interception or monitoring for operational reasons or for lawful business purposes.

[noahgh221]

Mike,

I support adding <date> as an optional mixed content child of <part>. Thanks for explaining your logic.

[SJagodzinski]

Mike,

I see your point and understand your explanation. I do follow your points for e.g. //genreform or //corpname, but still hesitate with names tagged in multiple parts. See the TL example for //persname. Where to put the date in here?

`

Casey 1807-1882 Silas

`

For data processing you would always have to separate a date from one part and add this to the other part, too. In fact here we don't even know, if the date belongs only to the surname, because Silas has maybe another birthname.

I see your point with block/mixed content and that's a good argument to decide for your solution, even if I'm not absolutely convinced. So if we are going to implement //part/date the documentation needs to clarify uses cases mentioned above.

[cannedit]

Mike,

I agree with you to add <date> as an optional mixed content child of <part> like we already concluded in the discussion on issue 504.

@Silke: I think this will enable your example to be adapted like this:

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

And of course this enables to be more specific too, like using: @localtype="birthdate", @localtype="marriagedate", etc.

[ruthtillman]

@cannedit I like your example!

[SJagodzinski]

@cannedit: I like your example, too and you're right. This solution clears my concerns. @rockivist: I also agree. @all: Sorry, I was slow to catch on

[rockivist]

Thanks everyone for weighing in! I'll share this with TS-EAS for their input and advice on how best to vet this with the user community.

[karinbredenberg]

I agree with the addition but be careful with what is used as examples in localtype, marriagedate are in my opinion more suitable to use in EAC-CPF than in EAD.

[MicheleCombs]

Agreed.

Michele

From: Karin Bredenberg [mailto:notifications@github.com] Sent: Thursday, March 16, 2017 10:44 AM To: SAA-SDT/EAD3 EAD3@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [SAA-SDT/EAD3] Add as mixed content child of (#505)

I agree with the addition but be careful with what is used as examples in localtype, marriagedate are in my opinion more suitable to use in EAC-CPF than in EAD.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/SAA-SDT/EAD3/issues/505#issuecomment-287079226, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB1rY8kUIk-X6YkvwBhkHBUAosT0AH-wks5rmUqqgaJpZM4LIe0P.

[rockivist]

@fordmadox Looks good in the 1.1 release candidates.

[rockivist]

@fordmadox Looks good in all six 1.1.2 release candidate schemas.

[noahgh221]

Included in EAD3 v1.1.0 release. Closing issue.