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

Re: Disjointedness of FRBR classes

From: Tom Baker <tbaker@tbaker.de>
Date: Wed, 26 Oct 2011 16:10:57 -0400
To: Karen Coyle <kcoyle@kcoyle.net>
Cc: Tom Baker <tbaker@tbaker.de>, public-lld@w3.org
Message-ID: <20111026201057.GA26255@julius>
On Wed, Oct 26, 2011 at 12:12:13PM -0700, Karen Coyle wrote:
> Given the strict nature of the FRBRer declaration, I wonder if this
> couldn't be included in the discussion of Application Profiles to
> see if a solution might be found there. There could be a general set
> of FRBR classes and properties that have few constraints, then the
> library community could have an AP that performs the functions of
> FRBRer. (Perhaps FRBRer *is* that AP.) An AP makes sense to me
> because of the obvious desire to model enforceable constraints in an
> application.

I was wondering the same thing.  Application Profiles define constraints that
are layered over the underlying vocabularies.  The current OWL expression of
FRBRer could likewise be recast as a more-constrained expression to be layered
over underlying vocabularies defined, perhaps, with minimal semantic

Either way would take a "layered" approach to constraints.  The difference
would lie in the type of constraints layered.  In an OWL ontology, constraints
have to do with what is logically consistent with an artificial conceptual
universe.  In Application Profiles, the constraints have to with things one
expects to find in the data at hand.  There is a role for each, depending on
requirements, but either one can be layered on top of an underlying,
less-constrained vocabulary.

> The big trick, then, becomes creating a model that would allow you
> to intermingle bibliographic metadata that follows different APs of
> FRBR, as well as those that do not follow FRBR at all. I can imagine
> class and sub-class relationships that facilitate this, yet even the
> loosest version of FRBR would need to have a usable relationship to
> undifferentiated (no WEMI) bibliographic descriptions, and that's
> the one that still won't come clear for me.

Would it help simply to stop saying that the WEMI classes are disjoint?
Stating that Resource X is a Work and then stating that Resource X is an
Expression would be semantically acceptable.  A Work description could
potentially be seen as a Work "view" of Resource X while an Expression
description could -- without formal contradiction -- been seen as an Expression
"view" of the same Resource X.  What would break?  W, E, M, and I descriptions
could still be exposed as separate graphs, so the distributed management of
resource description -- drawing on bits from here and there -- would still be
supported.  In other words, one would not need to sacrifice the practical
benefits of FRBR.

For this to work would of course require consistent data, but this could be
achieved by using the strong OWL ontology or the Application Profile, as
needed, when the data is created.

The _formal-semantic_ barriers to merging WEMI data with legacy data (with WEMI
entities smushed into a single undifferentiated block) -- or with data that
simply slices up the world differently -- would simply melt away.  It would
come down to the classic, and unavoidable, judgement calls about how to
interpret data from a diversity of sources and perspectives.


