Re: Of "reification" (and sealing wax?)

>Pat,
>
>I thought I had been converging on some understanding of these 
>issues, but my attempts to bridge the (mis)understandings seem to 
>keep "bouncing off" some fundamental block...
>
>At 11:22 PM 6/23/01 -0500, you wrote:
>>>A part of this will be deciding about the role of "reification", 
>>>or maybe some replacement idea.  I happen to think this is a key 
>>>area, because the issues of provenance/trust/logic depend on being 
>>>able to use a statement without asserting it.  (I am skeptical 
>>>that this can be retro-fitted to a core RDF consisting of just 
>>>asserted triples.)
>>
>>This is probably going beyond the scope of this working group, but 
>>I would like to reiterate an opinion I have already voiced on 
>>RDF-logic. The previous paragraph seems to accept a view that seems 
>>to be built into RDF 1.0, but shouldn't be, since it is  profoundly 
>>and totally mistaken. This is the view that an expression  must be 
>>either asserted or described (reified), so that anything that is 
>>not asserted must be reified. This view is so utterly wrong that I 
>>find it hard to understand how it ever got built into RDF. Every 
>>logic ever invented, from Aristotelian logic forwards, has used 
>>propositional expressions in ways other than asserting them, until 
>>RDF.  RDF, uniquely in the history of human language design, 
>>provides no way to use an expression other than to assert it. In 
>>effect, it has no propositional syntax. Reification does not 
>>provide a way to add one.
>>
>>To see why this assumption is wrong, consider any simple 
>>propositional assertion which is more complicated than an atomic 
>>fact, eg say the negation of an atomic fact. If someone asserts 
>>(not P), they obviously do not assert P. However, they also do not 
>>*mention* P or *describe* P; they use the expression P in *exactly 
>>the same way in the same sense* as someone who asserts P 
>>simpliciter. Both asserting and denying are about the truth-value 
>>of the expression.
>>
>>There are two different contrasts one needs to keep distinct: 
>>between using and mentioning an expression, and between an 
>>assertion and other uses of an expression. Denying P , or claiming 
>>that P implies Q, or that one of P, Q or R is true, all *use* 'P' 
>>in the same way that asserting P itself uses the expression. In 
>>modern boolean logic, they are all done by asserting some 
>>propositional expressions (respectively (not P), (implies P Q) and 
>>(or P Q R).) None of these involve mentioning or reifying the 
>>(sub)expressions which are being used.
>>
>>All the model theories that have been suggested for RDF either 
>>ignore reification or treat it, correctly, as indicating that a 
>>statement exists. But if I assert (not P), ie if I deny P, I am not 
>>saying that P exists, still less that P doesn't exist: I am saying 
>>the world is such as to make P false, just as when I assert P I am 
>>saying the word is such as to make it true. In both cases I USE the 
>>expression to say something about the world, not MENTION it to say 
>>something about it.
>>
>>I am not arguing that reification should be abandoned or forbidden 
>>(though I would shed no tears if it were). It may have some 
>>utility. But it should not, and indeed I think cannot coherently, 
>>be used as a tool to encode non-assertional uses of subexpressions. 
>>In particular, it cannot be used to encode negation, disjunction, 
>>quantification or any of the rest of 'normal' logic, nor to encode 
>>modalities (such as indirect speech, as in transcribing "Ora said 
>>that Bill was Danish"; contrast direct quotation, as in "Ora said: 
>>'Bill was Danish' " where Ora's actual words are cited, rather than 
>>the propositional content of what Ora said. The latter does indeed 
>>involve reification of a statement, indicated in English as in many 
>>technical languages by the use of quotation.) In brief: reification 
>>is a technical device of very limited utility; in particular, it 
>>cannot be used to 'retrofit' most aspects of a richer assertional 
>>language into RDF.
>
>I'd like to try a little "thought experiment":
>
>1.  Suppose we have a language, say RDF[0], whose *only* primitive 
>construct is the quadruple of triples that we call "reification":
>    id rdf:type rdf:Statement .
>    id rdf:predicate p .
>    id rdf:subject s .
>    id rdf:object o .
>It's not very expressive -- using this, you can't say anything 
>meaningful about the world.  It simply allows one to bind a binary 
>predicate to an identifier:  (= id (p s o) )

Well, there is something basically unclear about this language. You 
say its only primitive construct is reification, but that isnt quite 
correct, I think (?), since it USES triples in a non-reified way to 
do the reifying. If you try to give this a semantics you will see 
what I mean: eg, the interpretation of rdf:predicate is a binary 
relation between thingies of one kind called statements and thingies 
of another kind, and "id rdf:predicate p" is true (in I)  when the 
pair < I("id") , I("p")> is in I("rdf:predicate"). In other words, 
those four triples inside the reifaction need to be interpreted as 
assertions (about setences, but still assertions) and those triples 
are bieng used, not reified. So you are restricting RDF here to a 
very small subset of RDF1.0, but it still obeys the interpretation 
rules of RDF 1.0.

