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

Re: rdf as a base for other languages

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Sat, 02 Jun 2001 08:49:16 -0400
To: GK@ninebynine.org
Cc: sandro@w3.org, www-rdf-logic@w3.org
Message-Id: <20010602084916R.pfps@research.bell-labs.com>
From: Graham Klyne <GK@ninebynine.org>
Subject: Re: rdf as a base for other languages
Date: Sat, 02 Jun 2001 05:46:28 +0100

> At 01:07 PM 6/1/01 -0400, Peter F. Patel-Schneider wrote:
> >From: Sandro Hawke <sandro@w3.org>
> >Subject: Re: rdf as a base for other languages
> >Date: Fri, 01 Jun 2001 12:22:51 -0500
> >
> > > In message <20010601115102E.pfps@research.bell-labs.com> you wrote:
> > > > Unfortunately RDF only has triples, so triples end up being used for both
> > > > the ground facts and the more-complex information.  RDF has no way of
> > > > distinguishing between these differing uses of triples, so any 
> > triples that
> > > > are used to store the more-complex information are also asserted as facts
> > > > by RDF.  Worse, ....
> > >
> > > The "more-complex information" is stored by being described with ground
> > > facts.  What's wrong with that?   Where is the confusion?
> > >
> > > The only potential for confusion I see is that some people might want
> > > to jump from having a triple described (with ground facts) to assuming
> > > the described triple is true, but that seems clearly wrong.
> >
> >Clearly wrong, but RDF mandates that all triples are in the model.  If you
> >believe that the model is a representation of some information, then you
> >want these triples to be true.  If you don't believe that the model is a
> >representation of some information, then what are you using RDF for?
> >
> >For example, suppose that you wanted to represent propositional formulae
> >within RDF.  You might do something like:
> >
> ><rdf:type x OR>
> ><component x y>
> ><component x z>
> >
> ><rdf:type y rdf:Statement>
> ><rdf:subject y John>
> ><rdf:predicate y loves>
> ><rdf:object y Mary>
> >
> ><rdf:type z rdf:Statement>
> ><rdf:subject z John>
> ><rdf:predicate z loves>
> ><rdf:object z Susan>
> >
> ><loves Bill Susan>
> >
> ><rdf:type Bill Person>
> ><rdf:type John Person>
> ><rdf:type Susan Person>
> ><rdf:type Mary Person>
> >
> >You understand this collection of RDF triples to mean that Bill loves
> >Susan and John loves either Mary or Susan, and that they are all people.
> Actually, I don't, because I don't know the semantics associated with data 
> type "OR".  Base RDF doesn't allow us to make this kind of statement.  But 
> I guess that's your point.

Sorry, by the ``you'' above I meant some agent who was in on the encoding
scheme, as opposed to a simple RDF agent.

> My point:  why cannot the "extra" semantics be attached to a particular 
> value -- in this case, "OR"?

Sure you can do this, but where would you stop?  In particular, if you
wanted to have propositional or predicate logic, almost all information
transmitted would use these special resources.  This, in my view, is no
longer RDF.  Sure it uses RDF as a transfer mechanism, but just in the same
way that it uses XML or unicode as a transfer mechanism.

> [...]
> >Sure, you can do anything you want outside of RDF.  However, if you want
> >RDF to represent anything, you better do all your work within RDF.
> Why the insistence on all-or-nothing?  Is there any fundamental reason why 
> we cannot start with a language capable of expressing ground facts, and 
> extend it in a consistent way (creating a new language, "outside" the 
> original) such that the original language for expressing ground facts is 
> present as a sub-language?

Because then you no longer have RDF.  Suppose we are talking about
programming languages, and we decide that 360 Assembler is the way to go.
A group of us, however, decide that we will add recursive functions (for the
sake of argument let us assume that 360 Assembler does not have recursive
functions, I think that this is the case but it has been so long since I
programmed in 360 Assembler that I might be wrong).  Can we continue to
call our language 360 Assembler and claim that 360 Assembler is now a more
powerful language?   (Note that in a certain sense we have changed the
power of the language, as without OS memory management calls 360 Assembler
is only a finite-state machine language, but our new language is not.)

Similarly, there is no reason that you cannot have a language that can
express ground facts, and embed it in a different language that can express
more.  However, the meaning of this larger language is quite different from
the meaning of the smaller language.  (Consider how you would handle
``facts'' with variables in them---you can't just use the meaning from the
smaller language, as it has no idea how to interpret the variables.)

Further, even this is different from having a language for expressing
ground facts (RDF), encoding more-complex constructs in this language, and
using the ground facts language as the transfer mechanism.  Under this
scheme, the encoding of the more-complex constructs are still viewed as
ground facts, and end up becoming part of their meaning, which is not desired.

> #g
> ------------
> Graham Klyne
> GK@NineByNine.org

Received on Saturday, 2 June 2001 08:50:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:35 UTC