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

In defense of reification

From: Graham Klyne <GK@Dial.pipex.com>
Date: Thu, 23 Nov 2000 10:45:26 +0000
Message-Id: <>
To: RDF interest group <www-rdf-interest@w3.org>
I'd like to stand back a little from the reification debate, and ask 
another question.

Suppose I wish to use RDF to model a security access scheme.  Suppose 
access controls are defined in terms of (a) a resource that may be 
accessed, (b) an actor who may gain some access to the resource, and (c) an 
operation type that describes the kind of access granted.  (In case this 
seems unduly artificial, this is exactly the access control framework 
proposed for the IMXP instant messaging proposal [1].)

How is such a system to be modelled in RDF?  I present the following as a 
reasonably obvious and direct way:

   [ACE] --rdf:type---> [AccessControlElement]
   [   ] --actor------> [AccessorIdent]
   [   ] --resource---> [AccessedResource]
   [   ] --operation--> [AccessGranted]

Notice how much this looks like an RDF statement reification?

My point is that reification as currently specified is a reasonable and 
direct way to model an RDF statement in RDF.  If we want to say something 
about an RDF statement, we model it in RDF.  I think it is only because 
modelling RDF statements is seen as a very common case that the current 
debate about reification has arisen.  I believe that the appropriate 
approach is not to optimize the model to deal with modelling RDF 
statements, but to optimize the implementations (and possibly the 
serialization format).

When I was an RDF novice, I raised the issue in this forum about the 
clumsiness of reification, and was persuaded then that implementations were 
not necessarily expected to actually construct and store the reification 
quads.  I think that is the right approach, which builds upon the current 
RDF spec.


[1] http://search.ietf.org/internet-drafts/draft-mrose-imxp-access-01.txt

Graham Klyne
Received on Thursday, 23 November 2000 06:53:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:33 UTC