- From: ZENG, MARCIA <mzeng@kent.edu>
- Date: Tue, 20 Jul 2010 00:25:58 -0400
- To: "Young,Jeff (OR)" <jyoung@oclc.org>, Karen Coyle <kcoyle@kcoyle.net>
- CC: "public-lld@w3.org" <public-lld@w3.org>
- Message-ID: <C86A9D96.E063%mzeng@kent.edu>
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
Attachments
- application/octet-stream attachment: Picture 4.png
- application/octet-stream attachment: Picture 5.png
- application/octet-stream attachment: Picture 6.png
Received on Tuesday, 20 July 2010 04:30:13 UTC