W3C home > Mailing lists > Public > public-rdf-star@w3.org > June 2020

Re: RDF* and grouping relation properties

From: Olaf Hartig <olaf.hartig@liu.se>
Date: Tue, 23 Jun 2020 10:44:05 +0200
To: public-rdf-star@w3.org
Cc: Tim Finin <finin@umbc.edu>
Message-ID: <1632648.caxdHMKKLu@porty3>
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).

      rdf:type  ex:SoccerPlayer ;
      ex:team  ex:real ;
      ex:favoritePosition  ex:forward .
      rdf:type  ex:Chef ;
      ex:favoriteDish  ex:biryani .

Best regards,

[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

[2] Olaf Hartig and Bryan Thompson: Foundations of an Alternative Approach to 
Reification in RDF. In CoRR abs/1406.3399, Jun. 2014

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

This archive was generated by hypermail 2.4.0 : Tuesday, 23 June 2020 08:44:27 UTC