RE: Problems with dark triples approach

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