I wonder how others feel about the difference in detail levels between RDA and BIBFRAME. Essentially, the way it is defined now, translation between RDA and BIBFRAME is quite lossy. Yet, people talk about doing RDA cataloging in BIBFRAME. I don't see how that is possible unless the more detailed RDA properties are included -- either in BIBFRAME or with their own namespace.


On 9/15/15 5:08 PM, Joseph Kiegel wrote:
[log in to unmask]" type="cite">

I made a number of (relatively small) points about changes that are needed in BIBFRAME, and that was my main conclusion.

Yes, BIBFRAME and RDA deal with relationships at different levels.  In a sense, the mapping itself is the answer.  It allows collapsing the detail of RDA to the broader categories of BIBFRAME.  As a minimum, no more need be done.

But, as you suggest, more could be done.  There are high levels in RDA, which are shown as not mapped in the tables.  It seems doubtful to me that RDA will be restructured to accommodate BIBFRAME.  If BIBFRAME wants subproperty definitions, they will have to be created on the BIBFRAME side.




From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Monday, September 14, 2015 10:56 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Relationships between resources


Joseph, this is great work, but it isn't clear to me what your conclusion is. BIBFRAME has taken a high level approach to these relationships, but that doesn't match what is in RDA. However, a relationship could be made between the high-level BIBFRAME terms and the more detailed RDA terms, such that, for example:

  rdfs:subPropertyOf bf:derivativeOf .

The other option is for RDA to develop general categories (I don't know if it has them already) with the details as subordinate, and the RDA general can be defined as = the BIBFRAME category. Then, by inference, the RDA details would also be subordinate to the BIBFRAME general category, which is then = the RDA general category.

rdau:derivativeOf = bf:derivativeOf
rdaw:televisionScreenplayBasedOnWork rdfs:subpropertyOf rdau:derivativeOf
rdaw:televisionScreenplayBasedOnWork rdfs:subpropertyOf bf:derivativeOf

Given that BIBFRAME could have a broader audience than library cataloging, it makes sense not to add the detailed categories to BIBFRAME, or at least, if they must be added, to make them optional, with the general category being a "good enough" solution for many users.


On 9/8/15 5:38 PM, Joseph Kiegel wrote:

I have produced a mapping of RDA resource relationships (Appendix J) to BIBFRAME, which is attached and also available at http://www.lib.washington.edu/msd/pubcat/ld.  There are four files, one for each WEMI class.

Note that the highest level relationship in each category is not mapped since it is not likely to be used in practice.


Here are comments on BIBFRAME based on a review of the mapping and corresponding BIBFRAME properties.


BIBFRAME does not handle well the relationship between resources that RDA terms “complemented by”:  a work paired with another work without either work considered predominant.  Examples are a musical work and a libretto, a screenplay and a motion picture, or a motion picture and music.  The property bf:accompaniedBy works well for appendices, addenda, errata, etc., but not for works complemented by other works.  An additional BIBFRAME property is needed.


There is a question how to handle prequels.  In terms of production date, a prequel succeeds the original (bf:succeededBy) but in terms of the date of the story line, it precedes the original (bf:precededBy).  What is best practice?


Verb tense should be consistent across property names so bf:absorbed should be bf:absorbs.


The subproperty assignments of bf:translation and bf:translationOf appear to be reversed.  bf:translation should be a subproperty of bf:hasDerivative, and bf:translationOf should be a subproperty of bf:derivativeOf.


The property bf:otherEdition was not used in the mapping and it is not clear what function it serves.



Thanks to Theo Gerontakos for reviewing the mapping.


Joe Kiegel

Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600