W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2001

what is RDF for? (was: RDFCore WG 2001-06-01 Teleconference Agenda)

From: Frank Manola <fmanola@mitre.org>
Date: Wed, 06 Jun 2001 13:12:23 -0400
Message-ID: <3B1E6477.7BE604FF@mitre.org>
To: Graham Klyne <Graham.Klyne@baltimore.com>
CC: Brian McBride <bwm@hplb.hpl.hp.com>, rdf core <w3c-rdfcore-wg@w3.org>
Graham Klyne wrote:
> At 09:48 AM 6/7/01 +0100, Brian McBride wrote:
> >Graham Klyne wrote:
> >[...]
> > > More recent discussion on the RDF-logic list has focused on the
> > > relationship between "reification" and syntax, and the nature of RDF
> > > "syntax".  A viewpoint that emerges from this discussion is that the RDF
> > > structure of triples is too simple to attach any meaningful
> > > semantics;
> >
> >Graham, do you really mean 'any meaningful semantics', or do you mean
> >that it is not syntactically rich enough to support, for example expressions
> >with quantifiers.  It seem to me rich enough to support the assertion of
> >'ground facts' with the semantics defined in the definition of the
> >semantics of the URI's involved.
> (That was an unfortunate turn of phrase I used ;-)
> But, yes, for example, the syntax (defined simply in terms of triples) is
> not rich enough to support expressions with quantifiers.  One can use the
> triples to encode some richer syntax (e.g. as one uses character sequences
> to encode programming language constructs) that is capable of supporting
> this, but that would be a different syntax hence a different language.
> So, to define a useful level of semantics, there must be a sufficiently
> rich syntactic structure.

While the above sentence is undoubtedly true, it leaves unaddressed the
question of what constitutes "a useful level of semantics" in the
present context.  We also have a general problem of our unstated
assumptions in a lot of these discussions.  What *I* believe Brian is
talking about (correct me if I'm wrong) when he says

> >It seem to me rich enough to support the assertion of
> >'ground facts' with the semantics defined in the definition of the
> >semantics of the URI's involved.

is roughly this:  

1.  Let's assume that the intended purpose of RDF is to provide a
facility for specifying collections of attribute-value pairs that
describe Web resources (example:  collections of Dublin Core attributes
about documents).  Under this assumption, there are some mechanics that
are really involved in using RDF that aren't currently very explicit,

a.  there is some mechanism that separates the collection of AV pairs
that one person created to describe a resource from a collection that
someone else has created (just as there's an assumption that a
collection of FOL expressions written by one person to describe one
circumstance is separable from a collection of FOL expressions written
by a second person to describe another circumstance).  This is
presumably some form of context (or at least, scoping) mechanism.

b.  within one of those collections, the AV pairs are implicitly anded; 
as I've mentioned before, I think RDF is intended to be a simple
existential conjunctive logic;  simple because only binary predicates
are allowed;  existential because there are also effectively "there
exists" quantifiers to quantify the resources involved in the
description (effectively because you can consider the URIs as being
Skolem constants that remove the need for these quantifiers.  

2.  these AV pairs constitute the "ground facts" about certain resources
using predicates from some domain (like publishing, in the case of
Dublin Core);  so the fact that Ora Lassila authored some Web page is
one of these "ground facts"

3.  the "semantics" in question are the semantics of predicates like
"author" (or the corresponding URI).

4.  RDF was intended to *reference* the semantics of predicates like
"author" (by using them in AV pairs), but not *define* them;  that
definition was left for other languages (like DAML+OIL, for example).

5.  Specifying such "ground facts" in RDF, using the semantics of
predicates in AV pairs that are defined elsewhere and "elsehow", is
nevertheless "useful" (although perhaps not "a useful level of
semantics");  just as being able to specify the data in tables in a
relational database is useful, even though you can't specify the
semantics of the tables, rows, or columns in that way.

Now, a lot of the debate on rdf-logic has revolved around the fact (I
repeat, *fact*) that you cannot express negation, universal
quantification, and other things in RDF triples, and expect them to
"work" as if these were native parts of the EC logic represented by the
above interpretation of RDF.  You can certainly encode a lot of
different things in triples, write triples that (for example) have NOT
as a predicate (and define engines that process those predicates), and
use those triples as some kind of exchange notation.  However, it seems
to me this moves us towards a different assumption about what RDF is for
than that stated above.  That doesn't disqualify that idea (although if
exchange of logical expressions were the motivation, I'm not sure I'd
immediately think of triples), but it is an idea that needs explicit
consideration as being separate from the idea of RDF as being for the
simple description of resources using AV pairs.

It seems to me there needs to be some nailing down of our assumptions
about what RDF is for, and correspondingly of our assumptions about the
so far implicit mechanisms I've suggested above (contexts/scoping,
anding of statements, etc.), and how (or whether) they are supported by
RDF or RDF processors, based on RDF's intended use.  This isn't intended
to be "philosophical" (to raise a politically-incorrect word here) as
much as to provide guidance for evaluating many of the issues that have
been raised regarding reification and other facilities, and for
clarifying the description of RDF in the specs.


Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752
Received on Wednesday, 6 June 2001 13:17:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:49 UTC