 |
 |
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