Add <rightsdeclaration> to <control>

[rockivist]

I propose adding a new element to EAD3 for recording the rights associated with the description itself. A common use case would be to declare that the description is shared under a CC0 license.

I suggest naming the element <rightsdeclaration>, following the name pattern of conventiondeclaration, languagedeclaration, and localtypedeclaration. I would pattern the content model after <conventiondeclaration>, which includes a required <citation> element, and optional <abbr> and <descriptivenote> elements. One important difference would be including the @localtype attribute on the <rightsdeclaration> element so that it can be subclassed as necessary.

Here is an example of a possible <rightsdeclaration> element:

` CC0

CC0 1.0 Universal (CC0 1.0)

`

I would make <rightsdeclaration> an optional, repeatable child of <control>, available as a following sibling of conventiondeclaration and a preceding sibling of localtypedeclaration.

[ruthtillman]

Like it overall. One question: what does it look like for those who want to put an "All rights reserved" in the rights declaration?

Although RightsStatements seem to be more appropriate for materials as CC is more appropriate for finding aids, I suppose it could be http://rightsstatements.org/vocab/InC/1.0/ with text "All rights reserved" ... Or are we going to say "if you want it in copyright have your own URL to your copyright statement"?

[rockivist]

@ruthtillman you've identified the major weakness as I see it. I think it's OK for <rightsdeclaration> to prioritize linking out to separate rights statements. If someone wants to simply put a copyright statement not linked to a formal rights statement, they can still put a paragraph in <publicationstmt>. I think we're trying to focus on something actionable with the new element, and there isn't much you can do with a simple text string in that regard. Happy to hear conflicting opinions, of course.

[ruthtillman]

@rockivist I like the idea of adding that to guidance about using the new element. aka "<publicationstmt> still exists if all you want to do is note that you retain copyright, whereas this is for actionable link-based statements, whether yours or mainstream. Please use mainstream." -- but nicer.

[SJagodzinski]

I'm in favour of the solution forwarded by Wim (//rightsdeclaration/rightsinfo) because we do know about the semantic of the elements content and we don't need to use a general descriptive or referring element for that. In my opinion it would be more distinct and neat for this purpose. I'd also allow content in //rightsinfo, so there is no need for //p, but I'm not familiar with the EAD politics here.

example: example: `

CC0 © 1998 Regents University of California `

[rockivist]

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

[tcatapano]

Looks like we need to compile this and #485, #506, and #507 into the various derived RNG, DTD, and XSD files for testing before merging. Is that right? If so, I'll create an issue and assign to myself.

[rockivist]

@tcatapano yes, that would be very helpful.

[tcatapano]

OK. I'll make an issue. See #509

[rockivist]

@cannedit @SJagodzinski @noahgh221 @BillStockting2 Following up on this issue, here are my arguments in favor of implementing rightsdeclaration as I described it above rather than as a rightsdeclaration with one or more rightsinfo elements.

-The pattern set in EAC-CPF and perpetuated in EAD3 within control is not to bundle the "declaration" elements (languagedeclaration, conventiondeclaration, localtypedeclaration) into wrapper elements. Having rightsdeclaration include one or more rightsinfo elements would change this convention. The revision process taught me to value consistent conventions highly, hence my preference.

-I also prefer the predictability that comes from two elements (conventiondeclaration and the proposed rightsdeclaration) sharing data models. They are conceptually similar, referencing external docments/resources in an actionable. way. It's easier to teach and to develop systems when they are structured similarly.

-I see the proposed rightsdeclaratoin/citation and rightsdeclaration/rightsinfo as essentially equivalent, so comparing the two proposed data models comes down to the additional presence of abbr and descriptivenote. Regarding descriptivenote,, we have included it in nearly all of the "declaratoin" elements in EAC and EAD3. Omitting it would again change a consistently followed convention. Omitting abbr would be less of a contradiction of convention, but I do think it is helpful to separate out an abbreviation used to refer to something from the citation for the thing itself.

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

[BillStockting2]

Mike,

Again I agree with your suggestions, consistency is as you say important for users and developers alike.

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@01D285E4.03EAC180] http://www.facebook.com/thebritishmonarchy [cid:image003.png@01D285E4.03EAC180] http://twitter.com/royalfamily [cid:image004.png@01D285E4.03EAC180] http://www.youtube.com/user/theroyalchannel [cid:image005.png@01D285E4.03EAC180] http://www.flickr.com/photos/britishmonarchy [cid:image006.png@01D285E4.03EAC180] https://www.instagram.com/theroyalfamily/

From: Michael Rush [mailto:notifications@github.com] Sent: 12 February 2017 04:32 To: SAA-SDT/EAD3 Cc: Bill Stockting; Mention Subject: Re: [SAA-SDT/EAD3] Add to (#506)

@cannedithttps://github.com/cannedit @SJagodzinskihttps://github.com/SJagodzinski @noahgh221https://github.com/noahgh221 @BillStockting2https://github.com/BillStockting2 Following up on this issue, here are my arguments in favor of implementing rightsdeclaration as I described it above rather than as a rightsdeclaration with one or more rightsinfo elements.

-The pattern set in EAC-CPF and perpetuated in EAD3 within control is not to bundle the "declaration" elements (languagedeclaration, conventiondeclaration, localtypedeclaration) into wrapper elements. Having rightsdeclaration include one or more rightsinfo elements would change this convention. The revision process taught me to value consistent conventions highly, hence my preference.

-I also prefer the predictability that comes from two elements (conventiondeclaration and the proposed rightsdeclaration) sharing data models. They are conceptually similar, referencing external docments/resources in an actionable. way. It's easier to teach and to develop systems when they are structured similarly.

-I see the proposed rightsdeclaratoin/citation and rightsdeclaration/rightsinfo as essentially equivalent, so comparing the two proposed data models comes down to the additional presence of abbr and descriptivenote. Regarding descriptivenote,, we have included it in nearly all of the "declaratoin" elements in EAC and EAD3. Omitting it would again change a consistently followed convention. Omitting abbr would be less of a contradiction of convention, but I do think it is helpful to separate out an abbreviation used to refer to something from the citation for the thing itself.

What do all of you think? 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/506#issuecomment-279196222, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVi3Jpn9XL5nSyty7Lvtw2IaOoJd5Ameks5rbotSgaJpZM4LIfIN.

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]

@rockivist I support your suggestion to add and have it follow the same convention as languagedeclaration, conventiondeclaration, and localtypedeclaration.

I think it would be desirable to accommodate local, not machine-actionable, rights statements in instead of recommending use of a separate element, but I can't quite think of an appropriate way to do that...

[rockivist]

@noahgh221 In cases where the metadata isn't available under a shared, published license that can be referenced in an actionable way, there is always publicationstmt/p. Not perfect, but it's a fallback for unstructured rights info.

[SJagodzinski]

Mike,

ok you're right, I'm convinced. Following the other declarations here seems feasible. I agree with your suggestion.

[cannedit]

Mike,

I agree with your proposal.

[rockivist]

Thanks all! Will forward to TS-EAS.

[rockivist]

@fordmadox Testing successful in all six 1.1 release candidate schemas.

[rockivist]

@fordmadox Testing successful in all six 1.1.2 release candidate schemas.

[noahgh221]

Feature included in EAD3 v1.1.0 release. Closing issue.