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: Sergey Melnik <melnik@db.stanford.edu>
Date: Thu, 10 Oct 2002 17:06:42 +0200
Message-ID: <3DA59782.80704@db.stanford.edu>
To: Graham Klyne <Graham.Klyne@MIMEsweeper.com>, Jos De_Roo <jos.deroo.jd@belgium.agfa.com>
CC: w3c-rdfcore-wg@w3.org

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>
 >
 >
Received on Thursday, 10 October 2002 11:06:46 EDT

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