W3C home > Mailing lists > Public > www-rdf-logic@w3.org > May 2001

Re: What do the ontologists want

From: Jonathan Borden <jborden@mediaone.net>
Date: Wed, 16 May 2001 10:48:55 -0400
Message-ID: <11cb01c0de17$54f06a70$0a2e249b@nemc.org>
To: "Dan Brickley" <danbri@w3.org>, "pat hayes" <phayes@ai.uwf.edu>
Cc: <www-rdf-logic@w3.org>
Dan Brickley wrote:

> > >pat hayes wrote:
> [...]
> > So it has no semantics at all? I doubt if that is really what you
> > mean, since then it would have no point to it, as far as I can see.
> > Certainly the RDF literature seems to *want* RDF to actually mean
> > something.

This depends on what you mean by the term "semantics". My intention with
starting with an abstract syntax formulation is to place RDF on a firm

Certainly we can start with the abstract syntax of XML itself which has been
well specified in the XML 1.0 recommendation ... and indeed I believe this
abstract syntax (i.e. EBNF) is in large part responsible for the success of
XML itself.

I believe that the only really good reason to use triples as opposed to just
XML is that this triple based abstract syntax is greatly simplified with
respect to XML 1.0 in general (see
http://www.openhealth.org/RDF/triples.html and
http://www.openhealth.org/XSet )

In terms of what these graphs or triples or documents _mean_, my assumption
is that this meaning is provided by the schema, particularly a schema such
as DAML+OIL whose raison d'etre (or so I assume) is for this specific

(not only that but I feel more comfortable defining abstract syntaxes than
semantics, particularly when we may be using the term "semantics" in
different senses, e.g. common english vs. logic  :-))

> I consider RDF content to be meaningful largely by proxy: RDF
> piggybacks on URIs, which are meaningful by virtue of
> a quasi-mystical social/legal process involving the devolution of naming
> rights (via various URI schemes) to individuals and organisations. I'm not
> sure how this aspect of meaning (ie. theories of reference) fits with the
> DAML+OIL formalisms (the Model-Theoretic and the Axiomatic semantics).

hehe. this is really the crux of the problem! regardless of RDF we are
attempting to ascribe meaning to URIs and URI references, Resources and
Entities yet what we are talking about is only described casually or in
different ways by different people in different documents. This is not an
exotic FOL problem, rather simple plain 'ole English terminology.

my reason to start http://www.rddl.org/SchemaAlgebra is so that we can start
to discuss these terms in a specific, well defined and logical fashion.
understand however, that I am not a formally trained logician, and that the
sum total of my understanding of lambda calculus consists of what a LISP
program is, and so I strongly suspect that these formulae have syntactic
errors -- i welcome correction :-))

> I'm not complaining about DAML, and I'm not claiming that RFC 2396 (the
> URI syntax spec) embodies an adequate theory of reference. Just that we're
> in the same boat, in that there's an aspect to meaning (ie. reference)
> that all these specs have a problem with.

yes. so the first order of business is cleaning up these definitions.
another (IMHO) critically important issue is that currently the syntax of
fragment identifiers are defined on a per network transaction basis (i.e.
are entirely dependent on the media type returned on a particular resolution
of a URI). I believe it is an absolute necessity that a generic fragment
identifier _syntax_ be defined, independent of media type, so that we can
properly speak of and make assertions about URI references. again see
http://www.rddl.org/fragment-syntax. the specific reason that I have propsed
the quoting mechanism that i proposed (triple scheme) is that it is
compliant with this generic fragment identifier syntax (note that this
syntax encapsulates XPointer ... hence describes the major fragment
identifier syntaxes I am aware of).

Jonathan Borden
The Open Healthcare Group
Received on Wednesday, 16 May 2001 11:05:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:45:37 UTC