W3C home > Mailing lists > Public > www-archive@w3.org > January 2002

Re: Grist for layering discussion

From: Tim Berners-Lee <timbl@w3.org>
Date: Fri, 11 Jan 2002 16:58:12 -0500
Message-ID: <017801c19aeb$10d9b620$84001d12@w3.org>
To: <sandro@w3.org>, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: <phayes@ai.uwf.edu>, <hendler@cs.umd.edu>, <las@olin.edu>, <connolly@w3.org>, <w3c-semweb-ad@w3.org>, <www-archive@w3.org>

----- Original Message -----
From: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
To: <sandro@w3.org>
Cc: <phayes@ai.uwf.edu>; <hendler@cs.umd.edu>; <timbl@w3.org>;
<las@olin.edu>; <connolly@w3.org>; <w3c-semweb-ad@w3.org>;
<www-archive@w3.org>
Sent: Friday, January 11, 2002 9:16 AM
Subject: Re: Grist for layering discussion


> As it appears that some participants in this debate prefer an operational
> view of the situation, let me try to couch my comments in an operational
> setting.  (I believe that Pat would agree with the following, but I'm sure
> that he will speak for himself as well.)
>
> Suppose you want to build a representation formalism, like, say, RDF.  You
> design a syntax (and, maybe, an API) that lets you create information
bases
> and you specify a retrieval mechanism that lets you see what you have
> created.  SQL is a not-very-good example of such as retrieval
> mechanism for databases.  The retrieval mechanism wasn't really done for
> RDF, so lets just say that we can ask whether an information base contains
> a particular triple.
>
> Now you want to extend RDF.  OK, lets add mechanisms for creating a class
> taxonomy and for typing the domains and ranges of roles, and call it RDFS.
> We'll use the same syntax to create information bases, but modify the
> retrieval mechanism to make it correspond to the wording in the RDF Schema
> Candidate Recommendation.  Now you definitely get more out of the
> information base than you put in.  In particular, you get
>
> rdfs:Class rdfs:subClassOf rdfs:Resource .
>
> out of an information base that has not had any information added to it.

I would not expect that.  There is  a set of axioms from the RDFS spec which
you can put into any database but I see no reason why you should
assume them in any database.   For me, a database and a document are the
same.  Each is just a way of accessing some abstract information.
This way, you get a set of statements which every document is deemed to
include.
That is weird. I would prefer to say that any statement made in a document
which
uses OWL terms imples the semantics of the OWL spec, and therefore the
author is deemed to support the decutive closure of  the union of
the statements from his document and the axioms.

> So far so good.
>
> We have:
>
> 1/ All RDF syntax is also RDFS syntax.
> 2/ Given an RDF information base, i.e., an information base created using
>    only the syntax in RDF, the RDFS retrieval mechanism produces
everything
>    that the RDF retrieval mechanism would produce, and maybe more.

I would say, exactly the same.

> This is precisely what it means to be an extension.

Not for me. What you have in my view  is a new function, "answer this query
using the extra knowledge you have about DAML".  This will tell you a
superset of what you got out of the
plain query.

> However, RDF and RDFS have a very uncommon relationship because they also
> share a syntax.  Let's try to create a same-syntax extension of RDFS to
> encompass some of propositional logic, namely the part that allows us to
> create related disjunctions such as John is either married to Susan or
> friends with Jake.
>
> [Why do this extension in particular?  Well it is an extension that shows
> some of the problems, but it also has a construction that can be fairly
> naturally expressed as triples.]
>
> What doesn't work is to directly encode the missing logical
> construction.  A direct encoding of this would be something like
>
> IB1 John rdfo:or _:x .
> _:x married Susan .
> _:x friend Jake .

That is just nonsense of course.  You can't encode "or" as a conjunction
of triples.   DAML defines some prediates which allow you to do
similar things.  you can defien that the class of people married to the
Susan and the class of people friends of John are disjoint.


> We construct a formal specification of RDFO to incorporate this
> construction.

You can't.  You can define the meaning of a property  rdf:or but you can't
define it in a way which reaches up inside the machine and affects other
things.
You can only (1) give an algorithm for deducuing other information
from a statement and (2) give new axioms - constraints on the world - which
are related to the property. You can't say  "and if used in a sentence
it negates the meaning of the previous sentence" for example.

>  In particular, from
>
> IB2 John rdfn:or _:x .
> _:x married Susan .
>
> RDFO retrieval will produce
>
> John married Susan .
>
> Now is everything OK?  NO!  There are two problems:

No, it is not OK, you can't do that. DAML doesn't do that.

