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

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>

Received on Friday, 11 October 2002 12:33:25 UTC