Standardized rights

[edgartdata]

Work done to align YCBA's rights language with Creative Commons and RightsStatements.org to do:

The ‘Image Use’ facet with 2 values mapped to the old ones, and the logos of Creative Commons and RightsStatements are now appearing for rights on the item pages in DEV collections-test:

https://collections-test.britishart.yale.edu/catalog/tms:1109 public domain https://collections-test.britishart.yale.edu/catalog/tms:1186 in copyright https://collections-test.britishart.yale.edu/catalog//tms:1505 copyright undetermined https://collections-test.britishart.yale.edu/catalog/orbis:3225019 public domain https://collections-test.britishart.yale.edu/catalog/orbis:11327404 in copyright https://collections-test.britishart.yale.edu/catalog/orbis:3293587 copyright undetermined

Please review and prepare feedback for next meeting.

[edgartdata]

@flapka's and Rare Books' feedback:

1. I’m fine with how the new CC logos look in the online catalog, though the button bar stands out to me as one of the areas where we might benefit most from the help of a graphic designer (wishful thinking, I know).
2. The CC logo gets a little bit lost on my mobile device. See screenshot.
3. I am concerned about the new values that show up under the “Rights” facet. “Under Certain Circumstances” as a standalone value seems inadequate. I wonder too if the facet should be named, given the emphasis on what you can do with the images. Should it be called something like “Image Reuse” or “Image Rights” or “Image Reuse Rights”?

[edgartdata]

Let's go with "Image Use' for the title of this facet.

[flapka]

In our discussion about rights modeling and mapping yesterday, we noted that we may want to pivot to using the MARC field intended for use rights (540) rather than the MARC field for copyright (542) -- especially in view of how the data may be vended and mapped from YUL to LUX. To recap, here are examples of RBM's current practice

542 0_ |f Public Domain |l public domain |q CtY-BA |u http://id.loc.gov/vocabulary/preservation/copyrightStatus/pub

542 0_ |f Copyright Information |l unknown |q CtY-BA |u http://id.loc.gov/vocabulary/preservation/copyrightStatus/unk

542 0_ |d John Dilnot |f © John Dilnot |l under copyright |q CtY-BA |u http://id.loc.gov/vocabulary/preservation/copyrightStatus/cpr

Their equivalents using a 540 instead could be something like:

540 __ |f Public Domain |q CtY-BA |u https://creativecommons.org/publicdomain/zero/1.0/

540 __ |f Copyright Undetermined |q CtY-BA |u http://rightsstatements.org/vocab/UND/1.0/

540 __ |a © John Dilnot |f In Copyright |q CtY-BA |u http://rightsstatements.org/vocab/InC/1.0/

Issues / concerns:

1. I'm a little bit uncertain about the last example. It's unclear whether a statement such as "© John Dilnot" matches the definition of 540 subfield $a. I welcome thoughts from others. If there's no home for such a phrase in field 540, I suppose could consider leaving that information in field 542.
2. In YUL special collections, field 540 is commonly used to document use restrictions on archival collections, in a manner less structured than what I've described above. See examples in [YUL documentation].(https://web.library.yale.edu/cataloging/manuscript/5xx#540). It's not clear whether this would create a mapping conflict in LUX.

[edgartdata]

@flapka Thanks for this Francis. Did you have a chance to connect with Tim Thompson on YUL's usage of the 542 and 540 fields?

[flapka]

@edgartdata @mxgold @Lcallery Tim has recommended a discussion with select YUL colleagues (neither 540 nor 542 are currently mapped to LUX).

Before I bring this to LUX, I'd like to float a new possibility, and I apologize in advance for the ugliness of MARC. Just days ago, MARC approved changes to the 856 field that would enable the addition of image use data there, perhaps instead of the MARC 540. When RBM has images of an object, we already use the 856 in this fashion:

856 41 |y View a selection of digital images in the Yale Center for British Art's online catalog |u http://collections.britishart.yale.edu/vufind/Record/2038220

If we were to use the same field for use information, it might be rendered something like this:

856 41 |y View a selection of digital images in the Yale Center for British Art's online catalog |r Public Domain |r https://creativecommons.org/publicdomain/zero/1.0/ |u http://collections.britishart.yale.edu/vufind/Record/2038220

I like that this option associates the use rights specifically with the YCBA set of images, whereas a 540 field would generically associate the use rights with the analog object. (Keep in mind there are cases when YCBA shares a record with Beinecke and we both have images of it.)

What do you think?

[mxgold]

Agreed, this seems like a great solution, and fortuitous timing!

[edgartdata]

Great! @flapka Are you going to coordinate with Eric on this?

[flapka]

There are a couple of dependencies to solve before we can move forward with this altered MARC encoding.

1. The new 856 subfields are so new that they're not yet available at Yale. They should be implemented by September.
2. In alignment with recently updated YUL best practices, we really should put 856 field links in the Holdings record. If we do that, it takes us back to the long-standing problem we have with indexing Holdings data, in our current harvesting routines. Metadata Cloud may provide a solution, but I need to explore this option more (will do so in the week ahead).
3. At Tim Thompson's suggestion, my proposal for adding use rights data to field 856 has been forwarded to Mark Custer and YUL's Metadata for Digital Assets Advisory Group. Here's what I wrote to that group:

For material digitized in the Department of Rare Books & Mss at the YCBA, we’d like to add data about image use rights to the Holdings of the corresponding MARC record. Our rights data would make use of controlled vocabularies from rightsstatements.org and Creative Commons to tell users what they may do with images (in the Center’s online catalog). We tentatively hope to make use of new rights-related subfields in MARC 856. The 856 would be placed in the YCBA Holdings record, following guidance of the YUL e-variant TF. Three examples:

