RE: Problems with dark triples approach

Hi Pat

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

Jeremy

Jeremy:
>
> >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
Pat:
> ...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.
Pat:
> ?? 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


<daml:Class
   rdf:ID="Elephant"
  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
Elephants.

Now, suppose I have a fairly general implementation of restriction so that I
want most of my restrictions to be implemented by
"com.hp.hpl.jena.daml.RestrictionHack"

(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:Restriction>
      <daml:onProperty rdf:resource="jena:JavaClass"/>
      <daml:hasValue>com.hp.hpl.jena.daml.RestrictionHack</daml:hasValue>
    </daml:Restriction>
  </daml:intersectionOf>
</daml:Class>


(triples)

<#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.

e.g.

<rdf:Description>
  <rdf:type>
    <my:HackableRestriction>
         <daml:onProperty rdf:resource="eg:prop"/>
         <daml:toClass rdf:resource="eg:class"/>
    </my:HackableRestriction>
  </rdf:type>
</rdf:Description>


If we use dark triples, then the dark triples

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

and

_: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
odd.



Jeremy

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