The upshot is that you *can* do what I want to do with the non-FRBR-ized RDA properties, although those are not yet being used (the JSC has not moved them from the status of "proposed" to "accepted," and they do not want to recognize the non-frbr-ized properties as part of RDA, since they consider RDA to be fully FRBR-ized). If you do use the generalized properties, however, you are *not* using FRBR, by definition. There is no way to use FRBR and not use FRBR at the same time.
kc Quoting Jonathan Rochkind <[email protected]>: > Karen, I don't completely understand the RDF vocabulary issues either, > but since you all on RDA/DCMI committee had the foresight to create > those unconstrained 'base' properties that do not restrict domain or > range, if there is a property you'd like to put on a Work that exists in > RDA but is not allowed on work -- can you use one of those unconstrained > properties? > > I would suggest that if there is a property that logically applies to > every possible E/M of a W, and RDA declared it on E or M expecting that > it be entered identically on every E or M of a W -- then RDA is > incorrect. But so be it, we work with incorrect stuff sometimes. > > On 11/18/2010 1:59 PM, Lee Passey wrote: >> On Wed, November 17, 2010 11:45 pm, Karen Coyle wrote: >> >>> 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. >> I cannot speak to the capabilities of RDF, as I believe that the number of >> people in the world who actually understand RDF can be numbered with no more >> than 2 ditits, but I would suggest that not only is Mr. Rochkind's construct >> allowed by FRBR, it is /manadated./ >> >>> 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. >> Are you falling into the "one unit" trap that Mr. Rochkind thought I was >> subject to? Why do you feel that both of these data points must be >> represented >> in a single object? >> >> Assuming that "book23" is a manifestation, /I/ would represent your >> example as: >> >> person23 frbr:Name "Jonathan Rochkind" >> >> work23 frbr:hasCreator person23 >> >> expression23 frbr:expresses work23 >> expression23 frbr:hasTitle "A treatise on the correct use of the FRBR Model" >> >> book23 frbr:manifests expression23 >> book23 frbr:hasPublisher "Harper& Row" >> >> book24 frbr:manifests expression23 >> book24 frbr:hasPublisher "Random House" >> >> Five Entities representing two Manifestations of a single Work with no >> redundant data. Seems perfect to me. >> >>> 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." >> Correct. You assign a property to the appropriate "thing" and then you build >> relationships that tie the "things" together in different ways. This way you >> can avoid inconsistent, redundant data. >> >>> 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. >> If RDF cannot express FRBR/WEMI properties and relationships then >> it seems to >> me that RDF is broken, not FRBR/WEMI. Do not conflate the two, they are >> orthogonal systems. >> >> It is certainly possible to express the foregoing in a single "unit" using >> generic XML, so I presume it should be possible to do so using the RDF >> vocabulary. Consider this, in which the relationships are implicit: >> >> <theWholeThing> >> <frbr:Manifestation id = "book24"> >> <frbr:Manifestation.Publisher>Random >> House</frbr:Manifestation.Publisher> >> <frbr:Expression id = "expression23"> >> <frbr:Expression.title>The correct use of >> FRBR</frbr:Expression.title> >> <frbr:Work id = "work23"> >> <frbr:Person id = "person23" rel = "frbr:IsCreatedBy"> >> <frbr:Person.name>Jonathan Rochkind</frbr:Person.name> >> </frbr:Person> >> </frbr:Work> >> </frbr:Expression> >> </frbr:Manifestation> >> </theWholeThing> >> >> Or this, in which the relationships are explicit: >> >> <theWholeThing> >> <frbr:Person id = "person23"> >> <frbr:Person.name>Jonathan Rochkind</frbr:Person.name> >> </frbr:Person> >> <frbr:Work id = "work23"> >> <frbr:IsCreatedBy ref = "#person23" /> >> </frbr:Work> >> <frbr:Expression id = "expression23"> >> <frbr:Expression.expresses ref = "#work23" /> >> <frbr:Expression.title>The correct use of FRBR</frbr:Expression.title> >> </frbr:Expression> >> <frbr:Manifestation id = "book23"> >> <frbr:Manifestation.manifests ref = "#expression23" /> >> <frbr:Manifestation.Publisher>Random >> House</frbr:Manifestation.Publisher> >> </frbr:Manifestation> >> </theWholeThing> >> >> In my mind, both of these examples express a comlete FRBR/WEM representation >> of a Manifestation. Is RDF incapable of this same sort of >> expression? Not only >> could I parse and generate either of these examples back and forth >> losslessly, >> I could probably map them back and forth to a MARC record (although possibly >> not losslessly). >> >> I find it hard to believe that FRBR + RDF is not flexible enough to >> mimic this >> kind of encoding, but then, as I repeatedly point out I don't really >> understand RDF. >> >> >> _______________________________________________ >> 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]
