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

Re: Difference between syntactic building blocks and formal languages ...

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Wed, 02 Jan 2002 10:42:48 -0500
To: seth@robustai.net
Cc: www-rdf-logic@w3.org, horrocks@cs.man.ac.uk
Message-Id: <20020102104248V.pfps@research.bell-labs.com>
From: "Seth Russell" <seth@robustai.net>
Subject: Difference between syntactic building blocks and formal languages ...
Date: Fri, 28 Dec 2001 15:04:11 -0800

> Re:  http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0173.html
> Quoting from: Ian Horrocks (horrocks@cs.man.ac.uk)
> [[
> These sorts of problem illustrates just why we need a precisely
> defined semantics for our languages. If we allow for two possible
> interpretations we may get into all sorts of difficulties:
> - it may be impossible to say something in DAML+OIL without stating
>   something unintended in RDF (and vice versa)
> - it may be impossible to know which of two (possibly conflicting)
>   meanings is the intended one
> ]]
> But if we consider RDF\triples to be just syntactic building blocks with no
> formal semantics whatsoever, then would we still have this problem?  This
> view would mean that the entailments of any statement are only the
> entailments that can be infered by the axioms related to the arc label. In
> other words property arcs have semantics and entailments, but languages like
> DMLS, RDFS don't.  This has the advantage of allowing us to mix and match
> all the available properties of all the schema written in or translatable
> into NTriples.

RDF does have at least an intended meaning, and is probably getting a
formal semantics.  In light of this, I feel that any use of RDF triples has
to conform with the intended meaning.

> Would that work?  If not, why not?

I think that the problem is what a web ontology language syntax would want
to use the parts of RDF that have a non-trivial intended meaning which
would get in the way.

> Seth Russell

Received on Wednesday, 2 January 2002 10:43:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:37 UTC