RE: RDF specifications

From: Graham Klyne <GK@NineByNine.org>
Subject: RE: RDF specifications
Date: Thu, 03 Jan 2002 12:19:03 +0000

> At 01:22 PM 12/19/01 -0500, Peter F. Patel-Schneider wrote:
> >Standards are not necessarily about interoperability between pieces of
> >software.  Standards may instead be about the behaviour of individual
> >pieces of software when presented with a task to perform.  For example, the
> >HTML standard is not really about getting applications to exchange
> >information, it is about getting browsers to put pixels on display devices
> >or, perhaps, getting some other interface software to present content in
> >some other human-accessible manner.
> 
> I beg to disagree... HTML is precisely about achieving interoperability 
> between the tools that create  content, and the tools that render content 
> (or, more correctly, between different tools that create and/or render 
> content).

My view actually is that it is both, but that the interoperability aspect
is parasitic on the behavioural aspect.

Why do I say this?  Well, suppose that there was no renderer for HTML.
Would HTML then be useful, even if there were trillions of applications
that could pass it back and forth?  On the other hand, suppose that there
was only one renderer for HTML.  (Are you listening, Bill Gates?  :-)  Then
I would argue that HTML was useful.

> >If RDF was only a format for exchange of information between applications,
> >then two pieces of software that (only) checked RDF documents for syntactic
> >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.
> 
> Again, I disagree.  I am sure we are agreed that the syntax alone is not 
> enough to determine entailment.  In the case of RDF, I think the 
> interoperability that is crucial is at the level of determining 
> entailment:  application A provides some information to application B from 
> which (in conjunction or otherwise with commonly available additional 
> information) both applications may determine the same entailments in 
> accordance with the rules of RDF.  The determination of entailment 
> emphatically does not, in my view, depend upon the use of any particular 
> internal data structure.

I'm not arguing for any internal data structure, just observable behaviour.
To use the HTML metaphor again, the point of the HTML standard is not to
have HTML applications use a particular internal data structure, nor is it
even to have HTML renderers put bits on a display device.  The point of the
HTML standard is to have renderers that (somehow) produce something that
can be perceived (by humans).

In the case of RDF, the point of the RDF standard is to define the
(potential) behaviour of applications when presented with RDF input.   How
the applications achieve that behaviour is not the business of the
standard.  

Again, because the RDF standard defines a behaviour, different RDF-aware
applications will behave in the same way (or in compatible ways) when
presented with the same RDF input.  This is a form of interoperability.

(On thinking things over, I do agree that it is possible to have RDF-aware
applications that do not even determine entailment.  For example, a
(simple) RDF editor might not determine entailment.  However, I think that
any RDF-aware application must act compatibly with RDF entailment.)

> >I find it instructive to liken RDFS to a programming language.  A standard
> >for a programming language specifies more than a way of exchanging
> >information between pieces of software, say an editor and a syntax checker.
> >A standard for a programming language also specifies what an interpreter
> >for the language is supposed to do.  That is an interpreter is supposed to
> >take a source program and somehow perform the instructions in the source
> >program.  Similarly an RDFS system has to somehow determine the
> >consequences of an RDFS document, perhaps by constructing and elaborating
> >an RDF graph.  If a system does not provide an interface for accessing the
> >consequences of an RDFS document, then it is not an implementation of the
> >RDFS specification.
> 
> A programming language is an interesting case, but I'll argue that it's 
> still viewable as a form of interoperability.  In general, applications 
> don't exchange programs written in a programming language, so the standard 
> for a programming language doesn't (primarily) address inter-application 
> interoperability.  Rather, it is "interoperability" between a programmer 
> (who writes the language) and an interpreter for the language.  One should 
> be able to replace the interpreter with another, and still get the same
> result. 

Yes, sure, but again this is parasitic on the primary thrust of the
standard. 

> >I want this interface to meet the interoperability requirement of
> >standards.  If this interface is not standardized then applications will be
> >stuck with one particular implementation of RDF.
> 
> I did agree that an standard API could be useful, addressing as it does 
> interoperability between components within a single application.  I just 
> don't see it as being essential to core RDF.
> 
> Actually, despite all the "disagreements" above, I suspect we're engaging 
> in violent agreement here.

Yes, we are in agreement in some sense, but I think that there is a
philosophical difference that needed discussion.

> #g

peter

Received on Thursday, 3 January 2002 09:26:57 UTC