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
- Employing every possible solution using the target ontology may produce unnecessary redundancies, especially when using deeply hierarchical ontologies. Do we care?
- BIBFRAME has no property more specific than bf:relatedTo to express the relationship in the example above.
- When describing the resource using a literal:
- a madrdf:Title “Describes a resource whose label represents a title” and applies in this case.
- rdfs:label is actually an implementation of MADS/RDF, where madsrdf:authoritativeLabel would have been the correct property if the label “Hamlet” were controlled. It is not. madsrdf:authoritativeLabel is a subproperty of rdfs:label, which applies in this case and was used in the solution.