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