- 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