I mostly agree with Lee's general analysis. Except I'd note: Just because the FRBR document doesn't give a Work an author or title, doesn't mean we can't or shouldn't. I think the FRBR document probably _should_ have allowed such attributes. It won't be a _transcribed_ title or author, because a Work is an abstract thing, there is nothing to transcribe. It might not fit into _library_ workflow to assign a title or author to a Work.
But a Work still has a creator, and still can have an assigned (not transcribed) title labelling what the work is. If it's not in the official documented FRBR list of attributes, oh well, we can add it ourselves anyway if we need it -- to me it seems adding extra attributes to entities still used largely as FRBR intended is fine, it won't make your data incompatible with anyone elses FRBR data. I would also add, Lee, I think it's totally consistent with your and my analysis to in fact give attributes to Works. Consider, as you say: * "Every assertion|attribute value|property value of or about a work is also a valid assertion|attribute value|property value of or about the Expression that expresses the work. " Indeed. So if there's something you want to say which is _inherently_ true about all Expressions (and their Manifestations and THEIR Items) of a Work, the proper place to say it is about the Work. Then it is true of all past and future EMI of the Work, just as you intended. There is no need for an extra entity for "the whole thing", that's what the Work already does. I think adding an extra entity for "the whole thing" way more violates the conceptual model of FRBR, and is more likely to make your data no longer compatible with other peoples data, than adding missing attributes to a Work. I think Lee's perspective that: "I believe it is completely valid to say a Manifestation is a collection of all the values satisfying the entire Work/Expression/Manifestation hierarchy. " I think that is a true and accurate statement, but also one from the perspective of our legacy data with the "unit record" approach. Where we've got this ONE record that combines M E and W attributes all on the same record. But mostly M. So the only way to figure out the E and the W is to find the 'common elements' from the 'unit record'. That is perfectly compatible with the FRBR model, but is certainly not the way we'd CHOOSE to record our data starting from scratch, rather than all these legacy records. We'd put the W and E on seperate records. Since an M always has an E which always has a W, you _could_ say that the Manifestation is a collection of all it's E and W values too, this goes with the model fine. But I wouldn't. It also sounds to me like Lee is right that the way that OL has chosen to map it's internal data to FRBR is not the most useful way. I think he's right that "an OL Work record is best exposed as a FRBR Expression, and an OL Edition is best exposed as a FRBR Manifestation. " Exposing things thusly gives you no obligation to use all and only the attributes from the FRBR document for each entity. The document is a work in progress. I think the more useful thing is the entities, and mapping to the one that closest matches your data. I think my blog post about FRBR understood as set relationships might be helpful for deciding which FRBR entity you're dealing with. (Goes without saying, there is ALSO no obligation to decide boundaries between different works or different expressions or different manifestations the same way traditional library cataloging does. Even the FRBR document suggests this.) Jonathan Lee Passey wrote: > First off, let me say that despite a good faith attempt on my part I am > still utterly clueless about RDF. I find it is so opaque and poorly > documented as to be virtually useless. I can render no opinion whatsoever > about how FRBR concepts or OL concepts would be translated to RDF. > > That having been said... > > On Sun, November 14, 2010 11:36 pm, Karen Coyle wrote: > > >> Quoting Erik Hetzner <[email protected]>: >> > > [snip] > > >>> Also, do you want to make <http://openlibrary.org/books/OL24091785M/> >>> have type frbr:Manifestation? >>> >> That's the big question. The OL "book" is not a FRBR manifestation... >> it's a thing of OL's own invention that has some elements of >> manifestation, expression and even work. >> > > OK, you lose me here. As I understand WEMI, it is a stricly hierarchical > collection of attribute|propertie values from highly abstract "works" to > highly concrete "items" (I personally prefer the term 'instances'). While > a single work may have a multitude of Expressions, an Expression is the > expression of one, and only one work. > > Every assertion|attribute value|property value of or about a work is also > a valid assertion|attribute value|property value of or about the > Expression that expresses the work. Even if it is not explicit, no > Expression can exist without an underlying Work. > > Likewise, every assertion|attribute value|property value of or about an > Expression is also a valid assertion|attribute value|property value of or > about the Manifestation that manifests the Expression. A Manifestation > cannot exist without (conceptually) a specific Expression, which again > references a specific Work. > > Reverse relationships do not hold. An assertion|attribute value|property > value of or about a Manifestation is not necessarily a valid > assertion|attribute value|property value of or about the Expression (only > one) or Work (only one) which it manifests (although it may be if the > attribute|property is inherited from the parent). Indeed, this is how I > would go about determining which object should possess a particular > attribute or property; if /all/ manifestions MUST have an equivalent > attribute|property which has the same value then the property|attribute is > one that is properly associated with an expression object, not a > manifestation object. > > For example, all manifestations of "The Authorized Edition of Mark Twain's > Tom Sawyer" must have a title (attribute|property) of "The Authorized > Edition of Mark Twain's Tom Sawyer" (value); thus the title > attribute|property should be an attribute|property of the Expression > record/object, not the Manifestation record/object. On the other hand, the > number of printed pages may vary among Manifestations, so the > number_of_pages attribute|property is properly a part of the Manifestation > object. > > I think that much of the clumsiness of composition of the forgoing > paragraphs illustrates that a "WorkExpressed" is equivalent to an > "Expression" (because an Expression MUST inherit one and only one Work), > and an "ExpressionManifested" is equivalent to a "Manifestation" for an > analogous reason. By way of the transitive property I conclude that a > "WorkManifested" is also equivalent to a "Manifestation," simply one where > the attributes|properties ordinarily associated with an Expression are not > distinguished from the attributes|properties ordinarily associated with a > Manifestation. > > I believe it is completely valid to say a Manifestation is a collection of > all the values satisfying the entire Work/Expression/Manifestation > hierarchy. > > Several months ago when I was trying to fit OL's polymorphous schema into > a WEMI-based scheme I came to several conclusions. The first was that OL's > "Work" record did not represent a work at all, but was instead closest to > an expression. In fact, as I decomposed what constituted a Work I ended up > concluding that a FRBR Work is so abstract that it has virtually no > properties at all; it is probably best described (similar to what has be > described elsewhere in this thread) as "that object which is claimed as a > work record by this collection of Expressions." Now I don't claim that a > set is a Work, or a Work is a set, but it can be defined as the common > value in a set. > > Note that works don't have authors as properties; authors are an entirely > different entity. What they /do/ have is a "CreatedBy" property whose > value is the identity of one or more authors. Neither do I believe that > works have titles; a title is a property of an expression, often altered > according to the expression, and frequently assigned by publishers and not > authors. I ended up defining a Work object which was nothing more than a > collection of unique identifiers (OLID, ISTC, my own database id) which > could then be related to an author object and an expression object. > > Of course, OL does not have shelves (in fact, it doesn't even have an > archive), so it can't have items. It seems that the OL "Edition" record is > thus closest to a record of a FRBR Manifestation, wherever it may be > found. Thus, when you say, "The OL 'book' is ... a thing of OL's own > invention that has some elements of manifestation, expression and even > work," I say, "Hmmm, the OL 'book' must /be/ a FRBR Manifestation, because > it contains the elements of a Manifestation, an Expression and a Work -- > just like a Manifestation is required to." Now maybe it would be > appropriate to mark those values in an OL 'book' record that are included > because they are inherited from the implicit Expression record, as > distinguished from those assertions|attributes|properties that are unique > to Manifestations, but it still seems to me that a "WorkManifested" is > just a FRBR "Manifestation." > > So it seems to me that an OL Work record is best exposed as a FRBR > Expression, and an OL Edition is best exposed as a FRBR Manifestation. I > suspect that there are some attributes|properties that should be moved in > the schema from one record to the other for the best match, but OL has no > real commitment to any specific schema so this could be easily > accomplished. I think this mapping of OL records to FRBR objects is good > enough to go with for the time being. > > _______________________________________________ > 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] > _______________________________________________ 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]