>2.  Now suppose that we have a new language, RDF[1], which is the 
>same as RDF[0] but has an additional primitive construct:
>    or id id .
>which means, if id is bound as above, (or (p s o) (p s o) ), which 
>(under the usual meaning of or) is the same as (p s o).

The usual meaning of 'or' is the truth function (lambda (x y)(if x 
then T else y)). That doesnt give any value when applied to RDF 
sentences, which is what "id" denotes. You have missed out a vital 
step: you need to get from the expression itself (triple, in this 
case, denoted by "id") to its interpretation (a truthvalue, in a 
given interpretation, or maybe a proposition, or something like that: 
but not something syntactic like an expression or a sentence, for 
sure. What you need is the *meaning* of the sentence, in some 
suitable sense.) Again, try giving a semantics. The denotation of the 
expression "or id id" in an interpretation I is going to be some 
I-value for 'or' (never mind exactly what that is for now) applied 
(twice) to the I-value of "id";  I(" or id id") = I("or") ( I("id") 
I("id") ) and we know that I("id") is an expression (indicated by '(p 
s o)' ). Note that is not what you get when you USE the expression: 
if I were to assert (p s o) (ie to use it) then I wouldnt be 
referring to the sentence itself; I would be referring to a 
p-relation between two things called s and o (not two symbols called 
's' and 'o'). That is not what is meant by
or (p s o) (p s o) , however. It is more like
or '(p s o) '(p s o)
(note the quote marks: ive used LISP-style quotes to indicate the 
triple rather than the character string.)
Now, one CAN make sense of this, but only by interpreting 'or' in a 
rather nonstandard way. Instead of a truth-function
(lambda (x y)(if x then T else y))
it has to be the functional product of this with a semantic 
evaluation function (often called a truth predicate.) So suppose that 
'isTrue' is a predicate on expressions which obeys the semantic 
equation I(isTrue) = (lambda (x) I(x)), i.e. in any interpretation, 
it maps the expression to its value in that interpretation. Then the 
'or' you want here is
(lambda (x y)(if x then T else y)) o isTrue
ie (lambda (x y)(if I(x) then T else I(y)))
which is the same as writing (using now the 'usual' truthfunctional or)
or isTrue((p s o)) isTrue((p s o))
rather than
or (p s o)(p s o)

So, why not always interpret 'or' in this kind of a way? Well, the 
trouble is, it then doesn't mean 'or' when used 'normally', ie if I 
simply assert (or A B) where A and B are sentences (not names of 
sentences) then this truth-evaluating interpretation of 'or' will try 
to look up the intepretation of the interpretation of A and B, 
instead of just interpreting A and B in the usual way. And there is a 
deeper reason why this is a bad idea: it involves the interpretation 
function (I) in its own definition, ie it makes interpretation 
recursive. That is where paradoxes creep in if one is even a tiny bit 
careless, and even if one isnt careless it makes the semantics very 
much more complicated.

>This RDF[1] seems to me to have the same expressive power as RDF. 
>But, as far as I can see, it establishes a framework for *use* of a 
>predicate that is bound using the construct that RDF calls 
>"reification".

No, you kind of slid from mention to use when you went from
or id id
to
or (p s o)(p s o)

>I can't see what I am missing when you say, categorically, that 
>"[RDF] has no propositional syntax. Reification does not provide a 
>way to add one".  Is the problem with the term "reification", or is 
>it fundamental in the structure suggested?

The point is that reification alone doesnt do it. Reification plus a 
truth-predicate (isTrue, or whatever) might be a way to do it, but 
its an amazingly ass-backwards and awkward and dangerous way to do 
something that ought to be blindlingly simple (and is, in virtually 
every other natural and formal language).

>
>(This is the kind of thing I have been trying to pursue with my 
>"abstract syntax" and subsequent attempt at a semantics.)
>
>I'm trying to capture that the following:
>    id rdf:type rdf:Statement .
>    id rdf:predicate was .
>    id rdf:subject Bill .
>    id rdf:object Danish .
>    Ora said id .
>can mean
>    "Ora said that Bill was Danish"
>rather than
>    "Ora said: 'Bill was Danish' "

??But the first one doesn't use reification, and the second one does, 
so why would you want RDF reification to mean the first one?

Pat

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 26 June 2001 13:08:58 UTC