Re: Disjointedness of FRBR classes

Karen:



On 26 October 2011 at 09:57 Karen Coyle <kcoyle@kcoyle.net> wrote:

> So, taking a glance at this it DOES seem that all of the Classes are 
> mutually disjoint. I also notice that many of the properties are 
> disjoint. This is a bit hard to analyze because the labels aren't 
> present, but I took one short list, which essentially reads:
>
> 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
>
> First, am I right that this property would be used something like:
>
> <http://microsoft.com> <frbrer:[is realizer (corporate body) of]> 
> <"Windows 7"> 
No, because the property has a range of frbrer:Expression, so you would use the
URI of a specific expression, not the literal "Windows 7".
 

>
> and "has name of corporate body" would be like:
>
> <http://microsoft.com> <frbrer:[has name of corporate body]> <"Microsoft"> 
This is correct. 
 

>
> ?
>
> Gordon, is there an easy way for you to articulate the general 
> principle that this example illustrates that leads to the "disjoint" 
> declarations? I'm unfortunately not catching that pattern here, which 
> is probably based on a set of conditions that I'm not able to tease 
> out of the code. 
The first property is derived from a relationship between two FRBR entities
(Corporate Body and Expression), and so bounded by those entities (as domain and
range respectively).
 
The other properties derive from attributes of a FRBR entity (Corporate Body).
FRBR does not specify any content standard, controlled vocabulary, etc. as the
value of the attribute of any specific instance of an entity, so these
properties do not have a specified range. They do have the Entity class as
domain.
 
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. This is
irrespective of whether the object value is a string or URI. In this example,
the value of the attributes name, number, place, date, and other designation for
a specific corporate body do not reference the same thing, say when the name and
place have the same string such as "London, England". Propery disjointness is
not explicitly declared where domain and/or range classes themselves are
declared disjoint, as it can be entailed.
 
So the pattern is to declare domains and ranges for properties based on entity
relationships, domains for properties based on entity attributes, and
disjointedness which cannot be entailed from other semantic bounds.
 
Cheers
 
Gordon 
 

>
> Thanks,
> kc
>
>
> Quoting "gordon@gordondunsire.com" <gordon@gordondunsire.com>:
>
> > All
> >  
> > The Open Metadata Registry currently does not support OWL so it does 
> > not contain
> > any of the FRBRer constraints. The full FRBRer ontology, including disjoint
> > classes (e.g. Group 1) is available at:
> >  
> > http://iflastandards.info/ns/fr/frbr/frbrer/frbrer.rdf
> >  
> > This information is available on the just-ported Library Data 
> > Resources page of
> > the LLD community:
> >  
> > http://www.w3.org/2001/sw/wiki/LLD/Library_Data_Resources#FRBR
> >  
> > Cheers
> >  
> > Gordon 
> >  
> >
> >
> >
> > On 24 October 2011 at 16:48 Ross Singer <ross.singer@talis.com> wrote:
> >
> >> On Sun, Oct 23, 2011 at 8:37 PM, Tom Baker <tbaker@tbaker.de> wrote:
> >> > On Fri, Oct 21, 2011 at 11:40:07AM +0100, Ross Singer wrote:
> >> >> could be applied to a frbr:Manifestation and a frbr:Expression (and,
> >> >> probably, in some some cases, frbr:Item), and the fact that these
> >> >> classes are disjointed with each other, a bibo:Book (or Article or
> >> >> what have you) cannot fit well into a FRBRized worldview.
> >> >
> >> > Hi Ross,
> >> >
> >> > Please remind me who exactly is saying that the WEMI classes are formally
> >> > disjoint.  There are several formalized expressions of FRBR in 
> >> circulation.
> >> > Which one(s) do you mean here and what is the status of that expression
> >> > according to IFLA (or JSC, or anyone else)?  I was under the 
> >> impression that
> >> > the RDF expressions were all still just drafts, hence subject to possible
> >> > revision...
> >>
> >> Tom, this is a fair question, so I just revisited:
> >>
> >> Ian Davis' "original" FRBR vocabulary is formally constrained (see:
> >> http://vocab.org/frbr/core.rdf)
> >>
> >> RDA's has no formal constraints whatsoever (so a resource could be a
> >> Person, Subject, Place, Work and Item):
> >> http://rdvocab.info/uri/schema/FRBRentitiesRDA.rdf
> >>
> >> FRBRer (IFLA FRBR) also (despite our long debate on this list) has no
> >> formal constraints on any of the Group 1,2 or 3 classes
> >> (http://metadataregistry.org/schemaprop/list/schema_id/5.html).
> >>
> >> So I stand corrected (and here we can dust off that old chestnut about
> >> the word "assume").  There is nothing logically wrong with with saying
> >> that a resource is both a frbr:Expression and a frbr:Manifestation.
> >>
> >> I cannot say that I feel that this is necessarily "right", though.
> >> Something seems ontologically wrong with the complete absence of
> >> constraints.
> >>
> >> -Ross.
> >>
> >> >
> >> >> These properties exist because FRBR is *so* rigid. ...
> >> > ...
> >> >> If bibo:Book or bibo:Article or dct:BibliographicResource are
> >> >> inherently disjoint with FRBR (since they do not constrain you from
> >> >> violating FRBR rules), the ov:commonThing properties let you express
> >> >> FRBR relationships on these resources without making your reasoner
> >> >> implode in a puff of logic.
> >> >
> >> > What an image...!! :-)  Seriously, has anyone suggested that the 
> >> disjointed
> >> > nature of these classes be re-assessed in light, say, of the principle of
> >> > minimal semantic commitment?  Is it too late for such a discussion?
> >> >
> >> > Tom
> >> >
> >> > --
> >> > 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
>
>