My notes from the Google Hangout organized by Christina Harlow (@cm_harlow) on 7/14/2015
Keep in mind that I captured this as the video call went on and I might have gotten some of it wrong. I'll update this page with a link to the recording once it becomes available.
FRBR (Functional Requirements for Bibliographic Records) is a 1998 recommendation of the International Federation of Library Associations and Institutions (IFLA) to restructure catalog databases to reflect the conceptual structure of information resources. - http://www.oclc.org/research/activities/frbr.html
See also "FRBR, Twenty Years On" -- http://kcoyle.net/FRBR20.pdf
FIBR is not really hierarchical but people and the documentation tend to present it as such.
Hierarchy is tricky (animal taxonomy vs boss/employee relationship)
ER analysis went into FRBR. Defines separate entities.
There is no hierarchy in ER.
FRBR is actually a graph. Diagrams make it look like a hierarchy, but it is actually a graph
Work should be separated from representations.
RDA db scenarios - look into them (they are wrong?), shows the relational thought that went into it.
Manifestation manifests the representation of the work.
FRBR is a conceptual view of bibliographic world. Tables in database don't tell you what your data really looks like. How do we un-confuse those two?
DB storage does not tell you how to work.
Data design != database design.
Don't create chains, create graphs.
Some properties in common is all you need. Your data does not have to all look the same, you just need a few fields in common. We are stuck on the idea that we have to do all the same.
Classes in RDF are NOT structures (i.e. they are not the same as OO classes).
Question by Ben:
Is the two-entity model of BIBFRAME designed on the assumption
of dense graphs that Karen is describing?
BIBFRAME has the same problem as FRBR. What's different is that no one has declared the entities as disjoined. BIBFRAME is a bit more open, but people are not treating it as such.
Question by Owen:
What do we get by implementing FRBR in Fedora?
Rob Sanderson: The advantage is the ability to discover semantically similar resources. It's about the graph.
Karen: It seems to me that you can work without creating new data elements. The semantics gives you what you need, you don't need new properties.
Rob: The semantics of the property (e.g. dc:title) gives you what you need. You don't need separate properites (e.g. representation title vs manifestation title)
Karen: There is no such thing as an item having a title (in RDF.) You only have an item when you have something that declares a subject refering to it (?)
RDF comes out of AI (!) (for better of for worse). There are no containers. You cannot pass semantics from a subject to a property, it only goes in the other direction.
What are the entities that define a work or a manifestation? There is only a few of properties that thruly define. Subjects don't necessarily define works.
Wrong approach - this is a container and it has these things.
Right approach - this is a subject and it has this properties.
Tom: FRBR is overly prescriptive in their predicates.
Rob: BibFrame is also overly prescriptive.
Esme: RDBMS and XML force you match too much (?) as opossed to RDF that is more relaxed. Fedora uses RDF.