Unicity of triples in RDF* (was Re: RDF* and grouping relation properties)

Thanks Olaf for the clarification. Picking up on that other thread, I have
a related question. What about:

<<:a :b :c>> :assertedBy :alice.
<<:a :b :d>> :assertedBy :bob.
:c owl:sameAs :d.

Note that the use of owl:sameAs here is just for convenience. You could
replace that by any (set of) triple(s) entailing that :c and :d denote the
same thing (e.g. using a functional property, or whatever).

My question being: in such a graph where :c and :d denote the same thing,
do <<:a :b :c>> and <<:a :b :d>> denote the same triple or not?

In other words, are <<...>> brackets meant to be referencially opaque
<https://en.wikipedia.org/wiki/Opaque_context> [1]?

[1] https://en.wikipedia.org/wiki/Opaque_context

On Tue, 23 Jun 2020 at 10:44, Olaf Hartig <olaf.hartig@liu.se> wrote:

> Dear Tim,
>
> Apologize the late reply (the overhead of teaching and examining in
> distance
> mode is continuing to destroy any of my plans).
>
> I think your original question about RDF*, and Peter's follow-up request
> for a
> pointer to a document, has not been fully answered yet. So, here is my
> view.
>
> In a nutshell, your observation is right: In RDF* you cannot directly
> separate
> the statements about a triple into multiple groups. For use cases in which
> you
> need such a separation, you can do it indirectly by grouping the
> properties
> under a separate resource (as you do in your blank node entity approach).
>
> The crux of the matter is the following key idea of the RDF*/SPARQL*
> approach:
> Assuming a desire to keep the notion of triples as the atomic element of
> the
> data model, the idea is to use a statement itself for making statements
> about
> it (instead of using a separate resource as a proxy, or some form of
> explicit
> statement identifiers). The RDF* data model implements this idea by
> allowing
> for (nested) triples that have another triple in their subject position or
> in
> their object position [1, Sec.2.1]. As a consequence, an RDF* graph is
> still a
> set of triples, even if some of them are nested.
>
> The way you may use Turtle-style shorthand notation to group such triples
> in a
> Turtle* serialization is just for convenience [2, Sec.3.3]. In fact, the
> same
> holds for the standard Turtle serializations: If you write something like
> the
> following, you only have a single set of statements about ex:alice (rather
> than two separate groups of statements).
>
> ex:alice
>       rdf:type  ex:SoccerPlayer ;
>       ex:team  ex:real ;
>       ex:favoritePosition  ex:forward .
> ex:alice
>       rdf:type  ex:Chef ;
>       ex:favoriteDish  ex:biryani .
>
>
> Best regards,
> Olaf
>
> [1] Olaf Hartig: Foundations of RDF* and SPARQL* - An Alternative Approach
> to
> Statement-Level Metadata in RDF. In Proceedings of the 11th Alberto
> Mendelzon
> International Workshop on Foundations of Data Management (AMW),
> Montevideo,
> Uruguay, June 2017
> http://olafhartig.de/files/Hartig_AMW2017_RDFStar.pdf
>
> [2] Olaf Hartig and Bryan Thompson: Foundations of an Alternative Approach
> to
> Reification in RDF. In CoRR abs/1406.3399, Jun. 2014
> http://arxiv.org/pdf/1406.3399
>
>
> On torsdag 18 juni 2020 kl. 11:44:02 CEST Tim Finin 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 .
> >
> > 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
>
>
>
>