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

Re: Musing about "reification"

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Wed, 24 Oct 2001 18:47:48 -0500
Message-Id: <p05101076b7fcff2f6b85@[]>
To: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Cc: w3c-rdfcore-wg@w3.org
>At 04:56 PM 10/24/01 -0500, Pat Hayes wrote:
>>This all works fine until we get to reification, at which point it 
>>all goes horribly wrong, because the only useful sense of 
>>reification would be about tokens (triples) , but the only one we 
>>have actually got is about statements.
>Since reification is creeping out of the closet again,
>some musings...
>The structure of triples we call reification, as it stands, has no 
>special interpretation -- it's just more RDF statements.  Right?

Right, though I have no problem imposing reification semantics that 
insist that the things in the class rdf:Statement are in fact RDF 
statements. That would be another semantic extension and have a 
corresponding notion of entailment.  (I kind of did that at the F2F, 
though it wasn't stated in the newer way.)

>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 .
>     _: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.

>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?)

>  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...).


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. 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.
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Wednesday, 24 October 2001 19:47:56 UTC

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