Re: RDF-ISSUE-25 (Deprecate Reification): Should we deprecate (RDF 2004) reification? [Cleanup tasks]

* Sandro Hawke <sandro@w3.org> [2011-04-07 18:23-0400]
> On Thu, 2011-04-07 at 18:18 -0400, David Wood wrote:
> > On Apr 7, 2011, at 18:07, RDF Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
> > 
> > > 
> > > RDF-ISSUE-25 (Deprecate Reification): Should we deprecate (RDF 2004) reification? [Cleanup tasks]
> > > 
> > > http://www.w3.org/2011/rdf-wg/track/issues/25
> > > 
> > > Raised by: Sandro Hawke
> > > On product: Cleanup tasks
> > > 
> > > 
> > > The RDF 1999 and 2004 Recommendations include vocabulary and syntax
> > > (in RDF/XML) for RDF "reification".  The vocabulary is rdf:Statement,
> > > rdf:subject, rdf:predicate, and rdf:object; the syntax is rdf:ID used
> > > on a property element.
> > > 
> > > Although this feature is sometimes used in practice, some experts
> > > advise data providers to avoid it.  It has no syntactic support in
> > > RDFa or Turtle.  Should the WG align with this advice and say this
> > > feature is only to be use for backward compatibility?  (That is,
> > > RDF/XML parsers must continue to support the syntax, and libraries
> > > should allow applications to use the features to interoperate with
> > > legacy RDF systems.)
> > > 
> > > Note that many or all of the use cases of reification are also uses
> > > cases for [GRAPHS].  The decision about the fate of reificiation is
> > > connected with what happens with [GRAPHS].
> > 
> > 
> > Might reification undergo a renaissance when provenance comes back into fashion?  Couldn't we consider reification a degenerate case of a named graph?
> > 
> > We might want to go slowly on this one...
> 
> I think it's one of the candidate solutions for the GRAPHS use cases.
> My guess is it's unlikely to survive, but who knows.  :-)
> 
> Maybe I should move it from [Cleanup tasks] to [GRAPHS] ?

People objected to reification for inference and syntax reasons.

INFERENCE
The inference issues boil down to the fact that rules applicable to a
flat graph must be transformed when applied to a reified graph. The
principle exemplar being owl:sameAs:
  <LoisLane> <says> [ rdf:s <Superman> ; rdf:p <can> ; rdf:o <fly> ] .
  <Superman> owl:sameAs <ClarkKent> .
Applying the sameAs to the reified graph tells you that Lois Lane says
that Clark Kent can fly, just as it would if you applied it to all
symbols in
  <SYSTEM> { <LoisLane> <uttered> <G1> . }
  <G1> { <Superman> <can> <fly> . }

If we want use graphs for quoting, we have to be judicious about the
application of sameAs. Perhaps we want our <SYSTEM> to infer that if
  <Superman> <canBeatUp> <LexLuther> .
then
  <ClarkKen> <canBeatUp> <LexLuther> .
Of course, we can be equally judicious about the application of sameAs
in the reified world, using a rule like:
  { ?X owl:sameAs ?Y .
    <SYSTEM> <holds> [ rdf:s ?X ; rdf:p ?p ; rdf:o ?o ] . }
  => 
  { <SYSTEM> <holds> [ rdf:s ?Y ; rdf:p ?p ; rdf:o ?o ] . }

In short, I'm not convinced that named graphs offers any more quoting
ability than reification. We just can't mix reified and non-reified
statements. (More precisely, we need to know which statements are
reified, much as we need to know if an statement is inside {}s.)


SYNTAX
We can define a predicate <uttered> to encode quoting in named graphs:
  uttered: asserts that the subject asserted all of the statements
           in the graph named in the object.
  <SYSTEM> { <LoisLane> <uttered> <G1> .
             <Superman> <canBeatUp> <LexLuther> .}
  <G1> { <Superman> <can> <fly> . }
or reification:
  uttered: asserts that the subject asserted the dereification of the
           objects of the <holds> arc from the object. [wordsmithing opportunity]
  <SYSTEM> <holds> [ rdf:s <LoisLane> ; rdf:p <uttered> ; rdf:o <G1> ] ,
                   [ rdf:s <Superman> ; rdf:p <canBeatUp> ; rdf:o <LexLuther> ] .
  <G1> <holds> [ rdf:s <Superman> ; rdf:p <can> ; rdf:o <fly> ] .
or more simply in N3:
  uttered: asserts that the subject asserted the statements in the object.
  <SYSTEM> <holds> { <LoisLane> <uttered> { <Superman> <can> <fly> . } .
                     <Superman> <canBeatUp> <LexLuther> . } .

What happens when Lois says that Lex says that Superman can fly?
name graphs:
  <SYSTEM> { <LoisLane> <uttered> <G1> .
             <Superman> <canBeatUp> <LexLuther> . }
  <G1> { <LexLuther> <uttered> <G2> . }
  <G2> { <Superman> <can> <fly> . }
reification:
  <SYSTEM> <holds> [ rdf:s <LoisLane> ; rdf:p <uttered> ; rdf:o <G1> ] ,
                   [ rdf:s <Superman> ; rdf:p <canBeatUp> ; rdf:o <LexLuther> ] .
  <G1> <holds> [ rdf:s <LexLuther> ; rdf:p <uttered> ; rdf:o <G2> ] .
  <G2> <holds> [ rdf:s <Superman> ; rdf:p <can> ; rdf:o <fly> ] .
n3:
  <SYSTEM> <holds> {
    <LoisLane> <uttered> {
      <LexLuther> <uttered>  {
        <Superman> <can> <fly> . } . } .
    <Superman> <canBeatUp> <LexLuther> . }

SPARQL syntax might lead us to believe that queries can use nesting to
match she-said-he-said quotes, but I don't think there's any distinction
between (here arbitrarily promoting <SYSTEM> to the default graph):
  ASK {
    ?she <uttered> ?g1
    GRAPH ?g1 {
      ?he <uttered> ?g2
      GRAPH ?g2 {
        <Superman> <can> <fly>
      }
    }
  }
and
  ASK {
    ?she <uttered> ?g1
    GRAPH ?g1 {
      ?he <uttered> ?g2
    }
    GRAPH ?g2 {
      <Superman> <can> <fly>
    }
  }

The real challenge for named graphs comes when we don't have names for
our speach acts. Reification causes no problem:
  <SYSTEM> <holds> [ rdf:s <LoisLane> ; rdf:p <uttered> ; rdf:o _:g1 ] .
  _:g1 <holds> [ rdf:s <LexLuther> ; rdf:p <uttered> ; rdf:o _:g2 ] .
but names graphs requires bnode scope to escape the graph boundries:
  <SYSTEM> { <LoisLane> <uttered> _:g1 . }
  _:g1 { <LexLuther> <uttered> _:g2 . }
Critics of bnodes will no doubt say "invent names for your speach acts",
but "honor the names you invented" is a pretty heavy burden compared to
having to write out reification.

-- 
-ericP

Received on Friday, 8 April 2011 00:43:33 UTC