W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2002

RE: RDF specifications

From: Graham Klyne <GK@NineByNine.org>
Date: Thu, 03 Jan 2002 12:19:03 +0000
Message-Id: <5.1.0.14.2.20020103120347.03944cb0@joy.songbird.com>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: www-rdf-interest@w3.org
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).

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

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

#g


--------------------------
        __
       /\ \    Graham Klyne
      /  \ \   (GK@ACM.ORG)
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
  \/___________/
Received on Thursday, 3 January 2002 08:18:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:52 GMT