(N3's log:forSome and log:forAll do and they are not real RDF triples and
I must fix it so they don't appear to be in the syntax or the code. they
would have this problem if treated as such.)

[...]

> It is possible to overcome these problems, at least partly, by exploiting
> the reflective properties of RDF.  We can encode the disjunctions using a
> special construction, something like
>
> IB3 John rdfor:or _:l1 .
> _:l1 rdfor:fact _:f1 .
> _:l1 rdfor:rest _:l2 .
> _:l2 rdfor:fact _:f2 .
> _:l2 rdfor:rest rdfor:nil .
> _:f1 rdfor:predicate married .
> _:f1 rdfor:object Susan .
> _:f2 rdfor:predicate friend .
> _:f2 rdfor:object John .           [Jake?]

This is (with s/fact/first)    N3's   John rdfor:or  ( [ predicate married;
object Susan]
    [ rdf:predicate :friend; :object :Jake])

which is close to

   { :John :married :Susan } rdf99:or { :John :friend :Jake }.

which is very like

   { :John :married :Susan }  log:implies  { :John :notFriend :Jake }.

which works.

Now you can regard the {} as either an extension to the grammar of the
language, which I tend to do, or if you want to be strict and stick with RDF
you can use the construction above.  here it becomes I think
something like

:F1  rdf99:or :F2.
:F1  x:setOf  :L1.
:L1   daml:first :s1;    daml:rest daml:nil.
:s1 :rdf:Subject :John;  rdf:predicate :married; :object :Susan.
:F2  x:setOf  :L2.
:L2   daml:first :s2;    daml:rest daml:nil.
:s2 :rdf:Subject :John;  rdf:predicate :friend; :object :Jake.

# same as:

[ is x:setOf ( [:rdf:Subject :John;  rdf:predicate :married; :object
:Susan.])]
  rdf99:or
[ is x:setOf ([:rdf:Subject :John;  rdf:predicate :friend; :object
:Jake.])].


> Now retrieval for RDFOR can (probably) be designed so that
> 1/ All the extra consequences involve special the RDFOR constructs, and so
>    can be regarded as benign.

Before any deduction, yes.

> 2/ RDFOR is monotonic.

Yes.

> Have we succeeded?  Partly, but at three prices, two that show up right
> away and one that shows up in other extensions.
>
> The first price is that the construction is much more complicated than
> a syntax extension.

What does that mean?   You have made a construct which works in the abstract
space, which does not require a syntax extension.  More complicated?
Well, I suppose complexity is subjective. The simplicity is that the
abstract
space isn't changed.  You can then make some syntactic sugar to hide the
compexity of the construct in real files.


> The second price is that the construction adds a lot of extra
consequences.
> These consequences can be considered to be benign, but they are still
> there.  To make the formalism work correctly in the presence of these
> consequences requires a lot of work (and may not be possible, even here).

I suppose it consequences but they all involve the anonumous nodes F1, etc
used to set the thing up.  I don't see why making it work is so tricky.

> The third price is that we have introduced a form of reification and a
> construct that can assert the truth of reification constructs.  This
> (probably) doesn't cause any problems here because the extension is so
> expressively limited.  However, for more powerful extensions reification
> produces paradoxes, and thus cannot be used.

How do you mean "produces"?  Allows  one to write, or allows one to
deduce from the empty formula?

In N3,
{ this a :Falsehood }.

It is will always possible to write a paradox on the semantic web. It is
so importnat to be able to say what someone else is say is untrue that
one cannot help but be able to say that what one is saying is untrue.
That's life.  The question is whether the logic becomes unsound in that
any DAML system which includes :or can then be used to proove anything.

Being an amateur at this, I had understtod that Goedel's theorem anyway
demonstarted that in any system of any basic power must necessarily have a
sentence
which was paradoxical.  So avoiding expressing a paradox is a waste of time.

So you feel that allowing reification -- or, presumably, allowing
sets of statements as first class objects in the syntax -- makes the system
such that one can necessarily deduce a contradiction from nothing?
The I need help understanding how.

The normal way you do it relies on the Princple of the Excluded middle,
which of course cannot be part of the semnatic web.


> Why is there a problem?  The problem arises, as Pat has stated, from the
> attempt to extend a representation formalism while not extending the
> syntax.  This cannot be done in many circumstances and can only be easily
> done in very limited circumstances.

I need to understand better where the problem lies

>
> Peter F. Patel-Schneider
> Bell Labs Research
>
Received on Friday, 11 January 2002 16:59:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:15 GMT