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

Your question does not make sense as written, as far as I can tell, but your
basic thrust can be answered.


From
https://www.researchgate.net/publication/316686429_Foundations_of_RDF_and_SPARQL_An_Alternative_Approach_to_Statement-Level_Metadata_in_RDF
there is no denotational semantics for RDF* itself.  Instead there is a kind
of semantics for RDF* in terms of SPARQL* query results.  Then there are
mappings from RDF* to RDF that preserve these query results (with
adjustments).  So no denotation in RDF*.


RDF does have a denotational semantics but there is nothing that forces
triples to be in the domain of discourse.  Instead RDF has a class
rdf:Statement, whose denotation is (like every other class in RDF and RDFS)
nothing more than a subset of the domain of discourse, i.e, these elements can
be triples or quads or abstract claims or abstract statings of claims or .... 
So your question can be answered in the RDF that results from an RDF*-to-RDF
mapping.  Lets consider the "standard" mapping, where an RDF* embedded triple
is mapped into an RDF statement.

Suppose that we were working in an extension of RDF that knows it is a mapping
from RDF* where assertions of co-denotation are possible (i.e., owl:sameAs was
forced to be the identity function).   This extension could require that there
is only one statement with the same subject, predicate, and object; it could
require that the denotation of an RDF* triple be the triple itself (using some
rather weird machinery) so that the denotations of different triples were
different domain elements;  or it could not put any requirements on the
denotation of statements, or it could even do something else.


So,

TL;DR: Not necessarily, but it is possible to arrange for any answer you want.


peter


On 6/23/20 9:40 AM, Pierre-Antoine Champin wrote:
> 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
> <mailto: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 <mailto:finin@umbc.edu>,
>     tfinin@gmail.com <mailto:tfinin@gmail.com>,
>     > mobile:410-499-3522
>
>
>

Received on Tuesday, 23 June 2020 15:19:28 UTC