On Sun, 21 Mar 2010, Karen Coyle wrote:
> One thing I am finding about FRBR (and want to think about more) is that one
> seems to come up with different conclusions depending on whether one works
> down from Work or works up from Item. The assumption that an aggregate in a
> bound volume is an Expression seems to make sense if you are working up from
> the Manifestation, but it makes less sense if you are working down from the
> Work. If decisions change based on the direction, then I think we have a real
> problem!
It's a *reference model*. People are going to apply it differently, for
what works in their situation.
It is pointless to assume that we will ever get everyone to agree on a
single implementation -- it's either too complex and waste's people time
for stuff they don't care about, or it's not complex enough and doesn't
handle your special situations and strange edge cases.
Build the system that makese sense for your needs, and use FRBR as
guidelines on issues to consider, basic requirements, etc. It is not an
API spec. It is not an interchange format.
RDA, on the other hand, is more concrete -- it has specific cataloging
instructions on how to deal with specific situations. (and well, in the
case of aggregates as new expressions without a resultant new work, as
I've come to understand from this discussion, rules that might not comply
with FRBR) With the RDA toolkit, you even have a specific implementation.
...
Maybe my take on the situation is different because I don't deal with
bibliographic objects. Technically, by FRBR, I don't even deal with
Items, as it's all digital. (and I don't want to try to answer if little
bits of magnetic film spread across my disk arrays make up an 'Item', as
then I have to consider things being new Items when my disk array decides
to move data around because a drive starts to fail)
... as such, there's no way in hell I'm going to be able to mesh my
resultant catalogs with most other people's catalogs (and to do so,
wouldn't make sense for the users). I also have to try to mesh other
catalogs with our federation, where we just don't have the funding to
re-catalog every object, so I'm just trying to see how each catalog fits
within a common model, so I know how to talk to each system and how the
granularity of their results compares to the results from other systems.
I specifically have to plan for everyone coming up with their own systems;
some are spectacularly bad. (A new database table every year or month, so
we don't hit limits within our database. Multiple related tables, but not
actually assigning foreign keys between them. Over 10k tables, with each
catalog table storing both current and deprecated data and no way to easy
way to select just the deprecated data without going through an overly
cumbersome abstraction interface (which merges in constants as stored in
other yet other tables) ... and each of the catalog tables has no fixed
specification.)
...
I'm with Jenn on this -- different groups can set set up their little
idealized implementations of FRBR, as is being done with RDA, and the
different groups working on their implementation can ignore them when it
doesn't fit with their needs.
More concrete systems *are* needed, or we're going to end up with a
near-infinate number of variations, but some people are going to find it
easier to deal with a more restrictive model, where they don't have to
deal with complexity; and others are going to have strange edge cases that
don't fit within the restrictions that require that same complexity.
The final vote on if people accept the restrictions of RDA will be if they
decide to adopt it, or if they have to go with some other implementation.
-Joe
|