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

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