By way of analogy then--Karen's approach to works would be similar to
the U.S. application profile for dealing with format and material
type in Z39.50. There, a complex interdependency of multiple fixed
field values is used to determine that item X is AV material, or is a
DVD, or whatever. But in my limited experience, systems which
actually want to interoperate will translate these interdependencies
into simple, encoded declarations, so that other systems searching
via Z39.50 can do a single search on an index of known values rather
than having to get Boolean with all the discrete fixed field values
that lie behind them. I assume that's for reasons of processing
efficiency. I'm not sure how this would scale with the vastly larger
number of discrete work entities; and if the same record is supposed
to interoperate with multiple different application profiles for what
a work is, ...
Alternatively, each community that decides it needs one could have a
registry of defined work entities, and the access in the
institution's record could be a statement of the relationship between
the work's registered ID and the object being described. The elements
needed to meet the community's definition of a work would be
contained in its work entity record. There could also be the option
of deriving from the work entity record a standard form for
searching, sorting, and display, as well as elements of the work's
definition that might be useful as access points in the institution's record.
And the work entity record could also define it's relationship to
other entity records, etc.
In any case, it's great to see this discussion progressing to the
management of multiple definitions of what the Group 1 entities are.
That I can deal with, even enjoy dealing with. But the notion that
somehow we can do good searching and collocation without
acknowledging differences in the definition of the FRBR entities, or
by allowing the "same" entity name to have multiple definitions (like
an undifferentiated personal name authority record) just drives me batty.
Stephen
At 12:29 PM 12/5/2007, you wrote:
David M Pimentel wrote:
It strikes me that one way to address this situation might be to focus
not only on the nature of the relationships between (FRBR) entities, but
also on who makes (and hence values) particular relationships.
Absolutely! I think this would be handled well through application
profiles. The Dublin Core folks have been working on this in the
bibliographic realm. There are already examples of application profiles,
such as those for Z39.50 and for the OpenURL. Done well, you should be
able to make decisions about the meaning of a relationship based on how
it is defined in the particular application profile. What this means is
that different communities can have their own peculiar (and some will be
peculiar) sets of relationships and definitions without being
constrained by the needs of others. (Which I think is what has tripped
up the library and archive communities in the past -- that we didn't
have a way to express different views using the same data elements.)
Here's one article on application profiles. There are probably many more
and perhaps better ones that others can contribute. I think I'll start a
page on APs on the futurelib wiki.
http://www.ariadne.ac.uk/issue25/app-profiles/
kc
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[EMAIL PROTECTED] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
****************************************************
Stephen Hearn
Authority Control Coord./Database Mgmt. Section Head
Technical Services Dept.
University of Minnesota
160 Wilson Library Voice: 612-625-2328
309 19th Avenue South Fax: 612-625-3428
Minneapolis, MN 55455 E-mail: [EMAIL PROTECTED]
