-
Notifications
You must be signed in to change notification settings - Fork 25
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
Comments
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.
Implemented in branch issue_505. Wait for final approval to merge. |
@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). |
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.uk<http://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 <date> as mixed content child of <part> (#505)
@cannedit<https://github.com/cannedit> @SJagodzinski<https://github.com/SJagodzinski> @noahgh221<https://github.com/noahgh221> @BillStockting2<https://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 GitHub<#505 (comment)>, or mute the thread<https://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.
|
Mike, I support adding |
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?
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. |
Mike, I agree with you to add @silke: I think this will enable your example to be adapted like this:
And of course this enables to be more specific too, like using: @localtype="birthdate", @localtype="marriagedate", etc. |
@cannedit I like your example! |
@cannedit: I like your example, too and you're right. This solution clears my concerns. |
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. |
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. |
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 <date> as mixed content child of <part> (#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 GitHub<#505 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AB1rY8kUIk-X6YkvwBhkHBUAosT0AH-wks5rmUqqgaJpZM4LIe0P>.
|
@fordmadox Looks good in the 1.1 release candidates. |
@fordmadox Looks good in all six 1.1.2 release candidate schemas. |
Included in EAD3 v1.1.0 release. Closing issue. |
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.
The text was updated successfully, but these errors were encountered: