- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 20 Jul 2010 10:04:49 -0700
- To: "Young,Jeff (OR)" <jyoung@oclc.org>
- Cc: "ZENG, MARCIA" <mzeng@kent.edu>, public-lld@w3.org
Marcia, this is the area that Jeff and I have been discussing: frbr:placeOfPublication a owl:ObjectProperty ; rdfs:domain frbr:Manifestation ; rdfs:range frbr:Place . My question is: since FRBR only defines Place as a member of Group 3, is it valid to use Place elsewhere, such as with place of publication? I guess the thrust of the question is whether the FRBR groups and their relationships define the outer limits of the domain, or if they are illustrative of a typical usage? This also comes up around the Thema: in a sense, anything that you can define could be the subject of a resource, so would FRBR recognize the use of non-FRBR resources in subject relation to a cataloged resource? I'm mainly trying to get at the INTENTION of FRBR so I can understand what we can and cannot do within the model, and where we might need to create a new but related domain model. kc Quoting "Young,Jeff (OR)" <jyoung@oclc.org>: > Marcia, > > Thanks for the additional clues. I replaced my <<informal>> "Entity" > class with frsad:Thema (diagram attached). My UML associations were > also backward, so those are fixed now too. > > Note that I am using UML domain modeling rather than Entity-Relation > modeling to express the FRBR/FRSAD models. IMO, it is much clearer, > more expressive and maps more intuitively to OWL. > > From a domain modeling/OWL POV, Group1, Group2 and Group3 are pretty > clearly associated with frsad:Thema by UML > generalization/rdfs:subClassOf relationship. Recognition of these > classes in OWL would allow them to be set as the domain/range on > FRBR attributes/relationships as named in the original > specification. Here is some hypothetical FRBR OWL that should match > the attached FRBR UML diagram: > > frsad:Thema a owl:Class . > > frbr:Group1Entity a owl:Class ; > rdfs:subClassOf frsad:Thema . > frbr:Group2Entity a owl:Class ; > rdfs:subClassOf frsad:Thema . > frbr:Group3Entity a owl:Class ; > rdfs:subClassOf frsad:Thema . > > frbr:Work a owl:Class ; > rdfs:subClassOf frbr:Group1Entity . > frbr:Manifestation a owl:Class ; > rdfs:subClassOf frbr:Group1Entity . > frbr:Person a owl:Class ; > rdfs:subClassOf frbr:Group2Entity . > frbr:Place a owl:Class ; > rdfs:subClassOf frbr:Group3Entity . > > frbr:hasAsSubject a owl:ObjectProperty ; > rdfs:domain frbr:Work ; > rdfs:range frsad:Thema . > frbr:isCreatedBy a owl:ObjectProperty ; > rdfs:domain frbr:Work ; > rdfs:range frbr:Group2Entity . > frbr:placeOfPublication a owl:ObjectProperty ; > rdfs:domain frbr:Manifestation ; > rdfs:range frbr:Place . > frbr:termForThePlace a owl:DatatypeProperty ; > rdfs:domain frbr:Place ; > rdfs:range xsd:string . > frbr:nameOfPerson a owl:DatatypeProperty ; > rdfs:domain frbr:Person ; > rdfs:range xsd:string . > > Here are some individuals to illustrate the OWL: > > <http://example.org/work/1/#frbr:Work> a frbr:Work ; > frbr:hasAsSubject <http://example.org/place/2/#frbr:Place> ; > frbr:isCreatedBy <http://example.org/person/3/#frbr:Person> . > > <http://example.org/manifestation/4/#frbr:Manifestation> a > frbr:Manifestation ; > frbr:placeOfPublication <http://example.org/place/5/#frbr:Place>. > > <http://example.org/place/2/#frbr:Place> a frbr:Place ; > frbr:termForThePlace "New York City" . > > <http://example.org/place/5/#frbr:Place> a frbr:Place ; > frbr:termForThePlace "Paris" . > > <http://example.org/person/3/#frbr:Person> a frbr:Person; > frbr:nameOfPerson "Fred" . > > Try to ignore the URI patterns if you can. > > Marcia, your comment about the lack of universal sub-typing for > frsad:Thema in terms of category, kind, or type surely means > something other than these natural UML/OWL relationships. > > Jeff > > From: ZENG, MARCIA [mailto:mzeng@kent.edu] > Sent: Tuesday, July 20, 2010 12:26 AM > To: Young,Jeff (OR); Karen Coyle > Cc: public-lld@w3.org > Subject: Re: Open Library and RDF -- (Related to FRSAD) > > Hi, Jeff and Karen, > I have not followed your discussions closely so I may have missed > some points in the following reply. Apologize if I understood > incorrectly any question. > > 1, Jeff, I want to indicate that "[t]he entities in the third group > (outlined in bold in Figure 3.3) represent an additional > set of entities that serve as the subjects of works."[1] Please > pay attention to the emphasis of "additional", meaning in addition > to Groups 1 and 2. Group 3 is not an equivalent to all the 'things' > that could serve as the subject of works. I am attaching the > interpretation of this figure from [2] (see Figure A.1). > > 2, Karen, the explanations of why the 'thema' entity was not further > sub-typed by this report was explained in Appendix A [2] and > Appendix B [3]. In Section 4.1.1. of the FRSAD report [4], it > states that in an implementation 'themas' can be organized based on > category, kind, or type. > > There seems to be no universal categorisation of themas and any > attempt to declare one would necessarily limit the > usability of a general model. Each particular implementation will > need to define the categories or types of themas. > > The original FRBR Group 3 entities are only one possible scenario. > The attempt to build the model based on Group 3, among other > attempts, was recorded in Appendix A [2]. > > 3, It is important to indicate that FRSAD is an extension to FRBR > and is fully compatible with it. (See Figure 3.1 from [4] attached). > FRSAD and FRAD were developed independently therefore there are > differences (see[3]). One thing you probably noted is that in FRAD > 'subject' is modeled just as an attribute of a 'work'. This is a > different way of modeling from that FRBR and FRSAD have done. (See > also a recent presentation on my slideshare [5]). > > The three models definitely need to be reconciled and I believe IFLA > will consider this task soon. I attach another draft image of an > overview of FRBR family major entities from [6] (see Figure numbered > as Fig. 1). > > I hope I am on the right target in this conversation. Please let me > know if you have any problem opening the figures. > Thanks for all the discussions. > Marcia > > [1] Functional Requirements for Bibliographic Records: Final Report. > (1998). München: KG Saur, p. 17. > [2] http://nkos.slis.kent.edu/FRSAR/appendixA-ModelingAboutness.pdf > [3] http://nkos.slis.kent.edu/FRSAR/appendixB-RelationWithFRBRFRAD.pdf > [4] http://nkos.slis.kent.edu/FRSAR/FRSADmodel.pdf p.19 > [5] http://www.slideshare.net/mzeng/sac20100628 > [6] Fig. 1. from a paper to be presented at DC2010. "FRBR: A > Generalized Approach to Dublin Core Application Profiles" by Zumer, > Zeng, and Salaba. > > > > On 7/19/10 8:01 PM, "Young,Jeff (OR)" <jyoung@oclc.org> wrote: > Oops. Sorry. I should have looked closer at my UML. It's been awhile since > I did this. The way I modeled it, the highest level class is "Entity" with > "Group1", "Group2", and "Group3" as subclasses. This was the only way I > could make sense of it and I admit it is my interpretation. Still, though, > I think it makes for much simpler OWL and would allow us to use real FRBR > attribute and relationship names. Would examples help? > > Jeff > > Karen Coyle <kcoyle@kcoyle.net> wrote: > > Quoting "Young,Jeff (OR)" <jyoung@oclc.org>: > > >> >> There seems to be a flaw in your argument. "Subject" is not an alias for >> frbr:Group3. Instead, frbr:Group3 is related to frbr:Work by >> frbr:isTheSubjectOf and inversely frbr:hasAsSubject. The attached UML >> class diagram should help make this clearer (note the section numbers). >> This should mean that frbr:Place could reasonably be used as the range >> for frbr:placeOfPublication. > > > So you are saying that the FRBR definition of the entity doesn't limit > it to use in a subject relationship? Here's what the FRBR document > says (p. 29): > > "For the purposes of this study places are treated as entities only to > the extent that they are the subject of a work (e.g., the subject of a > map or atlas, or of a travel guide, etc.)." > > I'm not exactly sure what "for the purposes of this study" actually > means in terms of the entity definitions, but I don't think that FRBR > includes a relationship that would allow you to relate a FRBR place > entity to a manifestation as the place where the manifestation was > published/manufactured. That doesn't mean that one couldn't be > created, and I do think we need to flesh out FRBR to include other > relationships (and perhaps even other entities). But it's not there > today. And experience that we've had in interacting with both the RDA > developers and the FRBR developers is that they feel strongly about > the completeness of their model are not happy with the idea of anyone > extending the entities and relationships that they have defined. It > will probably have to be done in a different namespace and under > different auspices. (Ditto for the creation of classes for the FRBR > groups and other FR entities. It would be great to hear WHY this is, > but there is no place where public discussion takes place on this > topic.) > > Also note that we won't really know how group 3 entities and > relationships are defined in relation to the other frbr entities until > FRSAD comes out with its final report. FRBR is very vague on Group 3, > as is RDA. But FRSAD appears to be defining few relationships: > > The FRSAD model establishes two sets of relationships: > (1) Relationships between different types of entities: WORK-THEMA and > THEMA-NOMEN. > These are the primary relationships and are illustrated in Chapter 5 > when the entities are presented. > (2) Relationships between entities of the same type: THEMA-THEMA and > NOMEN-NOMEN. > > Between works and subjects there are only two: has as subject, is > subject of. That may be enough... but I haven't thought about it in > any depth. > > kc > > > > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet > > > > > > > ------ End of Forwarded Message > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Received on Tuesday, 20 July 2010 17:05:25 UTC