On Thu, December 9, 2010 1:00 pm, Lee Passey wrote: > On Wed, December 8, 2010 12:08 pm, Karen Coyle wrote: > >> I'd love to see it. Everyone's FRBR implementation seems to be >> different. Sometimes slightly different, sometimes wildly different. >> Maybe you can put your schema someplace online that could be pointed to? > > I had to go and open my big mouth. > > After searching my hard drives I came up with > "http://www.passkeysoft.com/~lee/OpenCat.sql";.
Because "Authors" and "Works" are orthogonal (related but independent), before I could design a database schema for the FRBR Group 2 entities (IMEW), I first wanted to design a database schema for FRBR Group 1 entities (responsibleEntities). FRBR only defines two types of "responsibleEntities": Persons and Corporate Bodies. Certainly the "Citizens United" case has significantly blurred the line between "real" people and "artificial" people (corporations). But I'm pretty sure that "The 9/11 Commission" is neither a person or a corporation. And what about NGOs (non-governmental organizations) which are not persons, corporations, governmental agencies or commissions? So I decided to unlayer every type of "responsibleEntity" (hereinafter just "Entity") I could think of, to see what was at the core. Rats, another onion. So how could I identify one Entity and distinguish it from another Entity? Works can be "defined", more or less, by the collection of expressions and subject references that "claim" them. What about Entities? Well, exactly like Works are referenced by one or more non-unique subject categories, Entities are referenced by one or more non-unique names. Of course, there are so many names out there, and Entities are generally known by so few, that even if you had a full collection of /all/ the names ever assigned (or self-assigned) to an Entity, you still may not be able to uniquely identify it. And while it is tempting to pick one name to be the "canonical", "authoritative", or "legal" name, society will almost always find ways to frustrate you. Whatever name you pick you can be certain of two things: 1. it will not uniquely identify an entity, and 2. someone will disagree with your choice. Historically, when one has wanted to uniquely identify an individual, s/he has included an approximate birth-date (if known) or an approximate death-date (if known) or some approximate date when the individual was known to exist (if known). That information was usually good enough in a specific context (I mean the Author Thomas Mann born in 1875, not the Baker Thomas Mann born in 1875 -- no doubt the origin of names like Thomas Baker, Thomas Smith, and Thomas Fisher. Just think of the names we might have had if more people in the 14th Century were literate! Thomas Scrivner!) It's easy to think that a birth date is an attribute of a person (ignoring for the moment the problem of "artificial" persons), but in fact it's more of a specific instance of a generalized relationship: participation in an event. Presumably, a person is the subject of but one birth event and one death event in her life. But a person participates in hundreds of other events, playing different roles and at different times. Personally, I have participated in three birth events in my life so far; once as the child, and twice as the father. (Among other ancestors I have two great-grandfathers: one Swedish named "Anders Anderson", and the other Danish named "Valentine Valentinsen." Boy, there really /is/ nothing new under the sun.) And I would bet real money that "event=Normandy evasion, role=Supreme Allied Commander" is a much more accurate identifier than "Dwight Eisenhower." If we had a collection of all the events in an Entity's "life" (Incorporation? Indictment?) with the Entity's role identified, together with a collection of names assigned to that entity over the course of time, I would think you would have a rock-solid identification scheme. Not to belabor the point, and to get down (finally) to brass tacks, this is the approach I decided to take in coming up with my database schema. Like a "Work", an "Entity" is an abstraction defined almost exclusively by relationships and references. Next in this breathtaking series: How I Used Abstract Notions to Build a True (mostly) FRBRized DataBase System! (gasp!) _______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to [email protected]
