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,

Well, there is a problem with that, since the axiomatic semantics 
doesn't agree with the RDF MT. But leave that aside.

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

OK, fine. That follows from the DAML (not RDF) semantics of 
daml:intersectionOf, right? That will be exactly as it is now, so all 
your inferences will work fine. However, those RDF triples also say 
some other things. They say that a mysterious thing exists (which is 
of type daml:List) which bears some mysterious relationship 
(daml:intersectionOf) to your <#HackableRestriction>, for example. 
That isn't the same as the DAML relationship called intersectionOf, 
just to emphasize, because that is between one class and some other 
classes, not between a class and a *list*. So now you have two 
different relationships being asserted by those triples, one provided 
by the RDF MT and one provided by the DAML MT, and they are 
different. Not much is known about the former, by the way, but it is 
asserted by the RDF, so it must be asserted by the DAML as well, if 
we adopt a straightforward picture of layering on the RDF/RDFS model.

Now, one can take several different views on this. Dan Connolly is 
quite happy to have these odd lists in his world. I am not, myself, 
and it seems to me that they don't belong there: I see that DAML as 
saying something about an intersection relation between classes, not 
about a list. It *uses* the list to encode what it wants to say about 
the classes, and putting those lists in the domain is a use/mention 
confusion. So I would like to darken all those triples that talk 
about lists (triples 2 through 6 in your Ntriples document above.) 
That doesn't alter the DAML meaning of that document, but it does 
remove the semantic clutter that the RDF meaning insists on putting 
into the interpretation. Then it means what I suspect you want it to 
mean, viz. exactly what the XML seems to say. Right now it DOESNT 
mean that: it means that plus a lot of other things. Some of those 
other things are what cause Peter's semantic paradoxes, but the 
general point applies even when there  is no explicit paradox. For 
example, do you *really* want your XML document to entail

<#HackableRestriction> <daml:intersectionOf> _:x .
_:x <daml:rest> _:y .
_:y <daml:rest> <daml:nil> .

? What on earth does that mean?  What has your HackableRestriction 
got to do with something called daml:nil? Nothing at all, I would 
submit. And does it really make sense to say that the relationship 
between <#HackableRestriction> and <jena:JavaClass> is not direct, 
but is only mediated by a three-step relational chain involving the 
property <daml:rest> ; particularly when that same relation is 
apparently what connects every other intersection class with the 
classes that it is the intersection of? If you didn't know that this 
stuff about lists was just a syntax encoding hack, you would find 
this very peculiar.

You probably don't think of it this way, because you 'automatically' 
see the daml:list triples as not really having *semantic* content, 
but just as a way to encode the higher-level language into triples. 
Its not really talking ABOUT lists, right? (Lists aren't mentioned 
anywhere in the XML version, for example.) And I agree: but the point 
is that at present it DOES have all that unwanted semantic content. I 
just want to be able to turn it off, is all.

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

No, it hasn't changed at all. The proposal won't change the intended 
meaning of OWL one iota, it just frees it from a lot of unintended 
extra clutter caused by the syntax layering.

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

Well, maybe, but that's another topic altogether.

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 18 April 2002 13:56:32 UTC