- From: Thomas Baker <tbaker@tbaker.de>
- Date: Sun, 13 Mar 2011 19:40:29 -0400
- To: public-lld@w3.org
Jon points to work by Ron Murray and Barbara Tillett:
There's another way to look at FRBR in the context of LLD.
I'd like to point you to Ron Murray & Barbara Tillett's fabulous
presentation from the CC:DA meeting at ALA's 2010 Conference:
http://www.slideshare.net/RonMurray/from-mobydick-to-mashups
It's extremely dense, and I highly recommend reading the whole thing
because it really explores the RDA/RDF cataloging problem space, but there
are a few places where they make some extremely important observations...
Slide 14-34
In which they point out that the _original_ FRBR conceptual model was
intended to be a network graph, not a hierarchy, concluding with...
"Why is there an expectation of -- or insistence upon -- hierarchies in
the FRBR conceptual model?"
Slide 63-80 (especially 68-78)
In which they show that the FRBR 'entities' can more usefully be
considered as "Resource Description Levels" that can be "differentiated
by degree of abstraction"
Slide 150 and on... "Managing Simplicity and Complexity:Description &
Relationship Growth" "An aggregate of resources and their descriptions
may grow over time"
The fundamental problem with both of the widely accepted FRBRer and
FRBRoop models is their reliance on an entity data model that distorts the
ability to see a FRBR resource description as an aggregate of properties
"differentiated by degree of abstraction". We need to move beyond the
notion of discrete records and entities.
If you're creating and managing metadata, then it's highly useful to have
that data described by an entity-based schema so you can build forms and
normalize. And the FRBRer and FRBRoop models are reasonably good for that.
But when you're distributing and aggregating that metadata as RDF data on
the open web, they're too restrictive and the original FRBRgraph model
becomes not just more useful, but essential. And if you want to bring
aggregated LLD FRBR metadata into a system that has hierarchic FRBRer
requirements, then you make a decision for _your_ system about what to
do with missing parts of the hierarchy. You might even take the various
properties and reassign them to different 'levels'. That's what the
'open' RDA superproperties are explicitly intended to support.
We have often made the mistake of trying to define a one-size-fits-all
data model that covers data creation, management, publication, and
aggregation. Data creation and management work quite well for the XML
hierarchical model but that model creates significant challenges for
distribution and aggregation. The RDF graph model excels at knowledge
transfer, publication, and aggregation but stinks for data creation and
management. We need to make sure that we're using the best model for
the job and keep in mind the significant differences between the two.
--
Tom Baker <tbaker@tbaker.de>
Received on Sunday, 13 March 2011 23:41:08 UTC