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