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

Re: Why? Re: rdf as a base for other languages

From: Seth Russell <seth@robustai.net>
Date: Mon, 4 Jun 2001 06:19:30 -0700
Message-ID: <005b01c0ecf8$fe4a4a60$b17ba8c0@c1457248a.sttls1.wa.home.com>
To: "Brian McBride" <bwm@hplb.hpl.hp.com>, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: <www-rdf-logic@w3.org>
From: "Brian McBride" <bwm@hplb.hpl.hp.com>

> The object of an RDF statement must be a resource or a literal.  Whilst
> does not specifically say that resources and statements are disjoint, it
> my interpretation of that they are disjoint, on the grounds that M&S
> specifically states that properties are a subset of resources, but omits
> making that assertion about statements.
> Consequently, if you accept this interpretation, a statement cannot
> be the object of another statement in the RDF defined by M&S 1.0

Quoting directly from M&S 1.0

      "A new resource with the above four properties
       represents the original statement and can both
       be used as the object of other statements
       and have additional statements made about it."

So that, while it is true that the statement itself cannot be the object of
another statement, a resource which represents the statement can.  But we
can well define any property arc which takes a reified statement as it's
object to mean that it's object is the statement itself.  Such a mechinism
is similar to declaring a property arc to be transitive.

r subProperty Unreifies.

    means "If {B represents C} and  {A r B}, then {A r C}".

So that in the sentence

     Jon says ((the sky) is red).

If we represent the statement ((the sky) is red) by a RDF reification quad
and declare that {says subProperty Unreifies}, then certainly that statement
is the logical object of  the other statement.

If we cannot make logical substitutions like this in RDF, then what kinds of
logical substitutions are permissable and which are not?  How can we be
willy-nilly about this ?

Seth Russell
Received on Monday, 4 June 2001 09:26:21 UTC

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