W3C home > Mailing lists > Public > www-webont-wg@w3.org > April 2002

RE: Problems with dark triples approach

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Thu, 18 Apr 2002 14:59:48 +0100
To: "Pat Hayes" <phayes@ai.uwf.edu>
Cc: <www-webont-wg@w3.org>
Message-ID: <JAEBJCLMIFLKLOJGMELDMELICDAA.jjc@hplb.hpl.hp.com>
Hi Pat

it seems that I was unclear in part. Here's some of my text and your text,
followed by a new example.


> >The motive was that the ontology I was creating was to represent the
> >conceptualization of e-mail in Microsoft's Outlook product and I
> wished to
> >extend the DAML+OIL mechanisms
> ...why do you call this 'extend' ? Seems to me you were just *using*
> DAML+OIL, not extending it. DAML allows you to define new classes and
> properties freely, that isn't doing any extending.
> >to include OLE mappings for the properties.
> >
> >From the point of view of computer science this seems a logical
> and natural
> >thing to do; and a functionality that I hope that OWL can support.
> Right, any assertional language would.
> >
> >From the point of view of the semantic web I see extensibility in all
> >possible directions as being a fundamental design obligation.
> >
> >This relied on *semantic* mechanisms such as subPropertyOf and
> subClassOf.
> ?? Why do you call these 'semantic'? They are just part of the
> language. Of course they have a semantics, but so does the rest of it.
> >
> >If the semantics of OWL is defined directly on top of the graph
> syntax then
> >this does not work. Rather, to have this work, we would need the
> conditions
> >on an OWL interpretation to be essentially semantic constraints, like the
> >additional constraints on RDFS interpretations in Pat's RDF Model Theory.

Let's suppose I am extending classes in daml with a property jena:javaClass
(where jena is same namespace). e.g. I expect to have

  jena:JavaClass="com.hp.hpl.jena.example.Elephant" />

(Sorry you don't like XML)

<#Elephant> <rdf:type> <daml:Class> .
<#Elephant> <jena:JavaClass> "com.hp.hpl.jena.example.Elephant".

My application may be using this to use special code that knows about

Now, suppose I have a fairly general implementation of restriction so that I
want most of my restrictions to be implemented by

(Special code that knows about most retrictions).

I can define a new class as the intersection of daml:Restriction and those
things whose jena:JavaClass is "com.hp.hpl.jena.daml.RestrictionHack".

e.g. (I think I'll do this in XML first)

<daml:Class rdf:ID="HackableRestriction">
  <daml:intersectionOf rdf:parseType="daml:collection">
    <daml:Class rdf:resource="daml:Restriction"/>
      <daml:onProperty rdf:resource="jena:JavaClass"/>


<#HackableRestriction> <rdf:type> <daml:Class> .
<#HackableRestriction> <daml:intersectionOf> _:list .
_:list <rdf:type> <daml:List> .
_:list <daml:first> <daml:Restriction> .
_:list <daml:rest> _:tail.
_:tail <daml:rest> <daml:nil> .
_:tail <daml:first> _:restriction .
_:restriction <daml:onProperty> <jena:JavaClass> .
_:restriction <daml:hasValue> "com.hp.hpl.jena.daml.RestrictionHack".

If we follow the way RDFS model theory works (no dark triples), and the way
that the axiomatic semantics for DAML+OIL work, then I can use my new class
HackableRestriction wherever I may have used daml:Restriciton.
It will be implicitly recognised as a daml:Restriction, and I can tell which
java class I need to use to implement it etc.


         <daml:onProperty rdf:resource="eg:prop"/>
         <daml:toClass rdf:resource="eg:class"/>

If we use dark triples, then the dark triples

_:foo <rdf:type> <my:HackableRestriction> .


_:foo <rdf:type> <daml:Restriction> .

are unrelated, and my ability to specialise the language for my purposes has
been diminished.

I hope this is clearer.

Seriously: the first time I looked at daml I read it as allowing me to do
this sort of thing, and so I did do this sort of thing. I might be kindof

Received on Thursday, 18 April 2002 10:00:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:43 UTC