Collaboration Documents
- Bill Branan
Basics
These documents make up the mappings we have worked on as a group. Notes for the discussion related to this can be found in the group notes in roughly the order these documents are listed. Do note that there are sometimes "two mappings" for one concept. This is because not every institution requires the same level of fidelity in their data. In the case of the two mappings, there is often a "simple" case that doesn't require the minting of other objects and a "complex" case that would require objects to be minted.
Title
Most other systems use the mappings found in the "Simple" tag that drop certain pieces of data from the title (such as if it was a supplied title or not). Keep in mind the Dublin Core Terms title must be used with a string literal as outlined in the simple example.
In the complex mapping, there is a Dublin Core Elements Title mapping (that isn't limited to a string element like Dublin Core Terms) and a SKOSXL Preflabel. This is due to Parallel Titles existing where two different titles are technically both a "primary" title of the object but your system (and others) need to know which of the two valid titles might be best to use for a single title display. In this case, the SKOSXL version is the one your system recommends using.
Name
Unlike other collaboration documents, the "Complex" case is the same as the "Simple" case but just has a bunch of optional fields to further split up certain data elements (like birth and death dates). In the case of birth and death dates in the "Complex" case are only valid for exact dates and do not support things like "circa". In the case the date isn't a simple date in the complex case, it simply gets appended to the name as in the Simple mappings (row 27 of the advanced mapping).
One other note is the three RDF type mappings for the minted objects: foaf:Person for an individual, foaf:Organization for organizations and conferences, and foaf:Agent if you don't know what type of name it is.
Type of Resource
Genre
The predicate used for this was based on DPLA Map.
OriginInfo (things like Place of Publication and Dates)
This sheet actually has three tabs to it. The first deals with how most will handle publisher, place of publication, etc. The second tab is a more complex example that can relate the "event" (like publication or manufacturer) with what location that occurred at. The last tab of this spreadsheet deals with dates and primarily uses EDTF that handles the vast majority of cases. The main exception in relation to dates is the "inferred" qualifier from modes. That qualifier means very little to machines and to how someone might use the data... so that information is instead mapped to a note. There are two options for doing notes (as one will see in a later section) which means one should use whatever note format they end up settling on.
The last note is that in the Complex Case there are five types of provision activity. Those are: bf:ProvisionActivity (generic case) and bf:Distribution, bf:Manufacture, bf:Publication, bf:Production (more specific cases)
- OriginInfo Collaboration Document
- Individual mappings pages: (Part 1 - Dates) and (Part 2 - Other)
Language
Physical Description
We didn't want to mint "extent objects" which is why we are using "opaque:extent". Please note that the hydra community is using "dcterms:extent" incorrectly as it has a range of a uri defined (ie. will not accept string literals). Bibframe's extent used to work in version 1.0 but they changed it in version 2.0 to require a uri.
There are also two options for how to map the "note" from this element. These two options are expanded upon in the "Notes" section farther below and you should use the syntax you picked for the other notes in your system.
Abstract
We picked "dcterms:abstract" over "dcterms:description". Why? "dcterms:abstract" is a more direct mapping to the concept in MODS. "dcterms:description" could contain table of contents or other non-abstract fields of text that we have proper mappings for.
Table of Contents
Target Audience
Note
There are two choices for mapping notes. The simplest is to use "skos:note" with a text string where the text string has any "type" identifier prepended to the note text. The other way is to use bibframe Notes which requires the creation of note objects but more clearly separates out the note type.
Subject
Description coming soon.
Classification
Identifier
The Option 2 (WON THE VOTE) is the mapping to use here. The other options were ones we were seriously considering and are left for posterity sake. We did a poll of the broader community to arrive at the option we recommend and officially support.
Location
This has three tabs for the three types of data one might find in this element. shelfMark and Holding had much controversy that surrounded them and we ended up at these versions after doing a larger community vote. (The options for said vote can be found at: here). The URLs section primarily uses EDM properties for how to access the object and what its primary url is.
Access Condition (Rights)
Essentially follow a subset of the Hydra Rights Group recommendations. Those can be found at: Rights Metadata Recommendation
Record Information
Comes mostly from a combination of DPLA methodology and bibframe. "edm:dataProvider" is optional and who provided the original record (ie. is mostly used by those aggregating data). "edm:provider" is the one that is currently making the data available from this linked data endpoint.
Series, Physical Collections, and Digital Collections
Descriptive information coming soon.