 |
 |
Dear Jörg,
I don't have a lot to add other than to say that your email very neatly captures how we anticipate responsibility of distinguishing between RDA Works and RDA Expressions will be a per implementation decision. Not all systems will want to feature these things as RDA Works and RDA Expressions (and FRBR designations are problematic for a lot of material in the cultural heritage sector that might use BIBFRAME) so our objective is to ensure that BIBFRAME can accommodate RDA description as well as a means to permit an implementer to exploit the RDA/FRBR entities while not unduly coupling BIBFRAME to RDA. We think it entirely possible to take BIBFRAME data and extract RDA Works and RDA Expressions from it. We hope to have some material that specifically looks at this issue.
I'd rather not call a BIBFRAME Work an "abstraction" in the sense - I think - Dr. Tillett meant it (I view a BIBFRAME Work as a type of Work within its own definition), but the principle of collapsing in this case is the same.
Warmly,
Kevin
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of [log in to unmask]
Sent: Wednesday, May 22, 2013 9:57 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Holds and ILL with Bibframe
Barbara Tillett noted back in 2003 that in FRBR, the "work" and "expression" entities may collapse into an "abstraction" and I think Bibframe is doing this.
Quote: "Using this model, one could even collapse both 'work' and 'expression' into something called an 'abstraction' when that was found to be useful for a particular application. It should be noted however, that FRBR kept them separate." http://www.loc.gov/catdir/cpso/frbreng.pdf (p. 9)
My conclusion is, it will be up to the Bibframe implementor to add more concrete entities that can distinguish a bf:Work for better contextualization. Maybe by using FRBR entities, maybe by other. It's for sure a set of bf:Work must be post-processed for many aspects, not only for search by author/title clustering, but also by building groups for text, sound, image, language etc. like we know from FRBR.
Another consequence is that Bibframe packagers will have to be a little cautious because there will be many properties for creating and linking bf:Work classes, since they will subsume the FRBR expression level. Some may package all properties in one bf:Work, while others may create multiple bf:Work's and link them.
Jörg
On Tue, May 21, 2013 at 11:16 PM, Trail, Nate <[log in to unmask]> wrote:
I don't see any complication. The thing being checked out is never the Instance anyway; it's the copy or holding, mixed in with some algorithms about who can check out and how. The system will have to do some work getting from your title to the actual copy; it'll have to do similar work in the new environment.
We have no bf:Expression in the sense of a different data structure; but we will have bf:Work with properties that make it useable as a FRBR:Expression, such as the language. It will be a related work with a property such as "hasTranslation" linking the two. A request for Mark Twain's Huckleberry Finn in Finnish would probably miss the Huck Finn in English because the language would only be on the bf:Work "Huck Finn. Finnish." [made up]
I'm working on a couple of examples of translations we can show, from our catalog.
Nate
-------------------------------------------
Nate Trail
-------------------------------------------
LS/TECH/NDMSO
Library of Congress
202-707-2193
[log in to unmask]
-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of J. McRee Elrod
Sent: Tuesday, May 21, 2013 3:56 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Holds and ILL with Bibframe
Laura said:
>... a user can still request a resource at the Expression level ...
How may one request at the Expression level, since Bibframe has no Expression level records*? Some Work level records are actually
Expressions I understand, e.g., a translation? But wouldn't ILL or
hold requests with Bibframe have to be made using the Work or Instance record?
I agree that Instance records based on binding is not only a major departure from long standing practice, but a complication for holds and ILL requests.
*I'm continuing t use "record" util there is an agreed upon alternative.
__ __ J. McRee (Mac) Elrod ([log in to unmask])
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__________________________________________________________