> 
> I think we need to move back a step and think about which 
> data elements 
> in the bibliographic record need to be actionable (at least, actions 
> other than keyword search and display, which works fine with string 
> data). 

I don't disagree at all, I'm just not sure how much RDA is going to
change at this point. Of course, some of this is not about RDA, about
about the systems and data formats - but RDA inevitably overlaps with
this by making statements about how data should be recorded.

> So based on the FRBR requirements, the data being produced by RDA is 
> just fine, thank you, because it's about human use of the 
> catalog. 

I'm not completely convinced about this, but there you go

> Those 
> of us working on the systems end are not in the FRBR picture 
> at all, and 
> I don't think we're in the RDA picture either. There are days when I 
> feel like the orphaned kid being handed a bowl of gruel. And, no, I 
> don't want *more*, thank you.
> 

I suppose one of the issues is the many different angles we can approach
this from. As we've discussed before (if not here, elsewhere), there is
a difference between managing library inventory and providing a
discovery layer. It seems that you are saying that RDA may be fine for
providing a discovery layer, but doesn't support the richness of what
you might need to do with library inventory data?

My own view is that for bibliographic information we need to be thinking
web not database - I suppose more along the Open Library lines. I'm not
necessarily talking about how the systems behind the scenes work
(Content Management Systems all work differently, but all produce web
pages), but that bib data is more effectively presented as a web. I
don't claim to be expert in semantic web tech, but there seems to be an
incredibly good match between this approach, and the FRBR model - but
this doesn't seem to be where we are going, which frustrates me. (I may
not completely understand how RDA tackles this, so if anyone can comment
on this, or point me at the right stuff to read, then that would be
great).

I'm clearly not the first/only person to see this as a way forward - the
way that I see it (this month at any rate) is that we should be looking
to establish a way representing the FRBR entities and their
relationships in a 'web-type' environment. Linking should be at the
heart of this. If you were cataloguing a new item, you would create a
local record for the item, linking it to an existing record for the
manifestation, which would already be linked to expression and work. If
there wasn't a manifestation record already in your environment (as big
or small as you want - your system, or all systems), then you create one
etc.

In an environment such as this, deduping would be something that would
emerge from the environment. Some manifestation/expression/work records
would gain 'concentration' in that they would have more incoming links,
but there might still be multiple versions - which could also be linked
together as equivalent, or deduped by other means.

I could go on, this is probably not the time/place.

The point is that if we took this approach to bib data, then the
'inventory' systems, and the types of issue you describe (for instance)
with 'systems' tasks becoming different in nature. So, I guess I'm
saying that given a free-hand, I'd opt for creating a completely new
kind of picture, rather than trying to bring RDA in it's current form to
a point where it serves a variety of needs.

Owen