- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Thu, 18 Apr 2002 10:18:34 -0400
- To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>, "Pat Hayes" <phayes@ai.uwf.edu>
- Cc: <www-webont-wg@w3.org>
Jeremy's example below, or similar things in other domains, are a common thing I've seen done - if dark triples has the side effect of making this impossible (or even just more difficult) than I think our support for these may need some rethinking. I was assured at the f2f that the DTs would not interfere w/any of our requirements - not sure if what Jeremy describes is directly in our requirements, but it is certainly something used in the various collection management use cases - so we'd better be sure we're not breaking anything we require. -JH At 2:59 PM +0100 4/18/02, Jeremy Carroll wrote: >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 -- Professor James Hendler hendler@cs.umd.edu Director, Semantic Web and Agent Technologies 301-405-2696 Maryland Information and Network Dynamics Lab. 301-405-6707 (Fax) AV Williams Building, Univ of Maryland College Park, MD 20742 http://www.cs.umd.edu/users/hendler
Received on Thursday, 18 April 2002 10:22:21 UTC