first draft on ISSUE-25 (Deprecate Reification)

On Mon, 2011-04-11 at 22:00 -0500, Pat Hayes wrote:
> On Apr 11, 2011, at 3:52 PM, Sandro Hawke wrote:
> 
> > On Mon, 2011-04-11 at 13:50 -0500, Pat Hayes wrote:
> > 
> >> I guess I give up at this point, Sandro. If you can't see the
> >> difference between making assertions about the (or a) world, and
> >> making assertions about syntax, I don't think we are going to be able
> >> to communicate rationally. To me, these are about as different as two
> >> things can be. Ever noticed what the original meaning of 'ontology'
> >> is? 
> > 
> > Hmmm. I don't want to push you into a conversation that doesn't feel
> > productive to you.
> 
> Sorry I got a little snappish there. Its been a frustrating week, for off-list reasons. Apologies.

No problem.

> >   My issue is this: I see a series of steps (one
> > might even say a slippery slope) from William's example that everyone
> > seems to think is fine, on down to RDF reification. 
> > 
> > When I thought I understood where the bright line was, you disagreed.  
> > You said that my example:
> > 
> >> [ :ternaryRelation movie:showing;
> >>  :op1 "The Sound of Music";
> >>  :op2 "2011-04-11T12:40:00Z"^^xs:datetime;
> >>  :op3 eg:SomeTheater ]
> > 
> > wasn't reification, but I think that's just a description of a 3-ary
> > predicate atomic sentence -- that is, it's about syntax.
> 
> Well, OK, but if it is about syntax then I didn't read it correctly. I thought it was supposed to be analogous to William's example of encoding a 4-ary or 5-ary relation in RDF. If its about syntax, then I agree it is similar to reification.
> 
> Let me ask you: what do you think are the rdfs:domains of :op1, :op2 etc. ? Are they the class of atomic sentences (in ISO common logic, maybe, or a kind of super-RDF that allows n-ary predications)? Or of relations? Or relation instances? Or what? 

This is why I think there is some gray area about reification.   I would
think, strictly speaking, the domains of :opN would be terms.  But in
RDF reification, they're objects in the domain of discourse. 

It's like in RDF reification, the triples are 75% reified (which is a
little bit like being 75% through a teleporter.)

> >   You also
> > asked what is this "thing", and the answer is "a sentence" (of some
> > sort).
> 
> Well, OK again, but then you are not doing the usual way of embedding a n-ary relation in a binary format. 
> 
> >   Perhaps my example -- that I meant that as a sentence -- wasn't
> > very clear.   When I made the 3-ary relationship (the
> > showing-of-a-movie-at-some-time-and-place) an RDF object, that felt like
> > reificiation (of *a* logic, but not of RDF) to me.  
> 
> OK, then this is the bright line, and it is an ontological bright line. The 'standard' role-based way to encode an n-ary predication into a binary logic goes like this:
> 
> Rel(a1, ....an) <==> (exists (x) (Rel(x) & Role-1(x, a1) & ... & Role-n(x, an) ))
> 
> Where the various roles are typically things like the agent, object, recipient, time, place, manner, etc. of the event or situation being described. Exactly which is which depends on what conventions were being used for arguments in the original formalism, of course: the above list reflects a common kind of convention based on English word phrase ordering, but other cultures might well find different orderings more natural. (One of the benefits of the role-based version is that it expresses the various roles without getting involved in essentially arbitrary decisions about order of arguments.)  But now, look: being the agent does not mean the agent *of a sentence*; being at a time does not mean the time *of a sentence*, and so on. In the movie example, the movie is not related to *a sentence* but rather to a screening event (or some such entity) in geophysical space. Using reification to model this forces all these roles to apply to something syntactic, which does not really make sense. 
> 
> >   So perhaps it's
> > the description of the syntax of a language in that language itself
> > that's the problem?
> 
> No no. That is not itself a problem. There is nothing intrinsically wrong with reification. The harm comes from its being used to do the wrong thing. 
> 
> > I think one of the reasons this is a perpetual source of tension in the
> > RDF community is that a tenet of RDF is that you can (and *should*) talk
> > about everything using these triples.   And now someone tells us, well,
> > everything EXCEPT the syntactic expressions of the language itself!
> > That's a little awkward.
> 
> It is fine use RDF to describe RDF, if that really is what you want to do. But it almost never is, is the point.

I wonder if we're close to some succinct consensus text about RDF
reification, now.    Something like:

        In logic languages, include RDF, "reification" is a
        sophisticated and error-prone technique where instead of
        asserting knowledge about some domain of discourse, one asserts
        knowledge about expression of the language itself.    While
        reification can be useful, is is often misunderstood and is easy
        to misuse.   With the latest RDF specifications (@@@tbd), new
        mechanisms are provided which provide similar functionality to
        reification but in a more direct and safe manner.  We recommend
        in nearly all cases these alternatives be used instead.
        
        Some of the problems with RDF 2004 reification include:
        
        * Confusion about whether two RDF statements with the same
        subject, predicate, and object are the same statement.   (In RDF
        2004, they are not.)
        
        * No standard way to gather RDF statements together to form RDF
        graphs.
        
        * Referential transparency (instead of opacity), which can lead
        to surprising results in the presence of inference.  For
        example, if statements are made about a particular triple
        (S,P,O) and a reasoner determines S=SS, then it is
        (counter-intuitively) licensed to infer those statements are
        also true about triple (SS,P,O). 
        
        * Inefficiency: using a straightforward implementation, 3-6
        times as many triples are needed to enable referring to existing
        triples.
        
        * Potential for paradoxical or ill-defined meaning of
        oddly-formed and self-referential constructs
        
How's that for a start?      Obviously some of this is going to need to
be refined once we figure out what's really happening with GRAPHS.

     -- Sandro

Received on Tuesday, 12 April 2011 17:54:39 UTC