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]
