Re: How do RDF and Formal Logic fit together?

> >(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.
> 
> Why bother? The RDF graph is cute, but its not the holy grail.

Good question.    I kind of like the RDF's non-syntax syntax, but it
can be a pain, too.   

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

That's what I was calling option 2.

Let me try to pose the question a little differently.  Something we
might like to add to RDF, to make it more expressive, is logical
negation.   How would you extend RDF's syntax to handle it?  Using the
same numbering, do you:

1) Throw out the Directed Labeled Graph syntax.  When you start trying
   to negate a graph, it gets pretty nuts.

2) Use n3's approach:   { :sandro :knows :everything } a log:Falsehood.
   This approach relies on extending RDF to have nesting, which is
   probably throwing out DLGs, too.   To stay in the RDF Graph, it
   needs reification, or something else perhaps too contorted to count
   as RDF.

3) Lay on another language, which is interoperable with RDF.  Say "(not
   (RDF :sandro :knows :everything))" in an RDF graph syntax.   That
   is, define a few RDF vocabulary terms, and use them.  It might look
   like
        :s1 L2:truth l2:true .   # assert the L2 expression :s1, in RDF
	:s1 L2:negation :s2 .
	:s2 L2:rdfNamedSubject :sandro .
	:s2 L2:rdfNamedPredicate :knows .
	:s2 L2:rdfNamedObject :everything .
   which looks kind of like reification and has the "truth" function,
   but can perhaps be managed because of the wall between the two
   languages.  That is, RDF has 5 sentences here, L2 has 2 sentences
   (called :s1 and :s2), and the L2:truth sentence says that an RDF/L2
   processor should load its knowledge base with :s1, in addition to
   the 5 RDF sentences.  I think the wall consists mostly of the rule
   that you don't look for more L2: stuff in what you infer.

So when you say "extending" do you mean adding new vocabulary terms or
something more dramatic, like adding nesting?  I think DAML+OIL just
adds vocabulary, which to me seems like option 3, although the style
is still a bit different.  

> >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.
 
Could be.   Has anyone written Towers of Hanoi in DAML+OIL?   I can't
figure out where you'd start.  Would you get your output by querying
class/instance relationships?   I thought DAML+OIL was decidable and
that meant it couldn't be Turing complete, but it sounds like I might
just be in over my head.

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

But AFAIK most prologs can't really be used naively.  You need to
order the terms in your clauses (and probably even use cuts) to get
decent performance and to avoid loops.  Tabled prolog solves some of
these problems.  I haven't done enough side-by-side comparison of XSB
and C code to see how it really comes out.

> Like I said, watch this space.

Of course.  :-)

   -- sandro

Received on Tuesday, 9 October 2001 04:53:53 UTC