- From: Tim Berners-Lee <timbl@w3.org>
- Date: Tue, 6 Mar 2001 23:25:19 -0500
- To: <jos.deroo.jd@belgium.agfa.com>, "Sandro Hawke" <sandro@w3.org>
- Cc: <www-rdf-logic@w3.org>, <www-rdf-interest@w3.org>
> My approach (not yet implemented) is much more explicit: conclude > (instead of a literal) something like "this engine could not satisfy > this proof", which I can't think of how to express in n3 right now. > "This engine" is an identifier for the running process which tried to > find the proof, and "this proof" is an identifier for the proof > requested. or something like that. This requires a model of the knowledge in the engine at a given time. I was thinking along the lines of followsFromUsingXXXReasoning(expression, document) where document is the source of information, and expression is the thing proved. "says" is a specific form of XXX involving only subetting the outermost conjunction of a formula (subgraphing and RDF graph) </etc/passwd.rdf> log:says { :<#timbl> unix:inGroup <#www> } . means that the file contains at the top level the assertion. By contrast, <~/calendar.rdf> log:impliesByFPC { :i a cal:OverCommittedPerson } . means that there is a forst order proof of the conclusion from the evidence in the document. Now you can be specific about negation </etc/passwd.rdf> log:doesntSay { :<#timbl> unix:inGroup <#www> } . we can state a default in a well defined way: { </etc/passwd.rdf> log:doesn'tSay { :x unix:inGroup :y } } log:implies :x unix:inGroup <#others> } . tim
Received on Tuesday, 6 March 2001 23:25:37 UTC