Skip to content

Instantly share code, notes, and snippets.

@hectorcorrea
Last active August 29, 2015 14:24
Show Gist options
  • Save hectorcorrea/dcd83e2cf4d9e72c66a0 to your computer and use it in GitHub Desktop.
Save hectorcorrea/dcd83e2cf4d9e72c66a0 to your computer and use it in GitHub Desktop.
Notes from FRBR + Fedora + Inheritance meeting

FRBR + Fedora + Inheritance

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.

What is FRBR?

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

Karen Coyle's intro

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

Questions

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment