Re: RDF* and grouping relation properties

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

Received on Tuesday, 23 June 2020 08:44:26 UTC