Re: RDF* and grouping relation properties

Hi Thomas,
Regarding your last question on the test suite for reification.
I've just found this report
https://www.w3.org/2013/rdf-mt-reports/index.html where there are 4 tests
"statement-entailment-test-00X" X=[1-4]

Not sure if they cover the current use-case

Best,
Ghislain

 On Mon, Jun 22, 2020 at 12:31 AM thomas lörtsch <tl@rat.io> wrote:

> 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
> >
>
>
>

-- 

"*Love all, trust a few, do wrong to none*" (W. Shakespeare)
Web: http://atemezing.org