RE: RDF specifications

From: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Subject: RE: RDF specifications
Date: Fri, 21 Dec 2001 16:17:22 +0100

[...]

> In terms of what does it mean to conform to these specs.
> 
> Something that reads RDF/XML documents should minimally detect ill-formed
> documents. I note that an RSS reader, for example, may reject many
> well-formed RDF docs which happen not to be RSS. For me, that does not mean
> that the software is not conformant with RDF, simply that it is not fully
> general.

Yuk.  I now have to know what sort of RDF software is reading the RDF I
produce.  

> Something that purports to report equality of RDF/XML documents, either
> needs to follow the graph isomorphism route, or the mutual RDF entailment
> route.

Who cares, as long as the correct answer is produced?

> Something that reports triples to an application layer, should report those
> triples identified in the Syntax and Test Cases specs.

Only these triples?  Test Cases can only cover a finite number of inputs.

> Something that purports to do entailment should follow the model theory.

Agreed.

> Schema writers, and sub-language specifiers should ensure that the meaning
> they intend with the RDF graph conforms to the Model Theory spec.

Sure, in that anyone or any program producing RDF(S) should commit to the
official meaning of what they produce.

> A fully conformant RDF implementation may do all these things, but an
> interesting space is that of partially conformant specialised systems.

> As an example, a small perl script that reads a piece of RDF/XML and
> modifies it in some fashion and then writes it would in my view be RDF
> conformant if it rejected non RDF input, and only produced RDF output. 

How about the following shell script?

	#!/bin/sh
	exit 1

This seems to meet all the requirements above.

> If it
> accepts as input alternative RDF/XML serializations of the same RDF graph, I
> would, in general expect it to produce output that corresponded to the same
> RDF graph in each case. If accepts as input a pair of RDF/XML files such
> that one entails the other, then it would be a very positive indication if
> this resulted in some relationship between the pair of output files.


> If I have understood correctly you [Peter] have earlier expressed a concern
> that daml:List syntax and the RDF Model theory do not conform. In DAML,
> daml:List, daml:rest, daml:first, daml:nil are purely syntactic
> constructions within the RDF graph and your reading of the Model Theory
> draft does not permit such constructions. To me, that very discussion seems
> to admit the possibility that the RDF specs may specify something whose only
> purpose may be to constrain other specs.

This is not at all what I meant.  

The problem is roughly that:

	Sufficiently-powerful formalisms that include all their syntactic
	structures in their interpretations and that (can) assert that
	these syntactic structures are true are ill-formed.  (Think of the
	liar's paradox.)

The natural way of looking at DAML+OIL does fit in this class.  I do not
know of any reasonable way of looking at DAML+OIL that does not fit in this
class.


> Peter:
> > I think that what I stated is that the RDF standard should require that RDF
> > implementations be able to determine entailment.
> 
> I think this is too high a burden on people who wish to do simple things
> using RDF. There are multiple ways to use RDF. This requirement is not
> inappropriate for a general purpose platform (I note that Jena currently
> does not meet it). However, there are many good uses of RDF that don't even
> require identification of the triples.

Then just what is required for an implementation to be partly compliant?
What options are there?  

> Jeremy

peter

Received on Friday, 21 December 2001 12:41:24 UTC