Jonathan, your arguments make sense to me (a human) but unfortunately the data you wish to create is not allowed by either FRBR nor RDF -- perhaps because both are too rigid to do what we need to do.
The FRBR WEMI entities are declared as disjoint in their domains. Therefore, if you say: book23 frbr:hasCreator "Jonathan" book23 frbr:hasPublisher "Harper & Row" you have created a contradiction, because no RDF subject can be both a Work and a Manifestation, since those are disjoint. The statement book23 frbr:hasCreator "Jonathan" in RDF declares by inference that book23 is of the domain that has been defined for the predicate property. These rules mean that you cannot mix and match properties between WEMI, assigning them to the same identified "thing." This is one of the main objections I have to WEMI. It would be great if the assignment of properties to one of WEMI would be optional, but RDF does not appear to have that concept. It is for this reason that the declaration of RDA in the metadata registry has created non-FRBR-bound super-properties. This appears to be the only way to use the properties without being caught up in the rigidity of FRBR. Analogously, we would need to create a set of "FRBR" properties for Group 1 that are not separated into WEMI to do what you describe below. WEMI would then be sub-properties of that declared set with the further restrictions that WEMI have today. I haven't thought this through far enough to be able to declare that it would work, but I think it is an idea worth exploring. kc Quoting Jonathan Rochkind <[email protected]>: > "Would a Dublin Core record be described as being "VersionOf" every > Expression associated with the Work? " > > Do you mean _should_ it be described that way? Or do you mean "if I > consider this dublin core record to be a VersionOf every Expression of > the Work, how do I actually record that?" > > For the latter, it is clear to me that you'd model it as being VersionOf > the _Work_. Anything that is true of every expression, the object of > your predicate is the work. > > Now as far as how to actually consider the semantics, that is indeed > trickier. > > If you have a non-FRBR record, I think your first step is deciding > according to the FRBR ontology what it best represents. Is it meant to > represent the work in general? Is it meant to represent one particular > textual version of the work? Then Expression. Is it meant to represent > one particular physical printing of the book? Manifestation. It doesn't > matter if your thing understood as an M or E isn't _exactly_ what > traditional library cataloging practices would consider an M or E -- the > FRBR document itself acknowledges that differnet communities will do > this differently. But I still think FRBR is useful as a general > skeleton, and I think your thing probably can be mapped to either W E or > M, according to what your thing represents. That this requires one to > think about what the thing actually represents, when one hasn't been > forced to think about that before, well, that's a positive thing, you > can't have interchangeable data without being explicit about what your > given entity represents. (A point I make to catalogers often, but > catalogers certainly aren't the only 'naive modellers' who do not > consider it). > > If you don't know, and it's just "you know, it's the book, just, in > general", then it's probably best understood as a Work. > > Once you do that, then you may find that the FRBR document itself still > doesn't offer the proper relationships to relate it to other things. If > so, that's a gap in the FRBR document, and you should, in my opinion, > simply create relationships to express what you need. > > I think it would be backwards and lead to trouble down the line to > decide which entity something is based on what relationships are > available! Mis-modelling your domain to take advantage of already > existing relationships is a bad idea, that will make things confusing > down the line. If your record is really best modelled as a Work, but you > want to relate it to a particular Manifestation, but there is no > Work->Manifestation relationship available -- that still doesn't mean > your thing is a Manifestation. The first step is modelling your thing > as the FRBR entity that best represents it. Then if insufficient > relationships or attributes are available, you'll just have to invent some. > > Jonathan > > Karen Coyle wrote: >> Quoting Jonathan Rochkind <[email protected]>: >> >> >>> I mean,I'm saying that something you want to be true for all E M and I >>> of a Work _is_ about the Work, whether a person you talked to on the >>> FRBR committee recognized that or not (which may just be a >>> misunderstanding), it is a fundamental consequence of the FRBR model, I >>> suggest, and the only way it makes sense to use the FRBR model, and >>> completely compatible with the FRBR model. >>> >> >> Jonathan, I agree with you if we are talking about what FRBR calls >> "attributes" (and RDF calls properties). If I have a new property that >> is logically at the Work level, I can add it to Work, and it in a >> sense "trickles down" through EMI. >> >> That wasn't my issue, however. What I would like is to be able to make >> a relationship between a FRBR-ized bibliographic description and a >> non-FRBR-ized or partially FRBR-ized one. Between, say, a Dublin Core >> record (which embodies WEM logically but not explicitly) and a >> FRBR-ized description. You may have something that would logically be >> an Expression/Expression relationship but one of your things is WEM >> and the other is W or E or M. And let's assume (because I think this >> will often be the case) that you don't know which E this WEM record is >> actually related to. Can I create an E/E relationship between a Work >> and a non-FRBR-ized record? What does that mean? Would a Dublin Core >> record be described as being "VersionOf" every Expression associated >> with the Work? Or is it the case that there is no logical way to >> create relationships between FRBR-ized and non-FRBR-ized data (thus >> leaving libraries again in a silo, apart from everyone else who does >> anything with bibliographic data). >> >> It seems like the only possible solution would be to hang such >> relationships on the most likely Manifestation so as not to involve >> all of the possible linked Group 1 entities (which could be a huge web >> of links), and ignore the fact that the non-FRBR-ized description >> includes some W and E elements. The difficulty, then is that most of >> the bibliographic relationships defined by FRBR are W/W and E/E, not >> M/M. (See: http://kcoyle.net/rda/group1relsby.html) >> >> kc >> >> >> >>> Consider, all the attributes actually declared on a Work _are_ true for >>> all (past and future) E M and I of the work, right? >>> >>> It is no surprise that there are additional attributes you might need, >>> either generally or for a particular application, that are not mentioned >>> in the FRBR model document. The model is just a beginning, just the >>> skeleton. >>> >>> 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] >>> >>> >> >> >> >> -- >> Karen Coyle >> [email protected] http://kcoyle.net >> ph: 1-510-540-7596 >> m: 1-510-435-8234 >> skype: kcoylenet >> >> _______________________________________________ >> 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] > -- Karen Coyle [email protected] http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet _______________________________________________ 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]
