This is only one of the areas where the translation from RDA to BIBFRAME is lossy.

In my view, the community has not reached a consensus on what it means for BIBFRAME to be a carrier, and this merits discussion.  There are two views (at least):

Catalog in RDA, code in BIBFRAME:  RDA rules are used to determine entities, which are then encoded according to the BIBFRAME model.  This is the final product and there is no attempt to recover the original RDA entities.  No round-trip back to RDA is needed. 

Catalog in RDA, retain RDA:  RDA rules are used to determine entities and there is a need to retain/recover them.  In this scenario, coding in the current BIBFRAME is problematic because of the losses.  A round-trip is needed, and at the present time BIBFRAME cannot provide it.

A use case for the second definition of carrier is contribution to OCLC.  At least some libraries that catalog in RDA want the full specification of RDA elements in the OCLC master record.  RDA records contributed to OCLC in BIBFRAME do not necessarily allow all of the original RDA elements to be recovered.

 

Joe

 

 

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.

kc

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.

 

Joe

 

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:

rdaw:televisionScreenplayBasedOnWork
  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
therefore:
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.

kc

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