- 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