Let me explain our thinking, behind the bf:relationship/bf:Relationship construct.


Nothing in bibframe precludes, for example, this pattern:


<WorkA>      bf:continuedBy     <WorkB> 


<WorkA>      rdaw:continuedByWork     <WorkB>


These are legitimate and unless you want to make statements about a relationship, this approach would be preferred over using the relationship construct.


However, you might want to supply the date that the continuation took place:


  bf:relationship [ 

                     bf:relatedTo  <WorkB> ;

                     bf:relation   bf:continuedBy ;

                     bf:date      “10232017” ]


You would not be able to indicate this information using the simple  triple:

                 <WorkA>   bf:continuedBy  <WorkB>     


In fact, the bibframe contribution pattern takes a similar approach, and one of the primary reasons it does so is so that you can make statements about a contribution.  (E.g. not just “this resource was illustrated by this person”  but “this resource was illustrated by this person on July 5, 2013 in Chicago”.)  The LD4 experts stressed how important this feature is during the various discussion between LC and LD4.  And the LD4 activity pattern also uses a similar approach, for the same reason.


But there are other use cases  supported by the relationship pattern.


Graceful degradation.  Let’s assume for discussion sake that everyone knows the RDA relationships. But suppose you want to express a relation outside of bibframe and outside of RDA, in some external namespace.  Let’s call it ex:xyz


You could say


(1)         <WorkA>   ex:xyz   <WorkB>


Or you could say:


(2)    <WorkA>   bf:relationship [

                                   bf:relatedTo  <WorkB> ;

                                   bf:relation   ex:xyz ]


Let’s assume the client receiving this rdf does not recognize this namespace (or at least, doesn’t recognize the relation xyz).   Using (1), the client will not make any sense whatever of this.  Using (2) it will at least know that WorkB is a resource related to WorkA, even though it won’t know the exact relation.


Next, suppose you have a relation to express, but there is no URI to express it (or if there is, you don’t know it).   Using form (2), you can say:


   <WorkA>   bf:relationship [ 

                                   bf:relatedTo  <WorkB> ;

                                   bf:relation   [rdfs:label “name of relation” ]


Finally, suppose you do have an explicit relationship, but no URI for the target resource.  An example would be the Instance to Instance relationship bf:otherPhysicalFormat. Let’s say you are converting a marc record that tells you that the resource has an “other physical format”  and it tells you what that format is, but does not provide a link to the resource.  (This is not uncommon in a MARC record. )


   <InstanceA>   bf:relationship [ 

                   bf:relation   bf:otherPhysicalFormat ;

                   bf:note [rdfs:label “Issued also as 16 mm filmstrip in cartridge and as slide set and as videorecording”]]


In summary, we think that there are situations where form (1) is best, however we also feel that form (2) is useful for other situations (described above) and that for those situations form (2) is not an example of over engineering.





> -----Original Message-----

> From: Bibliographic Framework Transition Initiative Forum

> [mailto:[log in to unmask]] On Behalf Of Steven Michael Folsom

> Sent: Friday, October 20, 2017 3:31 PM

> To: [log in to unmask]

> Subject: Re: [BIBFRAME] Resource relationships


> In the LD4L analysis and adoption of BF2 we chose simply to extend BF2 using

> select RDAU properties. [1]


> 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?


> Respectfully,

> Steven


> [1] For more information on the LD4L analysis of BIBFRAME, see:

> -

> -


> --

> Steven Folsom

> Metadata Specialist

> Cornell University Library


> @sf433





> 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:


>     Joe,

>     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.


>     Sally


>     -----Original Message-----

>     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,

>                             bf:ChoreographicAdaptation ;

>             rdfs:label "Choreographic adaptation" ] ;

>             bf:relatedTo <bf:Work B> ] .



>     -----Original Message-----

>     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:


>     choreographicAdaptationOfExpression


>     while BIBFRAME has:


>     derivativeOf


>     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.


>     kc


>     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.

>     >

>     >

>     >

>     >

>     >

>     >

>     >


>     --

>     Karen Coyle

>     [log in to unmask]

>     m: +1-510-435-8234

>     skype: kcoylenet/+1-510-984-3600