Skip to content
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

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

Closed
rockivist opened this issue Dec 9, 2016 · 14 comments
Closed

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

rockivist opened this issue Dec 9, 2016 · 14 comments

Comments

@rockivist
Copy link
Member

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 added a commit that referenced this issue Feb 4, 2017
Added date as a mixed content optional child of part. To do this I
created a new mixed content model called m.mixed.basic.date.
@rockivist
Copy link
Member Author

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

@rockivist
Copy link
Member Author

@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
Copy link

BillStockting2 commented Feb 13, 2017 via email

@noahgh221
Copy link
Member

noahgh221 commented Feb 13, 2017

Mike,

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

@SJagodzinski
Copy link

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?

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

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
Copy link
Contributor

cannedit commented Feb 20, 2017

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
Copy link

@cannedit I like your example!

@SJagodzinski
Copy link

@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
Copy link
Member Author

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
Copy link
Member

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
Copy link

MicheleCombs commented Mar 16, 2017 via email

@rockivist
Copy link
Member Author

@fordmadox Looks good in the 1.1 release candidates.

@rockivist
Copy link
Member Author

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

@noahgh221
Copy link
Member

Included in EAD3 v1.1.0 release. Closing issue.

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

No branches or pull requests

9 participants