I don't think "entity" and "resource" conflict.
To the user, "entity" certainly doesn't make any sense. The user is
interested in a resource. Or a book. Or a journal. Or whatever.
But we, through 100 years of practice in controlling metadata about
these resources, realize that these resources relate to each other in
some sophisticated ways. Some resources are different editions of the
same work. The FRBR model is an attempt to formalize and make explicit
our implicit shared (or not-so-shared) mental models of how this works,
and it decides it does this by Work, Expression, Manifestation, and
Item. These are entities, but all of them but 'item' are abstract concepts.
You can't give the user a "work", you can in fact only give the user an
"item". That's what the user wants, perhaps that's what a 'resource'
is. But we group these items into manifestations, these manifestations
into expression, and these expressions into works in order to figure out
_which_ resource meets the user's needs, to understand the relationship
between these resources, to display groupings to the user to help them
make sense of the complicated bibliographic universe (which they don't
realize is complicated, and we'd like to help keep it _seeming_ simple
to them, but when we try to do so we realize that it is in fact
complicated!).
I think your idea of "the resource as a whole" is mistaken. There is no
"resource as a whole", it's not like an individual resource is made up
of a work, an expression, a manifestation, and an item. A 'resource' is
probably an Item. But items are grouped together into manifestations,
etc. A user may occasionally be interested in only a particular item
(usually only in a museum/archival context, libraries are not usually
concerned with item-level identification). More commonly a user may be
satisfied by anything in an expression-set, or even by anything in ANY
expression-set meeting certain language criteria. Sometimes a user may
want a particular manifestation, or any manifestation meeting certain
format (and language) criteria. Other times a user may in fact be
satisifed by any resource in a particular Work---or be interested in
_seeing_ all the resources of a particular Work, to see the lay of the
land, and decide what she wants.
That's why the FRBR user tasks need to be accomplished against each
entity. The language of the FRBR Group 1 entities is meant to allow us
to asssemble "resources" into groups for showing the user what is there
and allowing them to find and select what they need.
Jonathan
Brenndorfer, Thomas wrote:
>> These are possible services against collections. They are ways of
>> saving the time of the reader. They exemplify growth opportunities
>> for libraries. Everybody has access to indexes and content. I can
>> carry the totality of the WorldCat index around on my iPod. Providing
>> services against content is a growth opportunity for libraries. Yes,
>> we have traditionally provided services against content, but we need
>> to provide more services against it and figure out ways to provide
>> these services in a networked environment.
>>
>>
>
> I think there is a lot of growth opportunity, but libraries have to get
> the underlying data structures and standards right and then make them
> available not only for their own internal purposes but for the larger
> public good. I suppose if that were to happen a whole growth industry
> could spring up, much like LibraryThing relies on MARC record
> information (in addition to Amazon records, or mashups of both sources).
> I don't think libraries should do it all-- companies like Syndetics and
> Serial Solutions can do things in a more rational way, but I think that
> the original mission and purpose of libraries should lead to a set of
> standards that can form the basis for both library-centered free
> information access and for a "new economy" model of information services
> to be used by all of society.
>
> Just to put things in perspective, I always like to go back to the 1997
> original FRBR paper (it caused an epiphany in some ways--it made what
> was implicitly right and wrong about cataloguing explicit)...
>
> """"At the international level, the model's mapping of individual
> attributes and relationships to the specific ways in which bibliographic
> data are used could serve as a useful framework for re-assessing data
> recording conventions and standards with a view to rationalizing the
> level of effort that is expended in "normalizing" bibliographic data. It
> could also help to frame investigations into the potential for more
> economic means of data capture. ....
> The entity-relationship analysis reflected in the model might also serve
> as a useful conceptual framework for a re-examination of the structures
> used to store, display, and communicate bibliographic data. Further
> study could be done on the practical implications of restructuring MARC
> record formats to reflect more directly the hierarchical and reciprocal
> relationships outlined in the model. An examination of that kind might
> offer a new approach to the so-called "multiple versions" issue. The
> model could also be expanded in depth to create a fully developed data
> model that would serve as the basis for the design of an experimental
> database to assess the efficiency and effectiveness of a database
> structure patterned on the model.""""
> http://www.ifla.org/VII/s13/frbr/frbr.pdf
>
>
> So have libraries got the underlying structures and standards right?
>
> I think it's very informative to note that RDA (Resource Description and
> Access) has replaced the original FRBR term "entity" with "resource"
> when discussing user tasks.
>
> A described "resource" is the traditional way of thinking about how to
> compartmentalize our bibliographic data-- it matches what fits onto our
> catalogue card. This has the effect of collapsing the original FRBR
> entities, and it weakens the original intent, which was to have each
> entity treated as a separate component.
>
> I've noted that RDA has over time increasingly aligned itself with the
> FRBR user tasks mapped against the original FRBR entities. The current
> planned chapter structure of RDA is:
>
> Chapter 2 - IDENTIFY - for resource
> Chapter 3 - SELECT by using carrier attributes - manifestation alignment
> Chapter 4 - SELECT by using content attributes - work/expression
> alignment
> Chapter 5 - OBTAIN - Acquisition and access information
> FIND task - Later chapters
> Relationships between FRBR Group 1 entities (work, expression,
> manifestation, item).
> Relationships between FRBR Group 1 and Group 2 entities (person,
> corporate body, family)
>
> The focus in RDA is on descriptive data, as opposed to fixed value data
> that can be used to SELECT results with functions such as limits and the
> new facet-based interfaces. Information that helps the user to IDENTIFY,
> SELECT, and OBTAIN is descriptive textual information, which is fine as
> far it goes, but it doesn't seem to be enough to properly provide
> overall bibliographic utility for new services in an automated
> environment.
>
> The original FRBR paper described the user tasks as happening against
> each of the entities, not the resource as a whole. So we should have
> systems that help a user IDENTIFY a PERSON or a WORK or a MANIFESTATION
> or an ITEM or a CONCEPT or a PLACE. [My earlier posts on IMDb.com and
> LibraryThing were intended to show that the original FRBR goals are
> feasible and make for great service-focused interfaces].
>
> Sticking to the original FRBR goals to me makes a big difference
> especially when drawing up the structures and standards that define
> bibliographic containers and components. I've always thought (even back
> in 1997) that the future catalogue structure would have to be based on
> compartmentalizing each of these FRBR entities, teasing them out of our
> MARC records. Only then could the full potential of what libraries are
> attempting to do be unleashed with rich new services. We have to get the
> underlying structures and standards right.
>
> Thomas Brenndorfer, B.A, M.L.I.S.
> Guelph Public Library
> 100 Norfolk St.
> Guelph, ON
> N1H 4J6
> (519) 824-6220 ext. 276
> tbrenndorfer_at_library.guelph.on.ca
>
>
--
Jonathan Rochkind
Sr. Programmer/Analyst
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
Received on Fri May 18 2007 - 09:34:55 EDT