My mapping is the test of whether the same concepts can be expressed in both schemas. BIBFRAME currently has no other means beyond these properties to express resource relationships, so BIBFRAME is not as expressive as RDA.
As far as catalogers are concerned, they will catalog in RDA in an interface like RIMMF or the LC Editor. The rendering of their work into linked data happens behind the scenes, so there is no question of "easier to work with". As long as RDA is the cataloging standard, the intellectual distinctions of RDA are what catalogers work with.
I would like to see the full range of resource relationships incorporated directly into BIBFRAME (rather than, say, being an extension). Since BIBFRAME avoids a proliferation of properties, this will involve creating more classes. For the purpose of the examples, new class names are drawn directly from RDA terminology. Note that unconstrained RDA is needed because BIBFRAME does not make a distinction between Work and Expression.
A simple way to express the relationship of choreographic adaptation is:
<bf:WorkA> bf:derivativeOf <bf:WorkB> .
<bf:WorkA> a bf:ChoreographicAdaptation.
A more complex way is possible, along the lines of what the LC converter does, using classes and the LC extensions bflc:relationship and bflc:relation. (In the example below, I pull these properties into BIBFRAME as well, as I have suggested elsewhere.). bf:relationship is used to create a node containing 1) bf:relatedTo with a URI for the related resource and 2) bf:relation with a class for the appropriate relationship and optionally a label for the name of the relationship. New classes are defined as subclasses of bf:Relation.
For example, the relationship can be rendered as:
<bf:Work A> bf:relationship [ a bf:Relationship ;
bf:relation [ a bf:Relation,
rdfs:label "Choreographic adaptation" ] ;
bf:relatedTo <bf:Work B> ] .
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Wednesday, October 18, 2017 9:18 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Resource relationships
RDA and BIBFRAME have definitely taken different approaches to this problem. It would be interesting to know whether the final functionality of the two approaches is similar. For example, RDA has:
while BIBFRAME has:
Statements would look like:
<A> <rdae:choreographicAdaptationOfExpression> <B> and <X> <bf:derivativeOf> <Y>
These could actually have the same semantics if X has the quality of being a choreographic adaptation (or a choreography, I suppose) and Y is an expression. That statement's semantics would then be: "this choreographical thing(X) is a derivative of the following expression(Y)."
It seems to me that RDA has some redundancy by adding "OfWork"
"OfExpression" to each of the properties, and I am guessing that is because the entities WEMI are defined as disjoint and therefore you cannot have a relationship that has an open range ("derivativeOf" with range being any group 1 entity). BIBFRAME opts for fewer distinct properties, and probably less control built into the vocabulary, but the same semantics may be inferred from the triple rather than being encoded in the property.
These are philosophical differences, in a sense, but checking to see if the same concepts can be expressed in both languages would be an interesting test. The other test would be to see if catalogers working in the two environments find one easier to work with. It could be that user interfaces could alleviate some of the difference between them.
On 10/17/17 10:31 AM, Joseph Kiegel wrote:
> One area where we can compare the relative expressiveness of RDA and
> BIBFRAME is the properties for describing relationships between
> resources, that is, between works, expressions, manifestations and
> items in terms of RDA and between works, instances and items in
> BIBFRAME. In RDA, these relationships are given in Appendix J
> (relationship designators). In BIBFRAME, they are listed in the
> category view in the two sections labelled Cataloging Resource
> Relationships - Specific and Cataloging Resource Relationships - Detailed.
> I have created mappings of resource relationships from constrained RDA
> to BIBFRAME for each of the four resource types in RDA. They can be
> found on the University of Washington linked data page:
> The first observation is that RDA provides a much more finely grained
> description of resource relationships. For example, for Works there
> are over 150 properties in RDA and 32 in BIBFRAME. For some types of
> relationships, e.g. referential relationships and whole-part
> relationships, the RDA-BIBFRAME mapping is one-to-one. For sequential
> relationships, the correspondence is close, with 22 relationships in
> RDA and 14 in BIBFRAME. (It was closer in BF1, but BF2 lost most of
> the "in part" relationships.)
> For derivative relationships and accompanying relationships, however,
> there is a great discrepancy between the expressiveness of RDA and
> BIBFRAME. There are over 70 derivative work relationships in RDA but
> only two in BIBFRAME. For accompanying relationships, RDA has over 50
> and BIBFRAME has 8.
> The result is that much detail is lost when RDA concepts are expressed
> in BIBFRAME. RDA differentiates "abridgement of" from "graphic
> novelization of" from "verse adaptation of" from "digest of" from
> "parody of". In BIBFRAME, we have a single choice for expressing all
> of these relationships: derivativeOf. RDA allows distinctions
> between addenda, appendices, concordances and errata but in BIBFRAME
> they must be rendered identically as accompaniedBy.
> My second observation is that BIBFRAME's treatment of resource
> relationships does not support the user experience we hope to provide
> under RDA. The elaboration of resource relationships is one of the
> significant advances that RDA has made over AACR2. When catalogers
> invest intellectual effort to determine resource relationships, this
> information should be displayed to users in our library catalogs.
> BIBFRAME-encoded cataloging does not fully allow us to do so.
[log in to unmask] http://kcoyle.net