Proposal: Validation for BIBFRAME CBD RDF Subgraph

[kallimathios]

Use case overview

• Priority: High
• Status: Draft

Describe use case

A clear and concise description of a use case supported by BIG outputs (DCTAP and/or SHACL).

• As a cataloger, I want to be able to reuse an existing BIBFRAME description in an application, via a single description import or export process, or via a bulk ingest or export process. Reuse in this use case is defined as importing and exporting a description from within any library linked data editor following the conventions in Proposal: use of bf:derivedFrom for ingesting BF descriptions with an existing URI #3. This issue aims to formalize and extend the use of Concise Bounded Descriptions (CBD) within the library linked open data community as a standardized practice for data exchange. Attached to this issue is documentation from the Library of Congress on existing Marva input payload expectations. Additionally, added details about CBDs are linked below. By using the CBD to exchange BIBFRAME descriptions, we are able to isolate sections of an entire graph as a subgraph. As Nate Trail writes:

The Marva BIBFRAME RDF editor expects a bibliographic description in a specific data structure. The description is dubbed “CBD” or “Concise Bounded Description” at ID.loc.gov. It is available from any BIBFRAME Instance on that site, for example : https://id.loc.gov/resources/instances/24091701.cbd.rdf .   The idea behind a CBD is that is a small graph of information that provides enough information such that the resource is self-explaining.  It is used for cataloging in Marva, but the exact same graph is fed to the BIBFRAME-to-MARC converter and has everything needed to output a pretty rich MARC record.

• Not only does the small graph help facilitate conversion between BIBFRAME and MARC, it enables us to neatly package RDF data and know where a description or set of descriptions begin and end. Further, the W3C documentation states (emphasis my own):

As the semantic web [2] emerges and the behavior of automated software agents becomes increasingly directed by formally defined knowledge about resources [3] gathered from disparate sources [4], the need for optimal and consistent interchange of knowledge about specific resources between agents becomes critical to achieving an efficient, globally scalable, and ubiquitous semantic web.
This document defines a concise bounded description of a resource in terms of an RDF graph [5], as a general and broadly optimal unit of specific knowledge about that resource to be utilized by, and/or interchanged between, semantic web agents.
Given a particular node in a particular RDF graph, a concise bounded description is a subgraph consisting of those statements which together constitute a focused body of knowledge about the resource denoted by that particular node...it is presented herein as a reasonably general and broadly optimal form of description for many applications, and unless otherwise warranted, constitutes a reasonable default response to the request "tell me about this resource".

• In addition to the description passing DCTAP/SHACL validation upon ingest (Validating in BF Editors When Attempting to Save Descriptions #1 and Warnings in BF Editors When Attempting to Save Descriptions #5), the Concise Bounded Description subgraph, as expressed in any serialization (new issue to follow), must also pass validation for ingest/export.

Preconditions (Optional)

List conditions that must be true before this use case can begin.

• The user is loading an Instance description and its accompanying resources using a CBD RDF URL, or .cbd.rdf file, following the practice of Library of Congress, and influenced by but not limited to the MARC2BIBFRAME and BIBFRAME-to-MARC conversion processes.
• The application is prepared to ingest and parse a CBD RDF URL, or a CBD file.
• The application is prepared to package and export a CBD RDF URL or a CBD file.
• Documentation and consensus exist for what entities, how many entities, and the nature of those entities exist within the subgraph.
• The description is being minted a new URI because changes are being made downstream from the originating source, the resource is not a look up or cannot be used as a look up, and the user is unable to contribute edits within the originating data pool.

Describe expected behavior in related systems

A clear and concise description of related system behavior

• The application expects CBD RDF, and rejects the ingest if it doesn't meet requirements.
• The system expects the CBD RDF URL to follow a pattern such as "https://id.loc.gov/resources/instances/21273441.cbd.rdf".
• Warning and error reporting would be helpful in notifying the user to resolve issues when trying to reuse data.
• To reduce duplication, duplication detection in the form of resource suggestions shown to the user before POST.

Post conditions (Optional)

Success post conditions

What should be true after successful completion?

• A user can open Work and Instance resources packaged in a CBD RDF URL or CBD RDF file in a variety of linked data editors.

Failure post conditions

What should be true if the use case fails?

• Data structure validation exists for BIBFRAME data based on the tooling and back-end, and there is no data structure standard or documentation for exchanging BIBFRAME descriptions across data pools when necessary.

Main success scenario

What steps or conditions would this use case be considered to be a success?

• Data consumers and individual users can open a BIBFRAME subgraph package in the form of CBD RDF expressed in a variety of serializations in a variety of applications.

Additional context

Add any other context or screenshots about the features you are requesting.

• The idea behind this use case is to strengthen and formalize practices that are emerging among BIG members and document them for wider community implementation.
• Prepare Your BIBFRAME Data
• Ex Libris BIBFRAME Support
• Marva Getting Started
• Blue Core platform suite

[kallimathios]

Marva input/export data structure by Nate Trail and Kevin Ford, Library of Congress, attached below

MARVA input description payload.docx

Added background on Concise Bounded Descriptions via W3C

[kallimathios]

Concern raised about W3C spec in relation to LC practices for .cbd, explained in detail here: https://gist.github.com/zimeon/0628bdc1387e0e5be45af0ce976e52a0

Questions:

• How do we describe the .cbd practice if it doesn't strictly follow the W3C spec?
• Is it possible to use the W3C spec instead of the LC process?
• What happens when we are working with BIBFRAME and not converting back to MARC? Is converting back to MARC a requirement of all BIBFRAME? Is converting back to MARC considered a "best practice"? What about libraries that migrated from another format (e.g. UNIMARC)?