- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Thu, 18 Apr 2002 12:56:22 -0500
- To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
- Cc: www-webont-wg@w3.org
>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