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

Sandro Hawke wrote:
> On Thu, 2011-04-07 at 20:43 -0400, Eric Prud'hommeaux 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.
> 
> Are you saying the rdf Reification is a good solution to the [GRAPHS]
> use cases?   It sounds like it.

the or a?

One could also take {} syntax to be Set (rather than [] list) of RDF 
Statements, such that { <Superman> <can> <fly> } is a Set of one (RDF) 
Statement. It would have to be a Set because it's unordered and contains 
no duplicates. As indicated by the N3 example Eric posted above.

Which a simplified snippet of would be:

   <LexLuther> <uttered> { <Superman> <can> <fly> } .

(note, remember http://www.w3.org/DesignIssues/Reify.html )

Which really, is a lot like:

  <LexLuther> <uttered> [ rdf:s <Superman> ; rdf:p <can> ; rdf:o <fly> ] .

But {} is far more concise when you're dealing with / annotating more 
than one statement.

 From this point of view, that's why I prefer quoted graphs to both trig 
style named graphs, and traditional rdf reification.

aside:

If you couple this with the first bullet of [1] "we assume that the URI 
part (i.e. excluding fragment identifier) identifies a resource, which 
is presumed to have an RDF representation. So when eg:someurl#frag is 
used in an RDF document, eg:someurl is taken to designate some RDF 
document (even when no such document can be retrieved)."

.. and also create a specific property like x:author which had some 
special form of entailment (can't knock this up off the top of my head, 
you'll see why!), then..

.. given a "document" available at:
    <http://example.org/ivans-never/seen/superman>

with the content:

  <> x:author </me#LexLuther> .
  <#Superman> y:can y:fly .

It should be possible to see this as:

{ <#Superman> y:can y:fly }
   x:author </me#LexLuther> ;
   y:from <http://example.org/ivans-never/seen/superman> .

and infer:

   </me#LexLuther> x:uttered { <#Superman> y:can y:fly } .

But that's going off on a tangent I fear, that said, it would be 
interesting to view all names like that - <doc#id> as a pair of (doc, 
#id) - then when you're pulling data off the web, for each name in the 
graph, you can see whether the doc part matches the <doc> which you 
dereferenced, and if so establish that it's using that name 
"authoritatively" (for lack of a better word) ... couple that with 
following your nose to </me> to see if the x:author has asserted 
<#LexLuther> x:wrote </ivans-never/seen/superman> and you've got the 
makings of something pretty cool ... and couple that with a signature 
asserted in </ivans-never/seen/superman> which can be verified using a 
public key found in </me> and associated to </me#LexLuther> and things 
start getting very interesting (WOT?!).

Anyway, enough rambling!

[1] http://www.w3.org/TR/rdf-concepts/#section-fragID

Best,

Nathan

Received on Friday, 8 April 2011 23:24:09 UTC