University of California Curation Center Merritt Data User Agreements Rev Introduction. 2 Data user agreements

Size: px

Start display at page:

Download "University of California Curation Center Merritt Data User Agreements Rev Introduction. 2 Data user agreements"

Diana Kennedy
5 years ago
Views:

1 University of California Curation Center Merritt Data User Agreements Rev Introduction Information technology and resources have become integral and indispensable to the pedagogic mission of the University of California. Members of the UC community routinely produce and utilize a wide variety of digital assets in the course of teaching, learning, and research. These assets represent the intellectual capital of the University; they have inherent enduring value and need to be managed carefully to ensure that they will remain available for use by future scholars. Within the UC system the UC Curation Center (UC3) of the California Digital Library (CDL) has a broad mandate to ensure the long-term usability of the digital assets of the University. UC3 views its mission in terms of digital curation, the set of policies and practices aimed at maintaining and adding value to authentic digital assets for use by scholars now and into the indefinite future [Abbott]. In order to meet these obligations UC3 is developing Merritt, an emergent approach to digital curation infrastructure [Merritt]. Merritt devolves infrastructure function into a growing set of granular, orthogonal, but interoperable micro-services embodying curation values and strategies [Foundations]. Since each of the services is small and self-contained, they are collectively easier to develop, deploy, maintain and enhance [Denning]; equally as important, since the level of investment in and commitment to any given service is small, they are more easily replaced when they have outlived their usefulness. Yet at the same time, complex curation functionality can emerge from the strategic combination of individual, atomistic services [Fisher]. In order to provide content curators the fullest possible control over the use of their content, Merritt supports enforceable data use agreements (DUAs), the terms of which must be agreed to by content consumers prior to use. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119 [RFC2119]. 2 Data user agreements Merritt data user agreements (DUAs) are enforced by a click-through a popup similar to Figure 1. The major configurable components of a DUA SHALL include: Short identifier. Descriptive title. Comprehensive terms of use. Obligation of consumer-supplied acceptance checkbox, name, institutional affiliation, and Merritt Data User Agreements Page 1 of 6

2 address: required, optional, or none. Scope of applicability: collection, object, version, or file. Scope of persistence: request, session, or permanent. Notification addresses (of the responsible curatorial agents). : In the initial implementation, Merritt will require the acceptance checkbox and consumer name, institutional affiliation, and address, and will support only collection applicability and request persistence scope. Title title title title title title title title Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. Terms of use terms of use. I accept all terms Name Affiliation Required Submit Decline Figure 1 Data user agreement click-through display Additionally, DUA support SHOULD include some provision for customization of the overall look and feel of the click-through popup, possibly including a logo. 2.1 Definition The DUA configuration options are defined in a Merritt DUA metadata file, mrt-dua.txt and a DUA template file, mrt-dua-template.xml. The behavior defined by a collection-level DUA SHALL be inherited by all objects that are members of that collection, unless explicitly overridden by a object-level DUA, and similarly for versions and files. The DUA metadata file, mrt-dua.txt, defining the overall behavior of the DUA, is an ANVLformatted file [ANVL] of the following form: Identifier: identifier Title: title Terms: terms-of-use Accept: obligation Name: obligation Affiliation: obligation obligation Applicability: applicability Merritt Data User Agreements Page 2 of 6

3 Persistence: persistence Notification: curatorial- [; curatorial- ;... ] where brackets [ and ] enclose optional elements and an ellipsis indicates arbitrary repetition of the previous element. The short DUA identifier may reference well known license terms, such as cc-by for the Creative Commons Attribution license, or be specific to a collection or object, for examples, ucsf_datashare for the UCSF DataShare project. The Accept, Name, Affiliation, and elements specify the obligation (and appearance) of the acceptance checkbox and the name, affiliation, and text boxes. The obligation value MUST be required, optional, or none. If none is specified then the associated element MUST not be displayed in the click-through pop-up. The pop-up MUST incorporate some visual indicator associated with required credentials to distinguish them from optional, for example, the red asterisk used in Figure 1. The scope of applicability MUST be collection, object, version, or file. The enforceable DUA behavior associated with collection scope MUST be inherited by all objects that are members of that collection, unless specifically overridden by other behavior defined with object scope, and similarly for versions and files. In the initial implementation, Merritt will support only collection applicability scope. The scope of persistence MUST be request, session, or permanent. If request, the DUA MUST be accepted prior to every access request; if session, the DUA MUST be accepted only once per session; if permanent, the DUA MUST be accepted only once, within a given scope of applicability. In the initial implementation, Merritt will support only request persistence scope. Note that this implies that the initial implementation is stateless. The notification addresses are those of the responsible curatorial agents, whether individual or corporate. At least one address MUST be provided; more MAY be optionally provided. All programmatic matching of element names and values by Merritt MUST be performed on a caseinsensitive basis. The DUA template file, mrt-dua-template.xml, defining the DUA terms of use, is an XHTMLformatted file [XHTML] of the following minimal form: <?xml version= 1.0 encoding= UTF-8?> Merritt Data User Agreements Page 3 of 6

