W3C home > Mailing lists > Public > semantic-web@w3.org > March 2005

RE: true/false in RDF?

From: Geoff Chappell <geoff@sover.net>
Date: Wed, 16 Mar 2005 17:54:57 -0500
To: "'Joshua Allen'" <joshuaa@microsoft.com>, "'Danny Ayers'" <danny.ayers@gmail.com>
Cc: "'Seth Russell'" <russell.seth@gmail.com>, <semantic-web@w3.org>
Message-ID: <001401c52a7b$2e18d310$6401a8c0@gsclaptop>



> -----Original Message-----
> From: semantic-web-request@w3.org [mailto:semantic-web-request@w3.org] On
> Behalf Of Joshua Allen
> Sent: Wednesday, March 16, 2005 5:25 PM
> To: Danny Ayers
> Cc: Seth Russell; semantic-web@w3.org
> Subject: RE: true/false in RDF?
> 
> 
> > http://foobar/page.html rdf:type urn:myterms:CachedObject
> 
> Basically, you are saying that Boolean true/false are completely
> unnecessary in RDFS.  From a conceptual standpoint this is very elegant.
> However, it has some trouble.

It comes down to a modeling choice. The fact is that any property/value pair
can be turned into a class (and any class can be turned into a prop/val
pair) - e.g:

<urn:myterms:CachedObject> owl:equivalentClass 
   [owl:onProperty <urn:myterms:isCached>;
    owl:hasValue 'true'].

It just happens that nearly all of the useful inferences licensed by owl/rdf
are based on class relationships -- so in the absence of something like the
above in your ontology, it's often seen as a better choice to just use the
rdf:type XXX version.

> If my object has multiple Boolean properties (it does), do I give it
> multiple rdf:types?  One rdf:type per property, or one per combinatorial
> group of properties?  Without having n factorial number of classes for n
> Booleans, you end up with RDFS classes that never completely match the
> actual data.  And how do I differentiate between true, false, and
> unspecified?  And of course, all of it means I *need* RDFS (and OWL),
> *everywhere*.  Why take such a huge dependency if you don't need to?

So if you have 8 boolean properties, you need a minimum of 8 classes (or 16
if you want to be able to distinguish between false and not known.) The fact
that you can create boolean combinations of those classes from those (i.e.
name classes for various combinations of those bits) - seems like a
strength, not a weakness - e.g:

You could get way with just:

ex:Male owl:disjointWith ex:Female.
ex:SinglePerson owl:disjointWith ex:MarriedPerson.

Or you could name some of the combinations:

ex:Husband owl:intersectionOf (ex:Male ex:MarriedPerson).
ex:Wife owl:intersectionOf (ex:Female ex:MarriedPerson).

(assuming traditional definitions)


-Geoff
Received on Wednesday, 16 March 2005 22:55:06 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:44:52 UTC