W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2000

Re: abstract model and reification

From: Graham Klyne <GK@Dial.pipex.com>
Date: Mon, 18 Sep 2000 22:08:19 +0100
Message-Id: <>
To: Dan Brickley <danbri@w3.org>
Cc: "McBride, Brian" <bwm@hplb.hpl.hp.com>, "RDF Interest (E-mail)" <www-rdf-interest@w3.org>
At 02:07 PM 9/18/00 -0400, Dan Brickley wrote:
>On Fri, 15 Sep 2000, McBride, Brian wrote:
> > A colleague has pointed this out to me, from m&s:
> >
> >   When a resource represents a reified statement;
> >   that is, it has an RDF:type property with a
> >   value of RDF:Statement, then that resource
> >   must have exactly one RDF:subject property,
> >   one RDF:object property, and one RDF:predicate
> >   property.
> >
> > Oh well ...
>Hmmm... I'm sat here with Dave Beckett trying to figure out what this
>might mean. Here's a possibly sneaky interpretation: the resource "in
>itself" must have those properties, but an RDF implementation (database,
>serialised graph etc.) might not have representations of those
>properties, even though they (in some sense) exist in the abstract.  So,
>the reading of the spec is that resources that are reifications of
>statements will always have these four properties. But we don't
>necessarily know what the values of those properties are. So we take the
>'must' language to be an observation about the world, rather than about
>data structures...

Well, as a reading of the spec, it seems a bit of a stretch.  But as a 
sta5tement of intent, it sounds reasonable.  Practically, I don't see that 
it's possible or helpful to insist that a resource representing a reified 
statement in a model has the properties as stated.  What is to stop me 
creating the graph:

   [A] --P-------------> [B]
   [S] --rdf:type------> [rdf:Statement]
   [S] --rdf:property--> [P]

?  Here, S may or may not be a reification of [A] --P--> [B].  But from its 
type, it clearly represents _some_ reified statement.


Graham Klyne
Received on Monday, 18 September 2000 17:12:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:25 UTC