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