W3C home > Mailing lists > Public > www-rdf-interest@w3.org > December 2001

RE: RDF specifications

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Fri, 21 Dec 2001 16:17:22 +0100
To: <www-rdf-interest@w3.org>
Message-ID: <MABBLGKMPIJFCKFGDBEPCEIJCAAA.jjc@hplb.hpl.hp.com>


> If RDF was only a format for exchange of information between applications,
> then two pieces of software that (only) checked RDF documents for
> validity and could echo their input would be sufficient to meet the W3C
> expectation that candidate recommendations have two implementations.  The
> pieces of software would not have to generate any internal data structures
> corresponding to the RDF data model or do any other RDF-related processing
> of the RDF documents.

I note that many plausible metadata applications of RDF could do little more
than this!

I think the triple model may be positively an impediment to deploying
working Dublin Core or RSS systems.

So the question remains what is the RDF Core WG upto in going to such
lengths to make the RDF graph a well-defined structure.

In my view, when RDF was only intended to act as a metadata language the
vagarities of M&S were livable with. As the semantic web vision clairifies,
and RDF is intended to play a foundational role then it is more necessary to
define it clearly.

So my view of how the new specs hang together:
Syntax - defines a subset of XML documents that are RDF documents.
         also defines mapping from RDF/XML to RDF Graph.
Model Theory - defines a model theory for RDF Graphs
               and hence, a model theory for RDF/XML documents
               and entailment for RDF Graphs
               also defines entailment and model theoretic aspects of RDFS
Schema       - not sure yet, minimally introduces the vocabulary of RDFS
Test Cases   - introdcues N-Triple as an alternative syntax, and sets up
               RDF/XML, N-Triple pairings. Thus stresses importance of
               graph isomorphism as one verion of RDF equality.

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

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

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

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

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

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. 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.

> I think that what I stated is that the RDF standard should require that
> 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.

Received on Friday, 21 December 2001 10:09:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:38 UTC