- From: Geoff Chappell <geoff@sover.net>
- Date: Sun, 17 Jun 2001 10:01:16 -0400
- To: <www-rdf-logic@w3.org>
- Message-ID: <00df01c0f735$fa64a0c0$835ec6d1@goat>
Hi folks,
I've been working with expressing inference rules in daml and need a little help/feedback.
It seems that rules with just the subject unbound can be expressed easily.
For example the rule:
type(X,animal)<-type(X,dog)
can be expressed as:
type(X,animal) or not(type(X,dog))
or in daml:
<unionOf parseType="daml:collection">
<Class>
<Restriction>
<onProperty rdf:resource="rdf:type"/>
<hasValue rdf:resource="animal"/>
</Restriction>
</Class>
<Class>
<complementOf parseType="daml:collection:>
<Class>
<Restriction>
<onProperty rdf:resource="rdf:type"/>
<hasValue rdf:resource="dog"/>
</Restriction>
</Class>
</complementOf>
</Class>
</unionOf>
You can of course join a number of rules together with an intersectionOf. In the end all you have done is define a class. How would you actually assert the rules? by asserting that all things are members/instances of that class?
What about rules with the object (and subject) unbound?
For example a transitive rule of isa-ness might be defined as:
isa(A,C)<-isa(A,B) and isa(B,C)
or
isa(A,C) or not(isa(A,B)) or not(isa(B,C))
what is the daml equivalent? here's an attempt -- not sure if it pulls off what I'm trying to do...
<unionOf parseType="daml:collection">
<Class>
<Restriction>
<onProperty rdf:resource="isa"/>
<toClass rdf:resource="C">
</Restriction>
</Class>
<Class>
<complementOf parseType="daml:collection:>
<Class>
<Restriction>
<onProperty rdf:resource="isa"/>
<toClass rdf:resource="B">
</Restriction>
</Class>
</complementOf>
</Class>
<Class>
<complementOf parseType="daml:collection:>
<Class rdf:ID="B">
<Restriction>
<onProperty rdf:resource="isa"/>
<toClass rdf:resource="C">
</Restriction>
</Class>
</complementOf>
</Class>
</unionOf>
What about rules with the predicate unbound? seems like those might be a problem since the range of onProperty is an object/property (not a class). I suppose the only types of rules you might want to define in this case would be things like transitivity -- which are dealt with in the language already.
Assuming you wanted to translate the daml "rules" back into your language of choice (i.e. just use daml for serialization/interchange of rules), additional information is necessary to preserve any information about how the rule should be applied efficiently (and with original intent). for example:
a<- not(b) and not(c) becomes a or b or c as a daml rule.
which could be interpreted as any of the following:
a<-not(b) and not(c)
b<-not(a) and not(c)
c<-not(a) and not(b)
a or b <- not(c)
etc.
Since the collections are unordered, you can't really establish a convention that the first term/class defines the head of the rule/consequent. Has anyone dealt with this yet?
Thanks for any corrections/comments/feedback.
Geoff
Received on Sunday, 17 June 2001 11:35:41 UTC