W3C home > Mailing lists > Public > www-rdf-logic@w3.org > April 2001

RE: semantics status of RDF(S)

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Mon, 02 Apr 2001 13:29:36 -0400
To: danny@panlanka.net
Cc: www-rdf-logic@w3.org
Message-Id: <20010402132936T.pfps@research.bell-labs.com>
From: "Danny Ayers" <danny@panlanka.net>
Subject: RE: semantics status of RDF(S)
Date: Mon, 2 Apr 2001 22:43:42 +0600

> Are you in essence saying that for two parties to be able to communicate
> successfully that their statements must ultimately refer back to a common
> set of axiomatic definitions? and that RDF(S) should contain these but
> doesn't?

I would say that for successful communication to happen that there has to
be a shared definition of the statements transferred.  For example, if we
don't have a shared definition underlying the words and other syntactic
constructs in this mail message, then we haven't communicated anything.
The better this shared definition is, the better we can communicate.

Human beings are (by and large) amazing in that they can actually
communicate succesfully with only a partial, informal, broken shared
definition.  Of course we do end up in severe difficulties because of the
inadequacies of our shared definitions, but, by and large, we can, if we
try, overcome the difficulties.

I have very strong doubts that the agents that we can now
construct will be able to do as well with so poor a shared definition.  I
want to help our constructed agents by giving them a much better foundation
on which to build.  I believe that RDF(S), in its current form, does not
provide this firm foundation for the two main reasons I have given earlier.

> I can see in the two examples you give how this might be feasible - in the
> first case by providing a formal definition of negation within the schema or
> at a URI, and including 'our version equivalentTo that one' somewhere in the
> system. The second case seems a matter of dodgy wording ;-) But how much of
> an ultimate reference can RDF(S) represent? Surely there will always be
> things that are not formalised within RDF(S), so do you a) continually
> extend it to encompass these things as they arise, or b) use 3rd party
> extensions as required. Ok, so what's in RDF(S) now might need tightening
> up, but surely that will get done before too long, in advance of which
> what's wrong with using other formalisms, if necessary your own proprietry
> ones?

Formalizing the semantics of RDF(S) and fixing them where required will
make RDF(S) into a more-suitable vehicle for transferring information that
falls within its area of competancy.  However, RDF(S) is just not very
suitable for extension in the way that I think you are proposing here.  

The problems have to do with RDF's view of itself in the grand scheme of
things.  It is much easier to extend a modest formalism than it is to
extend one that wants to be able to represent everything.  For example,
suppose that we do provide a definition of negation in triples (because
everything is supposed to be triples) and use RDF as the encoding
mechanism.  We can then transfer negated statements via RDF, but RDF will
get in the way by providing its own (incompatible) meaning for the triples
that encode negation.  It would be much better if RDF would stay out of the
way, and not provide any meaning for these triples, but that is not within
the philosophy of RDF. 

The net result of all this is that if I want to transfer information that
is not expressible in the RDF view of the world I am technically much
better off if I completely ignore RDF and RDF(S), even if there is a firm
semantic foundation for RDF and RDF(S).  I don't have to fit
within the triple view of the world and I don't have to suffer from any
RDF-provided meaning for my constructs.

Peter F. Patel-Schneider
Bell Labs Research
Received on Monday, 2 April 2001 13:30:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:38 GMT