We are beginning to align MARC to RDA/LRM. We began by aligning the MARC 490 field to RDA/LRM. As expected, complications arose.
Read more Our First MARC-to-RDA/LRM alignment: setting a precedent
We are beginning to align MARC to RDA/LRM. We began by aligning the MARC 490 field to RDA/LRM. As expected, complications arose.
Read more Our First MARC-to-RDA/LRM alignment: setting a precedent
This is the first of two posts on the panel discussion “What role can RDA/RDF play in the transition to linked library data?” which took place during the 5th annual meeting of the BIBFRAME Workshop in Europe [1], and featured comments from five distinguished panelists [2]. This post is a transcription of the response from Gordon Dunsire (former chair of the RDA Steering Committee and current member of the RSC Technical Working Group [3]) to a question posed at the BIBFRAME Workshop, followed by an annotated version (annotated by Theo Gerontakos) engaging some of the areas discussed.
RDA/LRM/RDF contains elements that are essentially reified property chains in RDA, known as shortcuts, while BIBFRAME features many property chains that are not reified as specific elements – what many people call “nested” data. What are the pros and cons of property chains and reification, and do they cause interoperability problems?
Read more Gordon Dunsire on property chains and shortcuts in RDA/LRM
The Problem:
Using RDA (Resource Description and Access, 2017) guidelines we can represent with accuracy a work that is the subject of another work; for example, a book analyzing Shakespeare’s Hamlet could be represented in RDA as follows:
fake:studyOfHamlet # imaginary book about Hamlet
rdaw:10140 # rda property “is analysis of work”
fake:Hamlet . # local Work record for Hamlet.
Or, if we have a literal to represent Hamlet:
fake:studyOfHamlet
rdaw:10140
“Hamlet” .
How can these be expressed using BIBFRAME?
Proposed solution:
fake:studyOfHamlet a bf:Work ;
bf:subject fake:Hamlet ;
bf:relatedTo fake:Hamlet .
Or, when Hamlet is described using a literal:
fake:studyOfHamlet a bf:Work ;
bf:subject [ a madsrdf:Title ;
rdfs:label “Hamlet” ] ;
bf:relatedTo [ a bf:Work ;
rdfs:label “Hamlet” ] .
Analysis:
To express the relationship in the example above (and in similar relationships using the Appendix M relationship designators), we judged that BIBFRAME requires us to choose properties either from a set of “relationship” properties in a bf:relatedTo hierarchy, or another “subject” property outside that hierarchy, bf:subject. As a result the decisive question was, are the relationship designators in Appendix M (“is analysis of work” in the example above) “subjects” or “relationships”? If the relationship designator is a “relationship,” we would use the property bf:relatedTo or one of its subproperties; if the relationship designator is a “subject,” we would use BIBFRAME’s bf:subject property then, when the value is a literal, use MADS/RDF classes and properties to complete the description of that “subject.”
The solution proposed above considers the relation both a BIBFRAME relationship and a BIBFRAME subject.This decision originated from the RDA Registry where RDA “elements” are given a semantic web identity. RDA-RDF creators proliferated properties and situated each property in a rich hierarchy. RDA Appendix M relationship designators for subject relationships are placed in a hierarchy beneath the following “relationship” branch: “has related entity of RDA entity” → “has related RDA entity of RDA entity” → “has related RDA entity of work.” The hierarchy at this point breaks into multiple branches, including two “subject” branches, “has subject RDA entity” and “has subject.” Both those subject branches lead to the Appendix M relationship designators, including the one used in the example above, “is analysis of work.” This demonstrates that the RDA-RDF creators consider these relationship properties both “relationships” and “subjects,” as the “top” of the hierarchy describes relationships, while “the bottom” of the hierarchy describes subjects.
The decision also emerged from a general principle when mapping from one ontology to another: if the target ontology has multiple solutions for a single statement created using the source ontology, use the multiple solutions — all if possible — not just one. In this case, a single statement from RDA carries multiple meanings with a single predicate; if BIBFRAME has multiple predicates that approximate the full complexity of the original statement, use multiple predicates, not just one. Specifically we will not say the study of Hamlet is only related to Hamlet, but Hamlet is also the subject of the study of Hamlet.
Additional thoughts on the proposed solution in the example
Follow this link to: SHACL Cheat Sheet
version 0.2 2020-05-30
Description
Cheat sheet to assist writing of code in the Shapes Constraint Language (https://www.w3.org/TR/shacl/). This cheat sheet invents two SHACL core groupings:
(1) “Core Core”
(2) “Intermediate Core”
The hope is that “Core Core” provides the bulk of properties and classes needed to write most shapes.
We are writing a metadata application profile. We are following Library of Congress’ profile syntax for creating BIBFRAME profiles (http://www.loc.gov/bibframe/docs/bibframe-profiles.html). Almost all our properties have been taken from Resource Description and Access (RDA; see https://www.rdatoolkit.org/about and the RDA Registry at https://www.rdaregistry.info). These are json profiles, intended to produce data input forms that output linked data. The data input forms will display in a linked data editor currently in development, Sinopia (https://sinopia.io/), allowing input specialists (catalogers, for example) to enter values for RDA properties. Once input, the data can be output as RDF data; that output is a presupposition of our work. In fact, we often create the profile in accordance with conceptual output we model for a given property. This entry illustrates that profile-creation practice: conceiving what data input form structures are required by modeling the form’s expected output; more specifically, this entry focuses on how the form outputs properties and values for subject headings (categories describing the content of a resource). The values are complex for library data because libraries traditionally use precoordinated headings (https://www2.archivists.org/glossary/terms/p/precoordinate-indexing) as values, which our model must accommodate. How? This illustration is not an exhaustive treatment of precoordinated headings but, rather, a clue toward a possible solution.
Read more Modeling LCSH Subject Headings as RDA Linked Data in Sinopia