• 856 41 |y View a selection of digital images in the Yale Center for British Art's online catalog |r Copyright Undetermined |r http://rightsstatements.org/vocab/UND/1.0/ |u https://collections.britishart.yale.edu/catalog/orbis:3429277

• 856 41 |y View a selection of digital images in the Yale Center for British Art's online catalog |r In Copyright |r http://rightsstatements.org/vocab/InC/1.0/ |t © John Dilnot |u https://collections.britishart.yale.edu/catalog/orbis:10465113

• 856 41 |y View a selection of digital images in the Yale Center for British Art's online catalog |r Public Domain |r https://creativecommons.org/publicdomain/zero/1.0/ |u https://collections.britishart.yale.edu/catalog/orbis:579093

Initial questions:

1. Would the above approach conflict with or cause trouble with YUL practice?
2. Could we map the 856 subfields for use rights to the corresponding fields in LUX? YCBA would like the data to appear there too.
3. Are there other MARC fields that should also be mapped to LUX’s fields for use rights (e.g. the 540)?

[yulgit1]

My concern would be the impact this would have on indexing speed. Including the rights on the show page from the mfhd should be doable. But making a URL call to holdings for each asset so it is available as a facet would slow the process down considerably and introduce a dependency on the network that could be a cause for other problems.

[flapka]

@yulgit1 Agree, this would be un-implementable in our current harvesting routine (because of indexing slowness). A possible appeal of the MetadataCloud harvesting routine -- if MC provides all necessary data -- is that it may bundle the necessary Holdings data with the rest of the Bib data, obviating the need for a separate call to the MFHD.

[edgartdata]

@flapka Thanks for this update. A couple of follow up questions: While we wait for 856 to be added to the Holdings record, is RBM going to keep using 540? When 856 is added to the Holdings record, will RBM be able to migrate the 540 field values in bulk to 856?

[flapka]

@edgartdata

1. Yes, I propose we maintain current rights usage (in 542) until we are ready to implement all aspects of the change in practice, thinking that such uniformity should make it easier to run the batch changes.
2. I hope so! It's of medium complexity, and I have fingers crossed that our kind YUL colleagues could help out.

[yulgit1]

Assuming we're currently going ahead the current usage (542). We had also discussed using "Copyright Not Evaluated" (http://rightsstatements.org/vocab/CNE/1.0/).

@flapka @mxgold Should CNE be the default if there is no 542? Will CNE ever be in the 542 like:

542 0_ |f Copyright Not Evaluated |l copyright not evaluated ...

Asking so as to implement the xslt and index mapping.

[flapka]

It's my understanding that CNE has been/would be implemented only (?) when the MARC record lacks a rights field (542 for now). @Lcallery or @mxgold can correct this if I've mis-remembered.

[flapka]

I met with YUL's Meta-Digets advisory group today to discuss the changes proposed above and related matters. Outcomes:

1. The group supports our use of the new 856 subfields (r and t) for use rights. YUL may not follow suit, but they foresee no conflicts for now.
2. It appears likely that the data values in these subfields would not display in Orbis, which is I think the desired outcome (our 542 fields do not display either).
3. Mark Custer encouraged us to also apply 856 subfield 7, to record the open access binary (open or restricted). Our material would all be open, right?
4. In YUL special collections, it looks like they'll soon implement a new twist for Voyager records describing objects that have been digitized. In addition to providing a link to the object in YUL Digital Collections (a mirror of sorts to our links to the YCBA catalog), they will also add the corresponding iiif manifest, though that manifest may essentially be hidden in current Orbis/Quicksearch displays (it's a bit fuzzy). Possible benefits (among others): [1] that iiif manifest may drive image display in LUX; [2] a future YUL discovery environment (Orbis replacement) may use the manifest to display images within the YUL catalog. With these benefits in mind, my initial sense is that we would also want to add the iiif manifest to our records, where applicable.

[yulgit1]

These 856s will go in bib records, not holdings, correct?

[flapka]

These 856s will go in bib records, not holdings, correct?

:) Painful as it is to say, they really should go in Holdings, for multiple reasons (including new YUL best practices). Of course we can't index Holdings data yet. We are exploring solutions to this dilemma.

[flapka]

Access to Holdings data now looks viable. See issue #412.

Following what's discussed above, using field 856 in the holdings (replacing 542 in the bib record), the new mappings would be like so, I think:

• ort_ss / ort_text = 856 $t
• rightsURL_ss / rightsURL_txt = 856 $r
• rights_ss / rights_text = derived from 856 $r?

Example data: • 856 41 |y View a selection of digital images in the Yale Center for British Art's online catalog |r http://rightsstatements.org/vocab/UND/1.0/ |t Copyright Undetermined |u https://collections.britishart.yale.edu/catalog/orbis:3429277

• 856 41 |y View a selection of digital images in the Yale Center for British Art's online catalog |r http://rightsstatements.org/vocab/InC/1.0/ |t © John Dilnot |u https://collections.britishart.yale.edu/catalog/orbis:10465113

• 856 41 |y View a selection of digital images in the Yale Center for British Art's online catalog |r https://creativecommons.org/publicdomain/zero/1.0/ |t Public Domain |u https://collections.britishart.yale.edu/catalog/orbis:579093

Does the above look correct, @mxgold @yulgit1