In the LD4L analysis and adoption of BF2 we chose simply to extend BF2 using select RDAU properties. 
RDAU isn’t perfect, but sticking to the general properties would get us pretty far. Our biggest reason for only using *select* RDAU properties is proliferation caused by the anti-pattern of minting new properties to account for the type of things being related; we don’t need “is opera adaptation of” if we have the more general “is adaptation of” and an Opera class/genre term.
Similarly, using relationships to create new classes (as described in Joe’s bf:ChoreographicAdaption example below) causes unnecessary Class proliferation; each class would then require parallel classes for all the different types of relationships between resources.
The other option being floated below (using bflc:Relationship) seems like over engineering for a problem that could be solved with just reusing the parts of RDAU that are well designed.
Is this under consideration?
 For more information on the LD4L analysis of BIBFRAME, see:
Cornell University Library
On 10/20/17, 12:14 PM, "Bibliographic Framework Transition Initiative Forum on behalf of McCallum, Sally" <[log in to unmask] on behalf of [log in to unmask]> wrote:
I can see why you were confused about the treatment of relationships in BIBFRAME as we had to use bflc: namespace ourselves to enable the expression of the hundreds of relationships that RDA lists and to express relationships from other sources. As we progressed through our MARC to BF conversion specs and programs we added an extended capability, the property bflc:relationship along with corresponding class bflc:Relationship, modeled on bf:contribution/bf:Contribution . We added this to bflc because the bf: vocabulary was already published and we were not comfortable just adding what we "felt like". I think you found it buried in the specs but here is it again:
RDF for relationships
<resource> bf:relatedTo* URI. (of resource being related to)
*bf:relatedTo may instead be one of the other bibframe relation properties.
Or to express a specific relation label and/or have the URI for another special relation:
<resource> bflc:relationship [a bflc:Relationship;
bf:relatedTo URI; (of resource being related to);
bflc:relation* URI; (for relation )
bflc:relation* [rdfs:label "name of relation"] ] .
* one or both of these
Thanks for highlighting this. We will check our conversion specs and programs to see that they are working as planned. We also need to add this to the BIBFRAME notes on the web site so it is not so hard to find.
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Joseph Kiegel
Sent: Thursday, October 19, 2017 12:09 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Resource relationships
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