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

Pat,

I note that your response below was "penned" before your response to my 
other message about abstract syntax [1].  I think the alternative treatment 
of the "reification" quad indicated there might have had some effect on 
your response.

I'm suggesting an interpretation of the quad-expression as a kind of 
definition, not as reification.  This why I hedged by saying the 'quadruple 
of triples that we call "reification"' -- I'm not clear what "reification" 
is to logicians, but it seems that this is not it.  (Is it really just 
quotation?)

I now see that my use of the notation (p s o) was wrong.

I was intending to use (p s o) as a function application in this 
case.  Thus, I was trying to say something like:

   I(" id rdf:type rdf:Statement .
       id rdf:predicate p .
       id rdf:subject s .
       id rdf:object o . " )

       = (= id (I("p") I("s") I("o")))      [NOTE1] [NOTE2]

where I("p"), I("s") and I("o") are provided by some other part of the 
interpretation, and I("p") is a binary predicate.  In words, the quadruple 
above means that the symbol "id" is bound to some binary predicate 
associated with "p" applied to argument values associated with "s" and "o" 
respectively.

[NOTE1] I'm assuming here that I("id") = id -- that identifiers in the 
language represent the same identifier in the domain of interpretation -- 
is this valid?

[NOTE2] A reminder of the other message:  I am suggesting that the quad is 
interpreted here in its entirety, not in terms of its components as they 
might be understood in standard RDF.


Then using your definition (lambda (x y)(if x then T else y)) for 'or', and 
'id' as above:

   (or id id) = (or (I("p") I("s") I("o")) (I("p") I("s") I("o")) )
                ((lambda (x y)(if x then T else y))
                         (I("p") I("s") I("o"))
                         (I("p") I("s") I("o")))
                ... etc.

<aside>
The reason for choosing 'or' here was quite arbitrary:  it easily fitted 
the binary predicate form and was one of the examples of "use" that you 
gave.  I might have chosen:

     assert1 id x .

and defined its interpretation as:

     I("assert1 id x .") = I("id")
                           ... etc.
</aside>

#g
--

[1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Jun/0489.html

At 12:08 PM 6/26/01 -0500, pat hayes wrote:
>>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

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<Graham.Klyne@Baltimore.com>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Received on Thursday, 28 June 2001 09:24:59 UTC