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

On Fri, 2011-04-08 at 04:48 +0200, Ivan Herman wrote:
> As an aside, I would love to use a different example that this superman. I have never watched these superman movies, so all this symbols are just abstract entities to me, which does not help understanding the issues...

IANAL (I am not a logician) but I've seen three examples commonly used.
Frege used the fact that "the morning star" and "the evening star" both
refer to Venus.  Wikipedia [1] uses Superman/ClarkKent and also
Cicero/Tully.

I'm expecting to learn more about this in the Provenance Working Group,
but mostly I'm thinking one should use the g-text (some bytes you can
securely hash if necessary) if you really need opacity.   

So, then, what's wrong with RDF reification, if referential transparency
is acceptable?  Well, picking perhaps the easiest [GRAPHS] use case
("Exchanging the contents of RDF stores" [2]), how would you serialize a
simple RDF dataset?  Maybe:

<u1> { <a> <b> 1, 2 }
<u2> { <a> <c> 3, 4 }

would be:

<u1> eg:enumeration ( [ rdf:subject <a>; rdf:predicate <b>; rdf:object 1 ],
                      [ rdf:subject <a>; rdf:predicate <b>; rdf:object 2 ] ).

<u2> eg:enumeration ( [ rdf:subject <a>; rdf:predicate <c>; rdf:object 3 ],
                      [ rdf:subject <a>; rdf:predicate <c>; rdf:object 4 ] ).

I think that *works* - we just needed to invent one predicate.  And
each quad turns into about five triples.   We could make it a just four
triples if we didn't care to say u1 and u2 have *only* these triples:

<u1> eg:hasTriple [ rdf:subject <a>; rdf:predicate <b>; rdf:object 1 ],
                  [ rdf:subject <a>; rdf:predicate <b>; rdf:object 2 ].

<u2> eg:hasTriple [ rdf:subject <a>; rdf:predicate <c>; rdf:object 3 ],
                  [ rdf:subject <a>; rdf:predicate <c>; rdf:object 4 ].

So, why do SPARQL folks prefer TriG and N-Quads to these forms?  I don't
know.    

One guess might be concern about handing the input efficiently in the
cases where the input triples are not localized.  If you put that into
N-Triples and sort it by predicate, performing the import is going to
require holding the entire structure in memory.  But a valid response
might be, "don't do that".  (That is, keep the bnodes localized as they
would be turtle or rdf/xml that avoided node ids, if you want
de-serialization to be a streaming operation.)

Another guess: it just seems kind of bulky for no real benefit.   This
is amusingly just what non-RDF-folks feel whenever faced with RDF
syntaxes before they need the benefits.  ;-)

Another guess -- in Lee's case, he's talk about them hand editing
TriG.  

One could imagine { ... } being defined to be syntactic sugar for
[ eg:enumeration ( [ rdf:subject ...; rdf:predicate; ... ]
[ ... ] ... ) ]

But, yes, referential transparency might be a problem, depending how one
is going to use these structures.

      -- Sandro

[1] http://en.wikipedia.org/wiki/Opaque_context 
[2]
http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#Exchanging_the_contents_of_RDF_stores
   
> I.
> 
> ----
> Ivan Herman
> Tel:+31 641044153
> http://www.ivan-herman.net
> 
> 
> 
> On 8 Apr 2011, at 02:43, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> > * 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 04:42:42 UTC