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

Re: Disjointedness of FRBR classes

From: Ross Singer <ross.singer@talis.com>
Date: Wed, 26 Oct 2011 21:25:03 +0100
Message-ID: <CAPJqReMfrF=9aV4oCG+x4HybG4LDaqGujDsEvjU7cCXVCNgh-g@mail.gmail.com>
To: Karen Coyle <kcoyle@kcoyle.net>
Cc: Tom Baker <tbaker@tbaker.de>, public-lld@w3.org
I guess the question I have about loosening up the constraints around
FRBRer (or any FRBR) would be, "what's the practical use of using FRBR
directly?".  That is, are the FRBR entities *really* useful outside of
a library context?  The only two that I can really see any application
of outside of simply "modeling FRBR" are Work and Item (Work being the
easiest to group things around, Item being the easiest to conceive --
Expression and Manifestation being too complicated to bother with).  I
am not really sure I can see a tremendous amount of value coming from
modeling WEMI - it makes the thing you're trying to talk about a
jumble of resources, when you really just want to talk about a Book or
Film or Poem.

In my mind, it seems much more useful to be able to talk about FRBR in
the abstract and while I'll concede that my commonThing properties
might not convey that perfectly, they do pull the conversation away
from worrying about modeling the FRBR entities themselves, which I
would argue is a distraction.

I'd personally be much more interested if somebody declared that a
bibo:Film was derivedFromCommonWork to a bibo:Book (or something,
that's not a great property name - "the abstract work implied in this
bibo:Film was derived from the abstract work implied in this
bibo:Book").  The semantics are all there and since nobody, outside of
libraries (and probably few within them) is going to bother to build
two completely different WEM stacks to express this, this issue is
sidestepped.

This is not to say that those WEMI entities couldn't be modeled at
some later point.

FRBR is complicated and controversial (in that there is so much
disagreement on the terms).  The fact that it doesn't play
particularly well with the data that people actually model seems
further reinforcement that it shouldn't be a primary focus.
Sidestepping it with properties that carry semantic equivalence that
can be applied towards everyday things, seems a much better path
towards adoption.

-Ross.

On Wed, Oct 26, 2011 at 8:12 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> Tom and Gordon,
>
> 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.
>
> 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.
>
> 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
>
>
>
Received on Wednesday, 26 October 2011 20:25:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 26 October 2011 20:25:33 GMT