Re: RDF* and grouping relation properties

Hi Tim,

I’m a bit relieved that Pat mostly took my side ;-) Just one addition: the section 3.3.1 in RDF 1.1 MT that you cite starts with "Semantic extensions MAY limit the interpretation of these so that..".   So it offers a proposal how semantic extensions or applications or out-of-band arrangements may make use of the reification vocabulary in useful or intuitive ways. But to be honest: I wasn’t aware. I believe the RDF 1.0 Primer supports my version and it’s also the way Pat explained it to me on semantic-we@w3.org two years ago.

Regarding your question about reasoners: no, I didn’t check. I wonder: does a test suite for reification semantics exist to check reasoners against?

Thomas


> On 21. Jun 2020, at 21:18, Tim Finin <finin@umbc.edu> wrote:
> 
> Hi Thomas,
> 
> Thanks for your thoughts on this issue. I've come to the conclusion that it may be best practice in both RDF or RDF* to bundle a set of property-value pairs as a blank node. However, I'm not sure of your view of the RDF semantics for a reified triple.
> 
> Section 3.3.1https://www.w3.org/TR/rdf-mt/#Reif of the W3C RDF Semantics recommendation has this example, which seems to contradict the view that two rdf:Statement instances with the same subject, predicate and object properties are owl:sameAs   
> 
> Since the relation between triples and reifications of triples in any RDF graph or graphs need not be one-to-one, asserting a property about some entity described by a reification need not entail that the same property holds of another such entity, even if it has the same components. For example,
> 
> _:xxx rdf:type rdf:Statement .
> _:xxx rdf:subject <ex:subject> .
> _:xxx rdf:predicate <ex:predicate> .
> _:xxx rdf:object <ex:object> .
> _:yyy rdf:type rdf:Statement .
> _:yyy rdf:subject <ex:subject> .
> _:yyy rdf:predicate <ex:predicate> .
> _:yyy rdf:object <ex:object> .
> _:xxx <ex:property> <ex:foo> .
> 
> does not entail
> 
> _:yyy <ex:property> <ex:foo> .
> 
> The RDF 1.1 Semantics recommendation section on Reification also includes this same example.
> 
> When I was first wondering about this I checked the Stardog implementation and found this was the case for my example.  I've just now checked the Hermit and Pellet reasoners via Protege and found that they also do not infer that the two Statement instances are owl:sameAs. Are you familiar with any developed reasoners that do infer this?
> 
> Tim
> 
> 
> On Sun, Jun 21, 2020 at 6:14 AM thomas lörtsch <tl@rat.io> wrote:
> 
> 
> > On 18. Jun 2020, at 17:44, Tim Finin <finin@umbc.edu> wrote:
> > 
> > While experimenting with RDF* I realized one issue: for some relations, we may have several properties that should be treated as a group.  For example, the provenance of a relation extracted from the text of a web page might include a link to the page and the date retrieved.
> > 
> > Using the following two RDF* expressions merges the four properties so that we can no longer determine which :source and :retrieved values go together.
> > 
> > << :man :hasSpouse :woman >>
> >     :source <http://foo.com/>;
> >     :retrieved "2020-06-17"^^xsd:date .
> > << :man :hasSpouse :woman >>
> >     :source <http://bar.com/>;
> >     :retrieved "2020-01-01"^^xsd:date .
> > 
> > Using a traditional RDF reification approach maintains the pairing.
> > 
> > :man2 :hasSpouse :woman2 .
> > [ ]  a rdf:Statement ;
> >      rdf:subject :man2 ;
> >      rdf:predicate :hasSpouse ;
> >      rdf:object :woman2 ;
> >     :source <http://foo.com/> ;
> >     :retrieved "2020-06-17"^^xsd:date .
> > [ ] a rdf:Statement ;
> >     rdf:subject :man2 ;
> >     rdf:predicate :hasSpouse ;
> >     rdf:object :woman2 ;
> >    :source <http://bar.com/>;
> >    :retrieved "2020-01-01"^^xsd:date .
> 
> In my understanding of the RDF Standard Reification semantics your two blank nodes are owl:sameAs as the reification quad refers to the abstract triple type, not any concrete token. That contradicts the intuition of the provenance statements (:source and :retrieved) but that’s just how things are right now in RDF. There is no sound meta modelling in RDF.
> 
> It would of course be possible to define subclasses of rdf:Statement, like rdf:TripleType and rdf:TripleToken, define a context (e.g. a Named Graph) in which a triple becomes an actual token, and then reify such tokens. Only then the above provenance statements would have sound semantics.
> 
> To the best of my knowledge RDF* binds its reification semantics back to RDF Standard Reification. The RDF* <<…>> construct is syntactic sugar for the RDF Standard Reification quadlet - nothing more, nothing less [0]. So merging those provenance statements is indeed the right thing to do. One might even argue that RDF* has a slight advantage over RDF Standard Reification as it represents the semantics more faithfully. However not what anybody would expect from the solution to reification in RDF.
> 
> Thomas
> 
> 
> [0] Well, not exactly, as there are those modes too - SA and PG - which may implicitly add the cited triple to the graph or not. That’s a proposal and I’m not sure if implementations support mode switching or which mode(s) they support. 
> 
> 
> 
> > A possible solution when using RDF* is to encapsulate associated properties as a blank node entity, as in the following
> > 
> > :man3 :hasSpouse :woman3 .
> > << :man3 :hasSpouse :woman3 >>
> >     :provenance [ :source <http://foo.com/>;
> >                            :retrieved "2020-06-17"^^xsd:date ] .
> > << :man3 :hasSpouse :woman3 >>
> >     :provenance [ :source <http://bar.com/>;
> >                            :retrieved "2020-01-01"^^xsd:date ] .
> > 
> > However, this approach seems to violate the normal key/value pattern of property graph properties, which could be a compatibility issue.
> 
> > 
> > 
> > --
> > Tim Finin,  Willard and Lillian Hackerman Chair in Engineering,  Computer Science and
> > Electrical Engineering, U. Maryland, Baltimore County, 1000 Hilltop Circle, Baltimore MD
> > 21250. http://umbc.edu/~finin, finin@umbc.edu, tfinin@gmail.com, mobile:410-499-3522
>

Received on Sunday, 21 June 2020 22:31:10 UTC