- From: Jeff Thompson <jeff@thefirst.org>
- Date: Tue, 25 Mar 2008 22:03:01 -0700
- To: Tim Berners-Lee <timbl@w3.org>
- CC: cwm talk <public-cwm-talk@w3.org>, Benjamin Grosof <bgrosof@mit.edu>
Thanks for the reply. I'll ask my question in N3 code with comments...
# Suppose you have a functional property:
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@keywords is, of, a.
inventor a owl:FunctionalProperty.
# and you have two different assertions using this property:
VintCert says {WorldWideWeb inventor TimBernersLee}.
BillClinton says {WorldWideWeb inventor AlGore}.
# which assert different results so that FunctionalProperty should not merge them:
TimBernersLee owl:differentFrom AlGore.
AlGore owl:differentFrom TimBernersLee.
# I assume you are saying that you could prioritize:
VintCert moreTrustedThan BillClinton.
# so that you could have a rule to resolve the conflict:
@forAll :s, :p, :o1, :o2.
{?source1 says {:s :p :o1}.
?source2 says {:s :p :o2}.
:o1 owl:differentFrom :o2.
:p a owl:FunctionalProperty.
?source1 moreTrustedThan ?source2.} => {:s :p :o1}.
Using --think in cwm, as expected this gives only one conclusion:
:WorldWideWeb :inventor :TimBernersLee.
Is this how you would handle prioritizing conflicting functional properties?
Has someone worked up a rule suite along these lines?
Thanks for any help,
- Jeff
Tim Berners-Lee wrote:
> Jeff,
>
> I have always held out for the design goal that two sets of rules, each
> of which is useful in its own local domain, can be combined into a large
> set. This requires monotonicity. Ben Grosof and I have argued about
> this for years, as his systems (like sweetjess) typically rely on the
> sort of prioritization you describe. In fact, if you have a given set
> of the rules with priorities you can always compile them down to a
> nested expression in monotonic logic. the problem is in an open world
> like the web, you never know all the rules. In a non-mon world, you
> can't really do anything as you don't know if somewhere something might
> be out-prioritizing you. So long as you exlictly close the world, by
> saying which data sources and rulesets are relevant, then you can talk
> about defaults and priorities - and negation as failure. We have called
> this 'scoped' negation as failure.
>
> Tim
>
> On 2008-03 -22, at 14:08, Jeff Thompson wrote:
>
>>
>> Has there been any thought about resolving conflicting conclusions in
>> N3 Rules?
>> This paper makes a good case for defeasible logic which lets you
>> prioritize rules
>> which may produce conflicting conclusions.
>> http://iskp.csd.auth.gr/publications/DKE-Kontopoulos.pdf
>>
>> Specifically, has there been thought of a non-monotonic version of
>> log:implies
>> which allows a superiority relation among rules?
>>
>> - Jeff
>>
>
>
>
>
Received on Wednesday, 26 March 2008 05:03:36 UTC