RE: Domain modeling and FRBR/FRSAD (was Re: Open Library and RDF-- (Related to FRSAD))

Here is a focused UML representation for this example:

 

 

 

> -----Original Message-----

> From: Karen Coyle [mailto:kcoyle@kcoyle.net]

> Sent: Tuesday, July 20, 2010 1:05 PM

> To: Young,Jeff (OR)

> Cc: ZENG, MARCIA; public-lld@w3.org

> Subject: Re: Domain modeling and FRBR/FRSAD (was Re: Open Library and

> RDF-- (Related to FRSAD))

> 

> 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

>