W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2001

RE: Why reification doesn't make sense (was: Re: PRIMER: PrimerReificationSection)

From: dehora <dehora@eircom.net>
Date: Wed, 24 Oct 2001 15:59:01 +0100
To: "'Pat Hayes'" <phayes@ai.uwf.edu>
Cc: <w3c-rdfcore-wg@w3.org>
Message-ID: <001701c15c9c$6c0f2530$01000001@MITCHUM>
Hi Pat,

Pat :
The example it gives introduces a 'statement'

 &lt;rdfprimer&gt;   &lt;editor&gt;   "eric".

That looks like a triple to me. (My criterion is the trailing dot. :-) 

<rdfprimer>   <editor>   "eric".

Yes. It's a triple.

Pat :
What exactly IS a 'statement' ? Is it a particular  syntactic token, or
a data structure, or something more like an expression? For example, if
two different documents contain identical triples, how many statements
is that? Two (that are isomorphic in some sense) , or one (that has two
tokens) ?

From the M&S:

A specific resource together with a named property plus the value of
that property for that resource is an RDF statement. These three
individual parts of a statement are called, respectively, the subject,
the predicate, and the object. 

There is also a set called 'Statements'. The M&S was never so clear on
whether the set of statements contained abstract things (like integers)
or the set of sets of inscriptions of statements, or a set of all the
statement inscriptions in the world, or... A few people in rdf-ig,
myself included,  agreed to agree that there was a set called
statements, that this set contained abstract things, and that anything
that might be inscribed in a text or a hard disk was a representation of
a statement (probably what we call a triple here), if only because that
let us each have a representation of the same statement in our inboxes.
Possibly this is where the term 'triple' comes from.

I guess calling "<rdfprimer>   <editor>   "eric"." a statement is
consistent with the M&S and a fair amount of article level literature;
I've got no problem calling it a triple instead of a statement if that's
more accurate.

Pat :
You go on to explain how to say something about that statement:

How would we go about doing this?  Well we know that the subject of a
statement is a resource denoted by a URI or an anonymous resource, and
we know
that these can also be the object of an RDF statement. So the thing to
do would
be associate the statement with a URI or an anonymous resource and use
that in
place of the statement directly. Here we'll use an anonymous resource,

Wait a minute; a miracle occurred in there somewhere. We have a triple
(above) and we have a bNode which is 'associated' with it. How?? What is
the nature of this 'association', and where and how is it recorded in

Well, more like three card trick. I'm not sure what you're looking for
Pat, but if you're asking for 'reification logically follows from' then
you won't find it in the M&S. You ask how. There isn't any operational
specification of how any more than there is a specification for writing
down triples. You want to a statement denoted (and by denotation make it
a resource available to RDF), you add four triples and you add them

Having re-learned recently that one can't get soundly from symbols to
things in the world, then I would say that the miracle which is
occurring is no different from the miracle of denotation that allows us
to associate URIs with things. The odd bit about reification is that we
start with a triple and go from generating a symbol for that triple to
generating a resource for that symbol, as if we magicked a resource to
justify the existence of an anonymous resource symbol. Unless we say
that the presence of a URI or an anonymous resource is an index of a
resource and that it's always reasonable in RDF to abduct the existence
of resource when we come across these indices.

   <rdfprimer>   <editor>       "eric".
   <w3.org>      <published>    _:stmt.
   _:stmt        <gathered>     <w3.org>.  
   _:stmt        <type>         <Statement>.
   _:stmt        <subject>      <rdfprimer>.
   _:stmt        <predicate>    <editor>.
   _:stmt        <object>       "eric". 

It's true to say that nothing binds the triple with its denotation. But
that's true of any resource and its denotation in RDF. Maybe I shouldn't
say 'associate'.

Pat :
and we get the example of the reification

   _:stmt    <type>       <Statement>.
   _:stmt    <subject>    <rdfprimer>.
   _:stmt    <predicate>  <editor>
   _:stmt    <object>     "eric"   

of the triple given first. Now, that is a *description* of a 'generic'
such triple, right? It says that a thing exists which is a Statement and
has these three property values. (Incidentally, it says that the subject
is rdf:primer, not "rdf:primer", so it actually doesn't make sense; but
let's leave that for now.) 

Cautious yes, not sure what 'generic' means. (I don't understand the
aside. Why would I need to put quotes around rdfprimer?). Like I said,
what Statement is a set of is somewhat vague in my mind.

Pat :
But that isn't enough to pin down any particular statement with this
form (the one in this particular document, say, or this particular
file). Obviously, another statement with exactly the same form might be
at this very moment being transmitted from somewhere in Iraq to
somewhere in Turkey, and this description could be referring to that one
instead of the one in my document. So, to repeat, HOW does RDF
'associate' this description, or possibly the _:stmt name used in it
(which, by the way, isn't even part of RDF syntax, so hardly seems
suitable for the rather central role it ought to have), with the *actual
statement* that it is supposed to be a reification of? Is there some
kind of secret labelling process going on under the hood, which somehow
attaches this anonymous node to the statement, thereby making it into a
reified statement?

No secret labelling. Any URI or anon resource that has a type property
with the value Statement, denotes a reified statement. 

Just so I understand you: the reified statement (anon resource) denotes
the abstract thing, what might be called the 'statement', not the triple
that's been written down?

(And: why isn't '_:stmt' part of RDF syntax? It's an anonymous

Pat :
OR have I got the wrong idea about statements altogether? If the answer
to my original question is that two identical triples in two different
documents are really only one statement, so that a statement is a class
of tokens all with the same syntactic form, then the reification of a
statement in four triples does indeed uniquely specify a single
statement. But with THIS sense of 'statement', it doesn't make sense to
say things like 'eric is the author of' a statement, since statements in
this sense don't have authors (or perhaps, can have infinitely many
authors), and similarly it doesn't make sense to say that document
contains a statement (as opposed to a token of the statement, which does
make sense but cannot be said in RDF).

Well, the examples aren't saying that eric is the author of a statement;
what's being said is that a statement was gathered from a resource and
that the same statement was published by the resource. That aside,
suppose there _is_ a statement; here's its representation as a triple:

  <rdfprimer>   <editor>   "eric".

here is the reification according to the M&S:

   _:stmt    <type>       <Statement>.
   _:stmt    <subject>    <rdfprimer>.
   _:stmt    <predicate>  <editor>
   _:stmt    <object>     "eric"   

Are you saying that a reification in RDF, is actually a reification of
the statement and not of the triple, and what was intended is the
reification of the triple? That is, our denotation is denoting the wrong

Pat :
There is a basic mismatch, either way: RDF reifications describe
syntactic forms, but the things people want to use it for require it to
refer to tokens of forms, not the forms themselves; and RDF reification
provides no way to refer to a statement token.

Assuming this is correct (I don't fully grasp the distinction you're
making) and there is a fundamental mismatch to the extent we are not
able to say what we intended to say using reification. Do we have a new


bdehora at interx.com 

Received on Wednesday, 24 October 2001 11:01:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:05 UTC