Re: 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?

While this is a fascinating topic, is it directly relevant to RDF-rules?

>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.

That seems to me to be obviously the right way to go, but it has to 
be done right. We have now a single model-theoretic framework that 
covers KIF, RDF and DAML uniformly (damn nearly...). Seems like a 
good time to try to fix a standard. Watch this space.

>
>(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.

Why bother? The RDF graph is cute, but its not the holy grail.

>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,

Wait. You have missed out the obvious (seems to me) option, which is 
to *extend* RDF to a more expressive logic while keeping RDF as a 
special subcase of that more expressive logic. It doesn't need much 
extra syntax to get full FOL with knobs on. That gives just the kind 
of backwards compatibility that one would want, since a more powerful 
reasoner would be able to draw all the same conclusions that an RDF 
reasoner would be able to draw from the same RDF (and maybe some 
more, though in fact I think not if it only had pure RDF as input.). 
That is what DAML+OIL does, and it is really what N3 does as well.

>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.

I think you are confusing two different ideas. DAML+OIL probably is 
Turing-complete already. It can describe lists which can get 
arbitrarly long. Once you have unbounded datastructures, it doesn't 
take much to achieve Turing completeness. That has nothing to do with 
expressivity.

>Why use a logic language instead of, say, Java byte code?  Java (as
>slow as it is!) would certainly run faster.

Are you sure? Modern prologs run *very* fast.

>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?

Like I said, watch this space.

Pat Hayes


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Monday, 8 October 2001 21:44:07 UTC