- 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