- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Fri, 11 Oct 2002 19:19:06 +0100
- 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 UTC