4 <!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN <html xmlns= xml:lang= en lang= en > <head> <title>title...</title> </head> <body> <p>terms-of-use...</p> </body> </html> The DUA template file MUST be valid with respect to the XHTML 1.0 Strict DTD and MUST define the DUA title and terms of use. The file MAY include any valid XHTML markup for purposes of structural layout and look-and-feel of the terms of use, including additional paragraphs, lists, <div> and <span> elements, class and style attributes, and references to external CSS stylesheets [CSS] and images. However, the file MUST NOT include a <form> element controlling the pop-up check-box, text boxes, or submission buttons. These elements will be implicitly added to the pop-up by the Merritt system. Note that the DUA title and terms of use are duplicated between the two files. It is the responsibility of a Merritt collection owner to ensure that both expressions are identical. 2.2 Acquisition A DUA metadata file, mrt-dua.txt, and template file, mrt-dua-template.xml, MAY be included as a file-level component of any Merritt collection object. Note that these two files MUST be included or excluded as a pair, that is, neither SHALL be present without the other. 2.3 Enforcement Merritt MUST NOT provide access to content data covered by the terms of a DUA until that DUA has been affirmatively accepted. Note, however, that a DUA only controls access to content data, not metadata. Merritt supports three data access modes: Downloading an object, i.e., clicking the Download button on an object landing page in the Merritt UI, or equivalently sending an API POST request to objectid. Downloading a version, i.e., clicking the Download button on a version landing page in the Merritt UI, or equivalently sending an API POST request to objectid/versionid. Viewing or downloading a file, i.e., clicking an actionable file link on an object or version landing page in the Merritt UI, or equivalently sending an API GET request to Merritt Data User Agreements Page 4 of 6

5 2.4 Notification A copy of the accepted DUA MUST be ed to the accepting user agent at the provided address, the curatorial agents at the notification addresses defined in the mrt-dua.txt file, and the UC3 support address, uc3@ucop.edu, with the following form: From: no-reply-merritt@ucop.edu Reply-to: curatorial- To: consumer- Subject: Merritt DUA acceptance: title... Name: name Affiliation: affiliation Collection: collection Object: object-identifier Date: yyyy-mm-dd hh:mm:ss±hh:mm Terms of use: Terms-of-use... Note that the To: address field will be variously: the accepting user agent, consumer- ; the curatorial agent, curatorial- ; and the UC3 support address, uc3@ucop.edu. 3 Implementation In order to support the necessary function described in Section 2, the Merritt UI MUST rely on a persistent data structure of the following conceptual form: Name Type Null? Indexed? Check PK Collection VARCHAR No Yes Identifier VARCHAR No Yes Title VARCHAR No No Terms VARCHAR No No Template TEXT No No Accept VARCHAR No No Name VARCHAR No No Affiliation VARCHAR No No required, optional, none VARCHAR No No Persistence VARCHAR No No request, session, permanent Notification VARCHAR No Yes This data structure is described in SQL-like terms for clarity; non-rdbms implementation options MAY be used. The DUA click-through pop-up SHALL be displayed as HTML [HTML]. The DUA template file, mrtdua-template.xml, defines the terms of use and their overall layout structure and look-and-feel. Merritt Data User Agreements Page 5 of 6

6 When actually displaying the DUA pop-up the Merritt system SHALL implicitly add an HTML <form> element with subsidiary <input> elements consistent with the information specified in the DUA metadata file, mrt-dua.txt. Conceptually, the point of insertion is immediately prior to the closing </body> tag of the template file. References [Abbott] Daisy Abbott, What is Digital Curation? April 3, 2008 < [ANVL] UC Curation Center, ANVL: A Simple Record Syntax, [CSS] [Denning] [Fisher] Bert Bost, Tantek Çelik, Ian Hickson, and Håkon Wium Lie, Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification, W3C Recommendation, June 7, Peter J. Denning, Chris Gunderson, and Rich Hayes-Roth, Evolutionary system development, Communications of the ACM 51:17 (December 2008): David A. Fisher, An Emergent Perspective on Interoperation in Systems of Systems, CMU/SEI-2006-TR-003, ESC-TR , March 2006 < [Foundations] UC3, Digital Preservation Program: Foundations, [HTML] Dave Raggett, Arnaud Le Hors, and Ian Jacobs, eds., HTML 4.01 Specification, W3C Recommendation, December 24, 1999 < [Ingest] UC Curation Center, Merritt Ingest Service, [Merritt] UC Curation Center, Merritt: An Emergent Approach to Digital Curation Infrastructure, [MOM] UC Curation Center, Merritt Object Model, [XHTML] World Wide Web Consortium, XHTML 1.0 The Extensible HyperText Markup Language (Second Edition): A Reformulation of HTML 4 in XML 1.0, W3C Recommendation, January 26, 2000, revised, August 1, 2002 < Merritt Data User Agreements Page 6 of 6

Network Working Group Request for Comments: 2318 Category: Informational W3C March 1998

Network Working Group Request for Comments: 2318 Category: Informational H. Lie B. Bos C. Lilley W3C March 1998 The text/css Media Type Status of this Memo This memo provides information for the Internet