W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2002

Re: On equivalence of tidy/untidy (was: Re: Reopening tidy/untidy decision)

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Fri, 11 Oct 2002 19:19:06 +0100
Message-Id: <5.1.0.14.2.20021011191717.039b3040@127.0.0.1>
To: "Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>
Cc: w3c-rdfcore-wg@w3.org

Er, yes, I didn't think of that.

Now that you mention it, I could imagine a short-ish Concepts section on 
"entailment".

I'll give it some thought.

#g
--

At 06:32 PM 10/11/02 +0200, Jos De_Roo wrote:

>Graham, I would propose to put some of your text
>here in one or the other documents as foundation
>
>-- ,
>Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
>
>
> 
>
>                     Graham 
> Klyne 
>
>                     <Graham.Klyne@MIMEsw       To:     Sergey Melnik 
> <melnik@db.stanford.edu>
>                     eeper.com>                 cc: 
> w3c-rdfcore-wg@w3.org
>                     Sent by:                   Subject:     Re: On 
> equivalence of tidy/untidy (was: Re: Reopening
>                     w3c-rdfcore-wg-reque        tidy/untidy 
> decision)
>                     st@w3.org 
>
> 
>
> 
>
>                     2002-10-11 01:15 
> PM 
>
> 
>
> 
>
>
>
>
>
>
>Sergey, I'm going to focus on one tiny bit of your message because I think
>it may underlie your other concerns:
>
> >Tidy/untidy as a requirement that we are about to put into the spec. What
> >I find disturbing and disappointing, given the amount of effort we
> >inversted, is that compliance with this requirement apparently cannot be
> >verified.
>
>While I think I understand your point, I don't entirely concur with your
>conclusion of futility.
>
>Yes, given an implementation of RDF it is not in general possible to
>confirm compliance with this entailment aspect of the RDF spec.  BUT... it
>would be possible to detect certain non-compliances.
>
>So, if we give an RDF engine the following, and nothing else:
>
>    ex:Tail ex:partOf ex:Dog .
>    ex:Dog ex:wags ex:Tail
>
>and the RDF application returns this:
>
>    ex:Tail ex:wags ex:Dog .
>
>we can say, I believe quite conclusively, that the returned value is NOT
>RDF-entailed or RDFS-entailed by the input.  OTOH, we can say the following
>
>expression:
>
>    _:x ex:partOf ex:Dog .
>    ex:Dog ex:wags _:x .
>
>*IS* RDF-entailed by the input.
>
>Furthermore, this is testable;  i.e. given an RDF application that takes
>some input and generates some output together with a "proof", it is
>possible to test whether or not the output and proof taken together
>represent a legitimate RDF- or RDFS-entailment from the given input.
>
>Now this may be a tiny step, but I believe an important one that sets RDF
>apart from being just another data format like XML.  And I think it's
>important to be clear where literals stand in all this.  The very idea of
>generalized entailment, however weak it may be, is one that I've not seen
>in any other Internet standard.  The RDF specification is saying that there
>
>are conclusions that an application is entitled to draw from some input.
>
>In my view, once we get past understanding how to use RDF as a
>general-purpose data format, we'll find that a little bit of inference goes
>
>a long way.
>
>#g
>--
>
>
>At 05:06 PM 10/10/02 +0200, Sergey Melnik wrote:
>
> >Sorry for delay in replying.
> >
> >I think I drifted too much towards comparing the semantics of RDF
> >statements to that of query languages. The latter is expressed in terms of
>
> >what language expressions do to data structures, a much simpler world than
>
> >model theory. You are of course right in that entailment is a "semantic"
> >relationship if the structures we talk about are model-theoretic
> >interpretations.
> >
> >Tidy/untidy as a requirement that we are about to put into the spec. What
> >I find disturbing and disappointing, given the amount of effort we
> >inversted, is that compliance with this requirement apparently cannot be
> >verified.
> >
> >Furthermore, whether we interpret those untyped literals as "values" or
> >"string literals" seems irrelevant. These entities cannot be used as
> >subjects, they cannot even be referred to (more than once) in the same
> >document, let alone across documents and applications. So who cares what
> >they denote? The controversial entailment is even less worldshaking...
> >
> > From the practical standpoint, most of our discussion dealt with whether
> > we use one node or two nodes, whether those nodes have systemIDs or not,
> > etc. These are all important API design issues. However, they are
> > orthogonal to (un)tidiness understood in terms of the questionable
> > entailment; apps can draw tidy conclusions using untidy APIs and the
> > other way around. In other words, if we go for untidy *entailment*, there
>
> > is no reason to modify existing tidy APIs. Therefore, I personally do not
>
> > care much about the outcome of the debate.
> >
> >Our problem might have been that we did not define the issue precisely, as
>
> >Frank pointed out several times. We have two syntaxes, RDF/XML and the
> >abstract syntax. We are talking about the model-theoretic semantics of the
>
> >RDF/XML syntax in terms of the model-theoretic semantics of the abstract
> >syntax. We are designing two mappings and one data model (abstract syntax)
>
> >and the same time, screwing on all three at once. That's an excellent
> >source of confusion.
> >
> >Sergey
> >
> >
> >
> >Graham Klyne wrote:
> >
> > > At 10:24 AM 10/1/02 +0200, Sergey Melnik wrote:
> > >
> > >> Our problem is that the entailment capability is *not* part of RDF
> > >> spec.    If it were, then we could define formally what the result of
> > >> entailment should be, applied to graphs. However, we do not require
> > >> each and every RDF application to support entailment (thanks God).
> > >
> > >
> > > Entailment *capability* may not be part of the RDF spec, but certain
> > > allowable entailments *are*.  The fact that RDF permits certain
> > > entailments is not the same as saying RDF requires applications to
> > > deliver those entailments.
> >
> >
> > >> Recall that entailment is a syntactic procedure, more precisely, a
> > >> binary relation that holds between syntactic sentences (graphs, in our
> > >> case).
> > >
> > >
> > > ?!?  I thought entailment was precisely a *semantic* relation, defined
> > > in terms of truth of expressions (graphs) (which I grant are syntactic
> > > entities) under any interpretation.
> >
> >[...]
> >
> > > But I agree that we don't require all applications to find all valid
> > > entailments.
> > >
> > > In fact, I don't think we require applications to do anything (though
>it
> > > is sometimes convenient to describe aspects of RDF by characterizing
>our
> > > expectations of applications -- I thought the whole idea of the formal
> > > semantics was to be able to nail down RDF meaning without having to
> > > describe applications).
> > >
> > > #g
> > >
> > >
> > > -------------------
> > > Graham Klyne
> > > <GK@NineByNine.org>
> > >
> > >
>
>-------------------
>Graham Klyne
><GK@NineByNine.org>

-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Friday, 11 October 2002 15:08:26 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:52:24 EDT