I don't interpret their response as disagreeing with me, as opposed to just another perspective. But even if they do disagree with me, I don't see any reason that it makes your data incompatible with anyone elses FRBR data or violates the model as described by them in any way to operate according to the perspective I am outlining.
Every expression belongs to a work, every manifestation belongs to an expression. If you have an assertion you would like to existentially apply to every past and future E or M of a work -- it only makes sense to make it on the Work, even if the FRBR committee doesn't recognize this, it's still true, and causes no problems whatsoever for your data's interoperability with anyone else using a FRBR model. This is just an inherent consequence of the FRBR conceptual model, whether or not the "FRBR Committee" recognizes it. But I am not sure the email you forwarded is actually a disagreement, so much as a misunderstanding. It's hard to talk about this stuff and be sure we're talking about the same thing, since it's so abstract. Karen Coyle wrote: > Quoting Jonathan Rochkind <[email protected]>: > > >> The Work represents the set of all Expressions that belong to it. The >> "set of all expressions" is not _an expression_, it is the set of all >> expressions, so, yes, they are disjoint sets, the entities, in that >> sense. Likewise, the expression represents "the set of all >> manifestations", etc. So yes, a work entity can't _also_ be an >> expression or manifestation, because the work is the set of all >> expressions (and their constituent manifestations, and their constituent >> items), which is a different thing. >> >> > > Jonathan, I know you think this to be true, but the reply from the > representative of the FRBR working group says that this is not so. I, > too, would like this to be the case. To make it so, we need to have > this conversation with the people developing the FRs. > > kc > > > >> I am pretty sure work represents the whole in this sense, and that this >> does not contradict the FRBR definitions at all, is implicit in them, >> and is in my opinion the most useful and least confusing way to consider >> them. >> >> If there's something you want to say about all >> expressions/manifestations/items within a Work, I think it makes sense >> to say it about the Work. I don't think adding another entity into the >> mix will clarify more than it confuses. It might be helpful to take >> this a little bit more concrete, come up with examples of assertions >> you'd want to apply to "the whole" to see if they make sense to apply to >> the Work. I am predicting that all of them will make perfect sense to >> apply to the Work. Because that is the nature of the Work. >> >> I and several other people have commented before on the usefulness of >> considering the FRBR entities as set relationships, I think it's the >> best way to avoid getting confused about what they are, myself. Here are >> a couple places I suggest that on my blog, but I'm definitely not the >> only one to have noticed/commented on this. >> >> http://bibwild.wordpress.com/2007/12/07/frbr-considered-as-set-relationships/ >> a relevant side issue: >> http://bibwild.wordpress.com/2010/03/17/notes-frbr-wemi-entities-physicality-interchangeability-merging/ >> >> Karen Coyle wrote: >> >>> Quoting Jonathan Rochkind <[email protected]>: >>> >>> >>> >>>> I'm confused why you need an entity for 'the whole thing'. I suggest >>>> that any assertions you think you want to make on 'the whole thing' are >>>> better made on a particular Work, and I suggest that's the intent of the >>>> FRBR model. The Work entity already is best thought of a set including >>>> all of it's EMI (a way of thinking not in the FRBR document, but >>>> _entirely_ consistent with it) -- any assertions on the Work already are >>>> on 'the whole thing'. >>>> >>>> >>> I haven't heard that interpretation before. As far as I know, the Work >>> does not represent the expression nor the manifestation -- in fact, I >>> believe that FRBR defines the classes as logically disjoint (although >>> it doesn't say this explicitly). This is how FRBR core interpreted the >>> classes: >>> >>> "No member of this class can also be a member of expression, >>> manifestation or item. Having a realization, a creator or a subject >>> implies being a member of this class. Things are a member of this >>> class if they are the value of a realization of or a creator of. " >>> >>> Unfortunately, FRBRer, as defined in the Metadata Registry, doesn't go >>> into this level of detail, so it's hard to know. >>> >>> I would be happy if Work did represent the whole, I just don't know >>> how to know if it does. I can ask Gordon Dunsire, who has been working >>> with the FRBR group and created the FRBRer registration. I'll report >>> what he says. >>> >>> kc >>> >>> >>> >>> >>> >>> >>>> What do you gain from adding another entity to the model to represent >>>> 'the whole thing'? I suggest it would represent no more and no less >>>> than the Work entity already does. >>>> >>>> Jonathan >>>> >>>> Karen Coyle wrote: >>>> >>>> >>>>> Quoting Jonathan Rochkind <[email protected]>: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> A side discussion, but I don't understand the difference between the >>>>>> "defined whole bibliographic entity" you mention, and a FRBR Work in the >>>>>> first place. I think that's what a FRBR Work already is. So I'm not >>>>>> sure what the FRBR group rejects, unless they're agreeing with me that >>>>>> that's what the Work entity already is. >>>>>> >>>>>> >>>>>> >>>>> Jonathan, my "whole entity" would be WEMI, not just Work. It would be >>>>> the entire Group 1. >>>>> >>>>> kc >>>>> >>>>> >>>>> >>>>> >>>>>> What reasons will a FRBR Work not work as this "bibliographic whole >>>>>> entity", or how do you see it being different from a FRBR Work? I >>>>>> suspect that some such failings of FRBR Work may really be reasons that >>>>>> FRBR Work needs to be tweaked or enhanced, not reasons you need another >>>>>> entity. >>>>>> >>>>>> Jonathan >>>>>> >>>>>> _______________________________________________ >>>>>> 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] >>>> >>>> >>>> >>> >>> >>> >> _______________________________________________ >> 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]
