Hi, Karen:
Thank you very much for bringing up these great points. I do share your
concerns. In addition, allowing linking from a manifestation record
back to multiple expressions might be hard for data quality control,
particularly for data integrity control during CUD processing (e.g.
Create, Update, and Delete operations) if no control over the breakdown
of identifiers for a record, which glue the composition of:
1. entities such as Work, Expression, Manifestation and Item, and
2. relationships accompanying RDA elements, sub-elements, and
vocabularies, etc. in a RDA record.
However, it is easier for end users to get to the core function of a
catalog, disambiguate similar hits, and explore other parts of linked
records representing the concepts of the intellectual work if a
manifestation record is used as the base record linked to RDA component
records for Work, Expressions, and other related entities, such as
persons, events, places, organizations, etc.
I understand that you are worried about going back to the one-size fit
all bib record. However, if you take a look at this record, it might
change your perspective. I found an example coded in MARC 21 format in
Swissbib Catalog via this URL:
http://www.swissbib.ch/TouchPoint/perma.do?q=0%3D%22115036369%22+IN+%5B3%5D&v=nose&l=de
<http://www.swissbib.ch/TouchPoint/perma.do?q=0%3D%22115036369%22+IN+%5B3%5D&v=nose&l=de>
According to RDA Core Schema, a root RDA core record is broken down into
the following RDA elements and their children:
* rdaWork
* rdaExpression
* rdaManifestation
* rdaItem
* rdaPerson
* rdaFamily
* rdaCorporateBody
* rdaConcept
* rdaObject
* rdaEvent
* rdaPlace
* rdaName
* rdaRelationships
Each element and their child or children is an aggregation agent.
Maintaining de-referenceable URIs for parts of a RDA record is as
important as maintaining full-text linking to aggregators and
publishers, ILL linking to lending libraries, etc. With a little touch
of semantics, e.g. supporting HTML5, RDFa, etc., our catalogs can be as
powerful as any other Web 2.0 services provided by online information
services.
As far as I understand, the one-size-fit all bib record is decoupled
into reusable components for mash-ups, gadgets, etc. as far as Work,
Expression, and Manifestation component records are concerned. What I
am trying to say is that let us lay out the data structure to liberate
our one-size fit all bib records, many innovative approaches or
applications or services will be flourished upon the components of a RDA
record.
Sincerely yours,
Amanda
***************************************
Amanda Xu
Assistant Professor
Information Technology Librarian for Collection Management
Room 0364F Bldg LIB
James E. Walker Library
P.O. Box 13
Middle Tennessee State University
Murfreesboro, TN 37132
a...@mtsu.edu (email)
615-904-8510 (office)
718-316-8787 (cell)
On 10/18/2010 12:58 PM, Karen Coyle wrote:
Quoting Jonathan Rochkind <rochk...@jhu.edu>:
My understanding of the FRBR model is that it insists that _all_
manifestations belong to an expression which belongs to a work. This is
what leads to aggregates neccesarily being works -- you've got a
manifestation in front of you which is clearly an aggregate. So the
manifestation must be part of a work.
If you look at the simple Group1 diagram:
http://archive.ifla.org/VII/s13/frbr/fig3-1.jpg
you see that a manifestation can manifest more than one expression. So
there are two (at least) ways to go:
1) consider the aggregate a manifestation and an expression and a
work; but that doesn't explain why manifestation and expression are
many-to-many
2) consider an aggregate a manifestation of more than one expression,
and each expression expresses a single work (note the arrows between
expression and work -- each expression can express only one work).
It seems to me that the aggregate form (#1 here) completely negates
the separation between work, expression and manifestation -- we get
back to traditional cataloging where we've only got one "thing" --
which is defined by the manifestation. It also means that once again
just about every publication becomes a separate "thing" and we are
back to showing our users long lists of bibliographic records for the
same text. If that's the goal, why did we bother with FRBR in the
first place? What does it gain us?
kc
Possibly it would be better/more flexible to allow manifestations that
do not in fact belong to any expression or work; but I'm not sure, it
gets confusing to think about. I think maybe a manifestation
neccesarily has to belong to an expression and a work for the model to
make any sense -- but that doesn't mean the work it belongs to actually
needs to be _modelled_, it can just be an as-of-yet-un-modelled work,
that will be modelled only when/if it is useful to do so.
Curious how you are handling this in terms of the model exactly though,
I'm confused.
Riley, Jenn wrote:
Hi Stephen and all,
We’ve made an intentional decision for the V/FRBR project to not
use the concept of an aggregate work. The many-to-many nature of
Expression to Manifestation for our need adequately models the fact
that two symphonies were released on the same disc (for example).
For our purposes, there’s no practical (or even semantic in my
opinion) benefit to calling those two symphonies by two different
composers an aggregate Work.
Like others have commented, I also have reservations about the
aggregate notion in FRBR as a whole. That has fed into the
practical decisions our project has made.
Jenn
On 10/17/10 9:53 PM, "Stephen Hearn" <s-h...@umn.edu> wrote:
For those who argue that FRBR defines aggregates as works, I wonder
if this is too atomic an approach. If there is an aggregate FRBR
work whose contents are expressed in an aggregate FRBR expression
and embodied in an aggregate FRBR manifestation, couldn't one
reasonably argue that the manifestation is really only the
embodiment of that aggregate work, and is rather a container for
the other, individuated FRBR works that Variations is working with?
Does Variations enable the description of the single aggregate
FRBR work that a given manifestation arguably represents?
For example, a search on "octubafest" identifies two "work results"
with that word in the title, but they are individual pieces
(Octubafest march and Octubafest polka). Wouldn't FRBR consider the
aggregation manifested as "Octubafest 1981" and the others like it
to be works as well?
That said, I've long considered the notion of aggregates as FRBR
works to be problematic, so I see a lot to admire in the Variations
approach.
Stephen
On Sun, Oct 17, 2010 at 3:04 PM, Riley, Jenn <jenlr...@indiana.edu>
wrote:
Dear Bernard and List,
My apologies for not responding sooner; I'm impossibly behind in
reading listserv email. Comments below.
Riley, Jenn wrote:
The Variations/FRBR [1] project at Indiana University has released
bulk downloads of metadata for the sound recordings presented in our
Scherzo [2] music discovery system in a FRBRized XML format.
Before digging into this any further, one question: How is the
linking between works and expressions effected? On first inspection,
I find nothing in the expression data that would indicate the work.
The XML format that defines this data (our project "efrbr"
definition; more information at
<http://www.dlib.indiana.edu/projects/vfrbr/schemas/1.0/index.shtml>)
doesn't have the concept of a "record," just "entities" and
"relationships". The XML wrapper can include any combination of
entities and relationships - there's no requirement that it be,
say, Work-centric (show one Work and all the other FRBR entities
with relationships to that Work) or Manifestation-centric (show one
Manifestation and all the other FRBR entities with relationships
to that Manifestation), though you could easily use the format for
either of those purposes. Therefore the big .xml file that has all
the Expression data doesn't *have* to have relationships between
Expressions and Works to be valid. We simply chose to arbitrarily
break the data into individual XML files by entity and relationship
type, since there was enough data we knew we had to split it up
somehow to keep the file size to something remotely manageable, so
this seemed logical. It's just the raw data - a system using it
could index and store and update it however it likes. All the
relationships are there, though, spread across all of the files.
Relationships between Works and Expressions can be found in the
file realizedThrough.xml.
I suspect the link to be via the file realizedThrough.xml, because
between manifestation and expression, there's the file embodiedIn.xml
which seems to be the link between the two. However, I'd have expected
the relationship between E and M to be 1:n, yet it seems to be
the opposite.
Can you elaborate on this matter?
You've switched to talking about the relationship between
Expression and Manifestation rather than Expression and Work, so
I'm a bit confused as to what you're asking, but I'll give it a
shot. You're correct that embodiedIn.xml lists relationships
between Expression and Manifestation. (Note "realized through" and
"embodied in" are terms right out of the FRBR report to describe
these relationships.) The relationship between Expression and
Manifestation is n:n (many to many). A given Expression be embodied
in any number of different Manifestations, and a given
Manifestation may embody any number of different Expressed Works.
In embodiedIn.xml, each element <efrbr:embodiedIn> describes the
relationship between one Expression and one Manifestation. This
statement, however, doesn't mean that's the only Manifestation of
that Expression, or the only Expression that appears on that
Manifestation. Instead, these are just tiny statements of fact. To
find all the Expressions on a given Manifestation (which is only
one of the many questions one might want to ask of this data),
you'd need look for all of the <efrbr:embodiedIn> statements that
have the URI for the Manifestation you care about in the @target
attribute. You can see some of these right at the beginning of the
file:
<efrbr:embodiedIn
source="http://vfrbr.info/expression/1";
target="http://vfrbr.info/manifestation/1"/>
<efrbr:embodiedIn
source="http://vfrbr.info/expression/2";
target="http://vfrbr.info/manifestation/1"/>
<efrbr:embodiedIn
source="http://vfrbr.info/expression/3";
target="http://vfrbr.info/manifestation/1"/>
<efrbr:embodiedIn
source="http://vfrbr.info/expression/4";
target="http://vfrbr.info/manifestation/1"/>
To find all the Manifestations a given Expression appears on, you'd
look in the data for all the <efrbr:embodiedIn> statements that
have the URI of the Expression you care about in the @source
attribute. Basically it's a whole bunch of very atomic data that
can be combined in any way to answer all sorts of different
questions: What Works are by this Person? What Manifestations were
published by publisher X? What Works were performed by Corporate
Body X (i.e., which Works have Expressions that have realized by
relationships to that Corporate Body)? Ad infinitum...
Many thanks,
B.Eversberg
Hope this helps.
Jenn
========================
Jenn Riley
Metadata Librarian
Digital Library Program
Indiana University - Bloomington
Wells Library W501
(812) 856-5759
www.dlib.indiana.edu <http://www.dlib.indiana.edu>
Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
<http://www.inquiringlibrarian.blogspot.com>
========================
Jenn Riley
Metadata Librarian
Digital Library Program
Indiana University - Bloomington
Wells Library W501
(812) 856-5759
www.dlib.indiana.edu
Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
