How do RDF and Formal Logic fit together?

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:26 UTC