Re: Musing about "reification"

At 06:47 PM 10/24/01 -0500, Pat Hayes wrote:
>>But suppose we also had another feature, let's call it reif:Truth, such 
>>that we can say:
>>
>>     reif:Truth rdf:type rdfs:Class .
>>     _:stmt rdf:type rdf:Statement .
>>     _:stmt rdf:subject ex:subj .
>>     _:stmt rdf:property ex:prop .
>>     _:stmt rdf:object ex:obj .
>>and
>>     _:stmt rdf:type reif:Truth .
>>
>>Still, there's nothing special about this, just regular RDF statements.
>
>OK, though I'm nervous about that 'truth'. It hasn't moved yet, but I'm 
>ready to swat it.

I'm sure you are ;-)

>>Now suppose we introduce some new semantics, along the same lines that 
>>you used for RDF schema, in the form of closure rules:
>>
>>   { _:stmt rdf:type rdf:Statement .
>>     _:stmt rdf:subject _:s .
>>     _:stmt rdf:property _:p .
>>     _:stmt rdf:object _:p .
>>     _:stmt rdf:type reif:Truth . }
>>
>>|-
>>     _:s _:p _:o .
>>
>>(hoping you'll follow my mixed notations).
>
>Yeh, well, there is a use/mention shift in there somewhere, but we can do 
>things like that when stating semantic conditions, I guess. (Wouldn't you 
>also want this to run backwards, though?)

Hmmm... this where I can't match your understanding of this stuff ... I 
thought the RDF resources here were being kept on the "use" plane.  The 
closest to "mention" I can see is that one *might* claim that the set of 
five triples somehow "mentions" the statement, but I'm strenuously trying 
to avoid saying that.

(Yes, you're right I would also want it to run backwards.)

>>  Does this provide us with a basis for making sense of reification?
>
>That is basically adding a truth-predicate, right? That would give it 
>considerably greater inferential power, but it still wouldn't handle the 
>type/token confusion (if it is confusion...).

I'm not clear about what exactly is a "truth predicate" -- I had understood 
it to be something that accepts a statement token (per your recently 
suggested terminology) and delivers a corresponding truth value.  I'm 
trying to avoid that.  As far as I can see, all I've described above can 
work entirely in the value space.  (Hmmm... does that mean I should have 
used "|=" instead of "|-" when stating the closure rule?  I wondered about 
that when I wrote it.)

>PS. Another musing, in reply. Maybe it would be easier to do this kind of 
>thing in terms of documents rather than triples, along the lines that Jos 
>and Tim are going with the log#entails stuff.

For some value of "document", that works for me.

But I wouldn't want a document to necessarily be identified with a 
web-resource boundary.  For example, CC/PP conveys fragments of RDF in 
transient protocol elements that don't have any existence in the Web as we 
usually think of it.  Also, I think that it would be useful to identify a 
"sub-document" (sometimes called a "context" or "statement set" by myself 
and others) for these purposes.

>  Then a reification of a document would be a (different) document that 
> described the first one. The point being that documents have URIs, so 
> they must be tokens, and the uriref provides just the 'missing link' 
> between a reification and the particular tokenish thing it is supposed to 
> be a reification OF. Your truth-conditions could then be stated as 
> conditions on valid entailment between documents, so that any RDF graph 
> would be reification-equivalent to another one, its reification, which 
> described all its triples and asserted them to be true. It would have 
> five times as many triples (but hey, what are you gonna do without 
> universal quantifiers?) Or, we could also allow one document to assert 
> another, and then we would have two documents: the reification document 
> with 4n triples in it, and the assertion document with one triple in it 
> that just says that the reification document is true. Then  the assertion 
> document  is reification-equivalent to the original document just in case 
> the reification document accurately reifies it.

Yes, any/all of that seems fair enough to me (and maybe some variations can 
be imagined by adding some additional semantic "closure" rules).  I would 
guess the conditions of valid entailment between documents would need to 
appeal to something similar at the statement level.

If I were implementing this stuff (and I do plan to do something like 
this), I'd use an optimized storage form to contain the triple-bloat.   But 
I'd see that as an optimization with a well-defined correspondence to RDF 
form, not an alternative syntax for an alternative RDF.

#g


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
------------------------------------------------------------

Received on Thursday, 25 October 2001 12:33:56 UTC