- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 05 Oct 2001 14:47:25 -0400
- To: www-rdf-rules@w3.org, www-rdf-logic@w3.org
RDF is a weak knowledge representation language. When we want to say something with a very simple logical structure ("Luke's father is Anakin"), we can say it directly with RDF Statements. If we want to say something with a more complex logical structure ("The force is strong with *everyone* in Luke's family"), we can't use RDF as the only language. We need all parties to understand a different language. How might such a language relate to an RDF graph? How might such a language be backwards compatible with current RDF data and current RDF tools? Do we need a new model theory for a new type of structue (which might not be a di-graph), along with new encoding languages, successors to RDF/XML and RDF/N-Triples? Some options: (1) Handle compatibility via converters and basically start fresh. RDF2 = KIF2, or something. This is appealing, but getting consensus could be very hard, and the RDF1 community might not view the outcome as a worthy successor. (2) Try some small tweaks to the model theory and the syntaxes which are compatible, or at least fail in graceful ways. Tim's adding parseType="quote" and the n3 logic vocabulary terms is an attempt in this direction, I think. The failure mode here is that parsers will abort when they encounter the unknown parseType (which is required for most (all?) advanced language features). I'm not sure one can do better; to ignore the extra data might be worse. (3) Make up another logic language (eg first order logic) and encode it in the RDF graph. Something like this is tedious but workable: # property(?Person, inFamilyOf, Luke) # --> property(?Person, strengthOfForce, Great, ) _:a <type> <Implication> . _:a <antecedent> _:b . _:a <consequent> _:c . _:b <type> <PropertyStatement> . _:b <subjectVariable> <Person> . _:b <propertyConstant> <inFamilyOf> . _:b <valueConstant> <Luke> . _:c <type> <PropertyStatement> . _:c <subjectVariable> <Person> . _:c <propertyConstant> <strengthOfForce> . _:c <valueConstant> <Great> . There are lots of logical notations one could use, of course. An agent reading RDF is then free to (or required to) extract the encoded logical formulas and add them to its knowledge base. I've done some experiments like this. There's some odd (dangerous) self-reference possible if you consider the RDF1 logic and the higher-layer logic to be describing the same world. In this example RDF1 is talking about Implications and PropertyStatements (the syntax of the stronger logic language), while that language is talking about Luke and his family. For backwards compatibility, I think we need RDF1 to be able to talk about Luke, too, but we probably have to forbid the more expressive language from talking about its own syntax. That seems doable from here. Trying to decide which road to go down, I go back to wondering why we want RDF Logic. There's the whole area of documentation, validation, etc, which seems to be the focus of DAML+OIL. That work tries to be helpful while keeping the language not just decidable but always tractable. I think a lot of us want to let go of that constraint, to go for a language which is at least Turing complete. We want to be able to have semantic web pages be little programs (like HTML pages with javascript, but cleaner). We want to be able to validate a date field or do currency conversion, etc, etc. Why use a logic language instead of, say, Java byte code? Java (as slow as it is!) would certainly run faster. My guess is that the right thing to do is both. Provide a logical formula which constrains the behavior of a program, and allow any program to be run which is proven (or claimed, in some circumstances) to meet those constraints. Trivial programs, like date validation, could probably be handled by an automated theorem prover. More complex ones written in a conventional language and proven compliant with machine assistance. But perhaps now I'm off in never-never land. Why do *you* want something more expressive than RDF1 and how do you think we should get there? (There's a simpler, related kind of "RDF logic", in which you're not concerned about transmitting the logic, just using it with your own tools to help you manage RDF data. Bijan Parsia's article on RDF with Prolog [1] is along these lines.) (Please forgive the cross post; this is coming out of discussions on rdf-rules, but seems rather relevant for rdf-logic, too.) -- sandro [1] http://www.xml.com/pub/a/2001/07/25/prologrdf.html
Received on Friday, 5 October 2001 14:47:25 UTC