I take respectful exception to the choice of the word "belong to" when
describing relationships among the WEMI entities. To my mind, "belong"
connotes a relationship along the lines of whole-part: a chapter of a
book, if modeled as a Work in its own right, "belongs" to the larger
work in which it was conceived as a part. Similarly, a volume in a
monographic series "belongs" to the aggregate manifestation of the
entire series. Etc., etc. The fact that a Manifestation must have at
least one embodied expression (which realizes a work) in order for us to
care about it (i.e. represent it in our metadata) does not mean that the
Manifestation "belongs" to that expression (or, transitively, the work).
This is an important concept to be wary of when considering aggregates.
I anxiously await the IFLA FRBR Group on Aggregate's report, but in the
mean time, my view of the identity of aggregates as "Works" is that such
identity is highly dependent on context. In the case of textual
monographs, thinking of the content of a resource as an aggregate "work"
allows one to, for example, perform subject analysis on that content as
a unit (since that happens at the Work level). But in the case of music
resources, providing access to such a happenstance aggregate "work",
which nearly always only exists by virtue of that particular grouping,
does not serve the user. The upshot is that while aggregates can be a
helpful modeling/access tool, their existence is not necessary per FRBR.
To tie together my two points: whether or not representing the content
of a resource as an aggregate is prudent in a particular scenario, it is
never, to my mind, prudent to consider the Manifestation as "belonging"
(via an expression) to such a work. Such a restrictive view, which seems
to connote one-to-one relationships among WEMI (which FRBR does not
support) is a hindrance to interoperability. To illustrate a fairly
common case, an issue of a serial can be cataloged as a monograph, with
its content represented as a unit for purposes of subject analysis, etc.
It can also be analyzed at the article level, for access in a journal
database. The Manifestation in question, however, is the same entity in
both scenarios. So, which Work(s)/Expression(s) does this Manifestation
"belong" to? All? Neither?
To reiterate, I think what Jonathan is getting at is that a Manifestion
needs to *embody* to at least one Expression for it to be an entity of
interest in our metadata. Put another way, the "stuff" embodied in a
Manifestation needs to be represented as either a compilation of
expressed works, or one expressed work, whichever best represents the
content and provides access to the user. But in pure terms of the V/FRBR
data structure, the manifestation is simply a node in a graph, related
to other nodes, but "belonging" to none of them.
Cheers,
Casey
(full disclosure: formerly on the Variations project, but not currently
speaking on their behalf)
On 10/18/2010 8:38 AM, Jonathan Rochkind wrote:
So does that mean that you have Manifestations... which do not belong
to any Work at all? Or have you just left Works out of your
modelling altogether?
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.
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
--
Casey A. Mullin
Discovery Metadata Librarian
Metadata Development Unit
Stanford University Libraries
650-736-0849
cmul...@stanford.edu
http://www.caseymullin.com
--
"Those who need structured and granular data and the precise retrieval that results
from it to carry out research and scholarship may constitute an elite minority rather
than most of the people of the world (sadly), but that talented and intelligent minority
is an important one for the cultural and technological advancement of humanity. It is
even possible that if we did a better job of providing access to such data, we might
enable the enlargement of that minority."
-Martha Yee
