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

Re: rdf as a base for other languages

From: Jonathan Borden <jborden@mediaone.net>
Date: Mon, 4 Jun 2001 12:47:29 -0400
Message-ID: <07c001c0ed16$3c8b00e0$0a2e249b@nemc.org>
To: "Wolfram Conen" <conen@gmx.de>
Cc: <www-rdf-logic@w3.org>
Wolfram Conen wrote:
> Jonathan Borden wrote:

> >
> > The problem is the term 'ground fact' and the way it is equated with the
> > simple _presence_ of a triple in RDF. In so doing, RDF uses up what a
_fact_
> > is. For example, a new language or an extension of RDF might wish to
equate
> > a fact with an expression constructed of multiple triples e.g. a
subgraph.
> > But RDF does not allow the assertion of a subgraph without asserting
every
> > triple in the subgraph.
>
> That seems to be true, but the questions are how you "express" what you
> want to model and how you "interpret" (in the sense of giving it a
> menaing in a universe of discourse) the resulting graph (is this
> prescribed in RDF?). Let me be more specific along your example:
>
> >
> > Hence what should be a simple construct:
> >
> > (not (color sky blue))
> >
> > becomes contorted.
>
> Yes, if you model this as (for example):
>
> [sky color blue]
> [r type statement][r subject sky][r predicate color][r object blue]
> [r hasTruthvalue not]
>
> it becomes a little bit diffult* (see additional remark below, if you
> like).

Not just "difficult", I would say this is a logical contradiction.
Removing the [sky color blue] triple makes it merely contorted
(i.e. 5 triples for 2 statements) and suppose we then apply "not" to the
entire expression, we cannot reconstitute the supposed 'fact' [sky color
blue] without 'unreifying' the group of 4 statements. The usual rules of a
not applied to a not would be to simply remove the not e.g. (not (not s)) =>
s, but (not (not s)) where s is a reified statement implied the reified
statement - no? regardless this seems contorted at best.

-Jonathan
Received on Monday, 4 June 2001 13:05:46 GMT

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