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.

I don't think it is, unless I wasn't following you.

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

Well, there are many ways. Drew McDermott has suggested one. My own 
favorite would be to use Sexpressions (maybe cobbled into XML to be 
fashionable) and map RDF triples (in something like N-triples form) 
into 3-lists. That provides a natural bridge between a KIF-style 
syntax and the RDF relational (ie property) interpretation. That 
would produce structures that wouldn't round-trip into RDF graphs, 
but that's life. There isn't a huge investment in RDF-graph handling 
code that couldn't be adapted quite smoothly to this extension, I 
suspect; it would have to produce something like Ntriples in order to 
serialize the graph in any case, and the Sexpression parsers could 
handle that.

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

Why in an RDF graph syntax? (What is so special about RDF? Its one 
among thousands of possible notations, and its not a particularly 
good one. The limitations of simple graphs as a notation have been 
known for about a century, so why would we want to deliberately go 
back to the stone age to find a basis for the world wide web?)

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

More dramatic still; using a completely different notation that has 
RDF as one special case.

>  I think DAML+OIL just
>adds vocabulary, which to me seems like option 3, although the style
>is still a bit different.

Yes, this is more radical than DAML+OIL. DAML was distorted to make 
it fit onto RDF, and I want to get rid of the distortions.

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

Turing machines are easier than Towers of Hanoi. (BTW, do you know 
the non-recursive ToH algorithm? Its real easy. Every alternate move 
moves the smallest disc; the other moves are forced. To get an 
optimal solution, never move the smallest disc to the peg it last 
came from: that forces every move. )

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

And Java can? You can't have it both ways. Either you have slow naive 
processors or smart users who write fast code, whether you are doing 
logic or not.

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 Saturday, 13 October 2001 00:20:01 UTC