W3C home > Mailing lists > Public > public-lld@w3.org > March 2011

Re: Question about MARCXML to Models transformation

From: <PATRICK.LE-BOEUF@bnf.fr>
Date: Wed, 9 Mar 2011 16:10:44 +0100
Cc: patricia.riva@banq.qc.ca,martin@ics.forth.gr,maja.zumer@nuk.uni-lj.si,smiragli@uwm.edu
Message-ID: <OFDB883E35.255EEEF2-ONC125784E.004CAF1A-C125784E.00536185@LocalDomain>
To: public-lld@w3.org
In FRBRer there are no superclass/subclass relationships of any kind, and 
it is extremely difficult to define what binds together Work, Expression, 
Manifestation and Item and excludes e.g. Concept or Object.
As far as I know, FRBRCore originated as a private initiative 
independently from IFLA, while FRBRoo was developed by a working group 
affiliated to the IFLA FRBR Review Group, and was submitted for reviewing 
by the IFLA Cataloguing Section prior to its publication. Of course 
private initiatives are always welcome and FRBRCore is an interesting 
result, but please keep in mind that FRBRoo is somewhat more "officially 
IFLA-sanctioned" than FRBRCore. Besides, the FRBRoo Working Group includes 
both representatives for IFLA and for the ICOM CIDOC, which makes it 
"doubly official" ;-)
FRBRCore was designed in order to represent FRBRer as RDF triples, while 
the aim of developing FRBRoo was primarily to harmonize the FRBR 
conceptualization with the museum model CIDOC CRM; the transformation of 
FRBRer into an object-oriented formulation was only a means to that end. 
As the contexts for the development of FRBRCore and FRBRoo were different, 
it ensues quite naturally that the outcomes are different.
It is incorrect to state that FRBRoo has declared a specific WEMI 
superclass. However, that superclass is virtually present:
- F1 Work is declared as a subclass of the CIDOC CRM class E89 
Propositional Object ("sets of propositions [...] that are documented as 
single units or serve as topics of discourse").
- F2 Expression is declared as a subclass of the CIDOC CRM class E73 
Information Object, which in turn is declared jointly as a subclass of 
both E89 Propositional Object and E90 Symbolic Object ("identifiable 
symbols and any aggregation of symbols [...] that have an objectively 
recognizable structure and that are documented as single units"). To put 
it in simpler, lay terms, that means that F1 Work represents a set of 
ideas independently from the way these ideas are expressed, while F2 
Expression represents both the signs that express the ideas and the ideas 
themselves. FRBRoo does not disregard the work when it envisions the 
expression, it is aware that the work is still there in the expression.
- The FRBRer Manifestation entity was split into two: F4 Manifestation 
Singleton when the set of physical carriers of an expression comprises 
only one physical object, which makes it difficult to distinguish between 
what pertains to the Manifestation level and what pertains to the Item 
level, and F3 Manifestation Product Type whenever there is an intention to 
produce at least two sibling items. F3 Manifestation Product Type is still 
a conceptual entity while F4 Manifestation Singleton is a physical object: 
FRBRoo, just like CIDOC CRM, makes clear distinctions between physical 
things and conceptual products of our mind. F3 Manifestation Product Type 
is declared as a subclass of the CIDOC CRM class E55 Type, which in turn 
is a subclass of E28 Conceptual Object, which subsumes all of E55 Type, 
E89 Propositional Object, and E90 Symbolic Object.
At this point, we therefore have E28 Conceptual Object  as an umbrella 
superclass for F1 Work, F2 Expression, and F3 Manifestation Product Type 
(note however that F6 Concept is declared as equivalent to E28 Conceptual 
Object: once again, it is extremely difficult to define a class that 
encompasses all that a Work, an Expression and a Manifestation is, but 
excludes what a Concept is).
- Both F4 Manifestation Singleton and F5 Item are subclasses of E24 
Physical Man-Made Thing (although the is-a chains are not the same in both 
cases, but I spare you the details...).
- Now, in CIDOC CRM, there is a class that subsumes both E28 Conceptual 
Object and E24 Physical Man-Made Thing: it is E71 Man-Made Thing 
("discrete, identifiable man-made items [in the general sense of the term; 
this definition comes from CIDOC CRM] that are documented as single units. 
These items are either intellectual products or man-made physical things, 
and are characterized by relative stability. They may for instance have a 
solid physical form, an electronic encoding, or they may be logical 
concepts or structures.").
E71 Man-Made Thing may seem to you too generic to cover the "WEMI thing", 
but once again I find it extremely difficult to think of a set of 
properties that would be common to W, E, M and I and that would suffice to 
unite them in one superclass while excluding all the rest.
Patrick Le Boeuf
(former chair of the FRBR Review Group - in a very remote past - and 
current member of the FRBR-CIDOC CRM Harmonization WG that developed 

Message de : Karen Coyle <kcoyle@kcoyle.net> 
                      09/03/2011 00:02

Envoyé par : 

public-lld <public-lld@w3.org>

Re: Question about MARCXML to Models transformation

Quoting Antoine Isaac <aisaac@few.vu.nl>:

> Well, if you need it such a "bibliographic blob", my two cents would 
> be to just go for it and create this new class. But create it as a 
> union of the classes for W, E, M or I. This is perfectly allowed, 
> isn't it?
> And then just use OWL for representing this axiom, et voila, 
> according to the OWL semantics [1], W is all of a sudden a subclass 
> of your blob, and so are E, M and I. I really don't see any reason 
> for which one could not do that.

FRBRCore and FRBRoo already have created a super-class of WEMI (each in
their own way, of course:-)). FRBRer, the "version" of FRBR that 
should beofficially sanctioned by IFLA, does not have that and I have 
heard it said
that the IFLA FRBR WG does not wish for there to be such a class. I don't
know the reasoning behind it, and hope that someone who does know could
bring that into the conversation.

Don't the sub-classes need to be defined in relation to the super-class?
If so, then you can't create a WEMI super-class and connect it to FRBRer
because FRBRer WEMI would not themselves have it defined as their 
super-class. OR
can you? Can you have a super-class with sub-classes even though the
sub-classes are ignorant of the relationship?


Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Exposition  Visions d'Égypte. Émile Prisse d'Avennes (1807-1879)  - du 1 er  mars 2011 au 5 juin 2011 - BnF - Richelieu / Galerie Mansart  
Avant d'imprimer, pensez à l'environnement. 
Received on Wednesday, 9 March 2011 15:21:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:43 UTC