> Meanwhile, I think that Tom is right in that this "instance" of FRBR
> is designed for a situation with trained catalogers, as well as
> applications that enforce the constraints. It defines a closed
> world. (I'm less sure that the Tillett/Murray definition is more
> open, but I would like it to be.) The AP model might be able to
> create a more open world for it be part of.
> kc
> Quoting Tom Baker <tbaker@tbaker.de>:
> >On Wed, Oct 26, 2011 at 04:03:20PM +0100, Gordon Dunsire wrote:
> >>> property "is realizer (corporate body) of" is disjoint with properties:
> >>> - has name of the corporate body
> >>> - has number associated with the corporate body
> >>> - has place associated with the corporate body
> >>> - has date associated with the corporate body
> >>> - has other designation associated with the corporate body
> >
> >Okay, so we have [1]:
> >
> >    <frbrer:P2012> <rdfs:label> "is realizer (corporate body) of"@en .
> >    <frbrer:P2012> <rdfs:range> <frbrer:C1002> .
> >    <frbrer:P2012> <rdf:type> <owl:ObjectProperty> .
> >    <frbrer:P2012> <rdf:type> <owl:NamedIndividual> .
> >    <frbrer:C1002> <rdfs:label> "Expression"@en .
> >    <frbrer:C1002> <rdf:type> <owl:Class> .
> >    <frbrer:C1002> <rdf:type> <owl:NamedIndividual> .
> >    <frbrer:P2012> <rdfs:domain> <frbrer:C1006> .
> >    <frbrer:C1006> <rdfs:label> "Corporate Body"@en .
> >    <frbrer:C1006> <rdf:type> <owl:Class> .
> >    <frbrer:C1006> <rdf:type> <owl:NamedIndividual> .
> >    <frbrer:P2012> <owl:propertyDisjointWith> <frbrer:P3045> .
> >    <frbrer:P3045> <rdfs:label> "has place associated with the
> >corporate body"@en .
> >    <frbrer:P3045> <rdfs:domain> <frbrer:C1006> .
> >    <frbrer:P3045> <rdf:type> <owl:NamedIndividual> .
> >
> >and then:
> >
> >    <frbrer:P2012> <owl:propertyDisjointWith> <frbrer:P3045> .
> >
> >I'm struggling to see the interoperability gains of putting all
> >these "disjoint
> >property" statements into the definitions of the base vocabulary.  Triples
> >about disjointness are 45% of the 3930 triples in [1].
> >
> >>Property disjointness is given where the value of the object of an instance
> >>triple should not be interpreted as referencing the same thing as for an
> >>instance triple using a different property but with the same subject.
> >
> >As OWL2 puts it: "two properties are disjoint if there are no two individuals
> >that are interlinked by both properties" [2].  I can understand why one would
> >want to apply such precise semantics in controlled environments (e.g., a
> >cataloging department) for the purposes of controlling the quality of data
> >produced, but I do not see the benefit of imposing such strong
> >semantics on the
> >rest of the world by including them in the very definitions of properties and
> >classes.
> >
> >To my way of thinking, the presence of these strong semantics
> >seems to tell the
> >world that nobody should even _think_ of using these vocabularies unless they
> >really really know, understand, and subscribe to the precise interpretation
> >encoded therein and are confident they can apply it correctly (and that
> >speakers of Chinese, Spanish, and Arabic should hope the translations are
> >good).  The semantically strong definition seems to imply that these
> >vocabularies are really only intended for use by trained, professional,
> >English-speaking library catalogers using OWL reasoners, and that
> >nobody should
> >even think of building on FRBR with additional properties without
> >defining them
> >with the same high degree of precision.
> >
> >If so, that feels like a missed opportunity, because FRBR is potentially very
> >useful outside of that relatively small world.  Defining FRBRer without all
> >this disjointness, on the other hand, would not at all preclude
> >the application
> >of strong interpretations when really needed in specific contexts, such as
> >controlling the output of cataloging departments.
> >
> >In the end, though, I wonder if this strong disjointness is really
> >supported by
> >the FRBR model itself [3]?   For example, I read:
> >
> >    "On a pragmatic level, defining work as an entity in the model serves a
> >    number of purposes. It enables us to give a name and draw
> >relationships to
> >    the abstract intellectual or artistic creation that encompasses all the
> >    individual expressions of that work. ....  It is the entity defined as
> >    work, therefore, that provides us with this grouping capability. ... On a
> >    practical level, the degree to which bibliographic distinctions are made
> >    between variant expressions of a work will depend to some extent on the
> >    nature of the work itself, and on the anticipated needs of users and on
> >    what the cataloguer can reasonably be expected to recognize from the
> >    manifestation being described."
> >
> >In such places, the language of FRBR seems to suggest less a rigid
> >ontology of
> >the world "as it is" and more a set of distinctions that have value because
> >they are useful in a pragmatic sense, e.g., in splitting parts of
> >a description
> >into separate bundles that can be maintained and referenced in a more
> >distributed manner.  As Barbara Tillett and Ron Murray put it [4]:
> >
> >    E-R and OO modeling may be used effectively to create information systems
> >    based on an inventory of "things of interest" and the relationships that
> >    exist among them. Unfortunately, the things of interest in Cultural
> >    Heritage institutions keep changing and may require redefinition,
> >    aggregation, disaggregation, and re-aggregation. E-R and OO modeling as
> >    usually practiced are not designed to manage the degree and
> >kind of changes
> >    that take place under those circumstances.
> >
> >Their reference to WEMI entities as "sub-graphs" which "reproduce
> >bibliographic
> >characteristics found useful by catalogers, scholars, other educationally
> >oriented end-users, and to varying extents the public in general" -- as
> >"views", or as "groups of statements that occupy different levels of
> >abstraction" -- suggests a more flexible (and useful) basis for a formal
> >expression of FRBR defined, perhaps, more along the lines of minimal semantic
> >commitment.
> >
> >Tom
> >
> >[1] http://triplr.org/ntriples/iflastandards.info/ns/fr/frbr/frbrer/frbrer.rdf
> >[2] http://www.w3.org/TR/2009/REC-owl2-primer-20091027/#a_DisjointObjectProperties
> >[3] http://www.ifla.org/publications/functional-requirements-for-bibliographic-records
> >[4] http://www.ala.org/ala/mgrps/divs/lita/publications/ital/prepub/index.cfm
> >
> >--
> >Tom Baker <tom@tombaker.org>
> >
> -- 
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet

Tom Baker <tom@tombaker.org>
Received on Wednesday, 26 October 2011 20:11:32 UTC

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