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

Re: cheating about reification

From: Sergey Melnik <melnik@db.stanford.edu>
Date: Thu, 25 Oct 2001 17:54:46 -0700
Message-ID: <3BD8B456.49080C28@db.stanford.edu>
To: Pat Hayes <phayes@ai.uwf.edu>
CC: w3c-rdfcore-wg@w3.org
Pat Hayes wrote:
> 
> >Pat Hayes wrote:
> >>  ...
> >>  Right, but one would not use IEXT for reification. I introduced a
> >>  REIF mapping from the syntax into IR, but one could do it more simply
> >>  just by requiring IR to contain a suitable set of expressions, by
> >>  semantic fiat, so that REIF is defined to be the identity.
> >>
> >>  >
> >>  >What about the following addition to the MT. Let a ternary relationship
> >>  >Reif be defined as:
> >>  >
> >>  >1) IR x IR x (IR union LV) <= Reif
> >>  >2) If (x,y,z) in (IR union Reif) x IR x (IR union LV union Reif),
> >>  >    then (x,y,z) in Reif
> >>  >3) Reif is the smallest set with (1), (2)
> >>  >
> >>  >In other words, Reif contains all reified statements that can possibly
> >>  >be constructed under a given interpretation I.
> >>
> >>  Right, that is almost the version I had at the F2F. (I used a mapping
> >>  from the syntax into the domain, you use a three-place predicate
> >>  defined recursively on the domain.) However, it was resoundingly
> >>  criticized as not what reification actually means, in practice. (Dan
> >>  C. told me that this was what reification *ought* to have been, but
> >>  in fact it wasn't that.) I am still waiting to discover what
> >>  reification actually is, in practice (as opposed to what the M&S says
> >>  it is.)
> >
> >Maybe the confusion arose because in your original version reification
> >mapped directly from the syntax. I must confess that I thought (and
> >possibly other F2Fers did) that your definition treated reification as
> >some kind of special syntactic mapping that needs to be established in
> >addition to I.
> 
> Well, in a sense it is, though its an embedding rather than an
> interpretation (mention, not use!).
> 
> If I follow what Jeremy C. was saying in his whats-the-fuss-about
> message concerning reification, then *some* kind of embedding from
> the syntax seems to be essential, since the rdf:subject and
> rdf:object arcs both point and refer to the very pieces of syntax
> that are in the triple being reified. If we can find a way to avoid
> the use/mention confusion (and Im rapidly coming to think that we
> can, and it would be based on the same trick that we used to handle
> literal overloading, by allowing the objects of the reification arcs
> to be the nodes themselves, rather than what the node labels denote)
> then this would I think be able to handle reification in just the way
> that users intend it to be used. The resulting system would be a
> rather unorthodox logic, and the reification relations would have a
> very odd relationship to the syntax; but that is OK, since they do :-)

Sorry, I'm slow here. Why do we need to pull the pants over the head?
Please explain what the problem is with the following approach:

Given: four statement below.

	s  p             o
	id rdf:subject   s
	id rdf:predicate p
	id rdf:object    o

Possible interpretation:

	DD    = { I(s), I(p), I(o), ... } union Reif
	Reif  = { <I(s),I(p),I(o)>, ... }

	I(id) = <I(s),I(p),I(o)>

	IEXT(I(p)) = { <I(s),I(o)> }

	IEXT(I(rdf:subject))   = { < <I(s),I(p),I(o)>, I(s) > }
	IEXT(I(rdf:predicate)) = { < <I(s),I(p),I(o)>, I(p) > }
	IEXT(I(rdf:object))    = { < <I(s),I(p),I(o)>, I(o) > }

If you don't want to deal with Reif and identify the thingies
explicitly, the interpretation becomes:

	DD    = { I(s), I(p), I(o), I(id), ... }

	IEXT(I(p)) = { <I(s),I(o)> }

	IEXT(I(rdf:subject))   = { < I(id), I(s) > }
	IEXT(I(rdf:predicate)) = { < I(id), I(p) > }
	IEXT(I(rdf:object))    = { < I(id), I(o) > }

where I(id) is just some resource in DD.

Why is some kind of "embedding from the syntax" need? What is the
mention/confusion in the above interpretation? If we discard Reif, why
does reification require some special treatment in MT at all? I think
the above interpretation is consistent with the current MT draft.

Sergey
Received on Thursday, 25 October 2001 20:28:22 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:41:13 EDT