Re: [External] : labelled property graphs vs -star extension of RDFn vs -star extension of named graphs

Souri,

If I understand this correctly, loading twice a document with a single triple (with no explicit name, so let’s say an RDF 1.1 document) results in two triples in the store? I am just trying to understand the ramifications to graph merging (something I think really sets RDF apart from LPGs).

Ora


From: Souripriya Das <souripriya.das@oracle.com>
Date: Tuesday, December 12, 2023 at 7:09 AM
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, RDF-star Working Group <public-rdf-star-wg@w3.org>
Subject: RE: [EXTERNAL] [External] : labelled property graphs vs -star extension of RDFn vs -star extension of named graphs
Resent-From: <public-rdf-star-wg@w3.org>
Resent-Date: Tuesday, December 12, 2023 at 7:08 AM


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


Hi Peter,

Since Ted recently commented on my linkedin posting dated 21-SEP-2021 [1]  asking if I had any updates on RDFn draft spec, I worked through the weekend to create a new set of slides based on my latest thoughts on this and posted the slides on linkedin [2] yesterday (dated 11-DEC-2023):  Slides 3-5 cover the concepts, 6-7 show examples, 8-11 compare with RDF-star.

Although the syntax was tweaked a bit in the new version, the basic idea did not change: RDF's <s, p, o> is extended to <s, p, o, n> where n is an IRI representing the name of the triple (or, tName). This easily accommodates the LPG case that you mentioned and goes beyond LPG.

LPG:
:liz :spouse :dick {| :start 1964; :end 1974 |} .
:liz :spouse :dick {| :start 1975; :end 1976 |} .

RDFn: (one of the two tNames could be an auto-generated name, but I used custom-name for both just for simplicity):
:liz :spouse :dick | :term1 .
:liz :spouse :dick | :term2 .
:term1 :start 1964; :end 1974 .
:term2 :start 1975; :end 1976 .

Of course, LPG cannot easily do the following that we can in RDFn:
:term1 :happierThan :term2 .

Thanks,
Souri.

[1] https://www.linkedin.com/posts/souripriya-souri-das-ph-d-48801911_rdfn-name-every-triple-or-quad-manually-activity-6846069087068540928-IKdd?utm_source=share&utm_medium=member_desktop


[2] https://www.linkedin.com/posts/souripriya-souri-das-ph-d-48801911_rdfn-rdf-extension-for-unasserted-and-named-activity-7140162410769702912-kuqg?utm_source=share&utm_medium=member_desktop

[cid:image001.png@01DA2E5D.873AB9E0]<https://www.linkedin.com/posts/souripriya-souri-das-ph-d-48801911_rdfn-rdf-extension-for-unasserted-and-named-activity-7140162410769702912-kuqg?utm_source=share&utm_medium=member_desktop>

Souripriya (Souri) Das, Ph.D. on LinkedIn: RDFn: RDF Extension for Unasserted and Named Triples<https://www.linkedin.com/posts/souripriya-souri-das-ph-d-48801911_rdfn-rdf-extension-for-unasserted-and-named-activity-7140162410769702912-kuqg?utm_source=share&utm_medium=member_desktop>
RDFn: A Backward-Compatible RDF Extension for Unasserted and Named Triples.
www.linkedin.com



[cid:image001.png@01DA2E5D.873AB9E0]<https://www.linkedin.com/posts/souripriya-souri-das-ph-d-48801911_rdfn-name-every-triple-or-quad-manually-activity-6846069087068540928-IKdd?utm_source=share&utm_medium=member_desktop>

Souripriya (Souri) Das, Ph.D. on LinkedIn: RDFn: Name Every Triple or Quad: Manually or Automatically<https://www.linkedin.com/posts/souripriya-souri-das-ph-d-48801911_rdfn-name-every-triple-or-quad-manually-activity-6846069087068540928-IKdd?utm_source=share&utm_medium=member_desktop>
Attached a few slides* to go with my recently posted article [1] outlining a new version of RDFn (original version [2]) that minimizes the data creator’s…
www.linkedin.com



________________________________
From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Sent: Friday, December 8, 2023 9:18 AM
To: RDF-star Working Group <public-rdf-star-wg@w3.org>
Subject: [External] : labelled property graphs vs -star extension of RDFn vs -star extension of named graphs

At the teleconference yesterday I mentioned that there could be user-visible
differences between different views of how to proceed, even when there is some
consensus that different views are essentially the same.

Here is one example of a user-visible divergence.  Consider the following
input, written in the community group syntax.

:liz :spouse :dick {| :start 1964; :end 1974 |} .
:liz :spouse :dick {| :start 1975; :end 1976 |} .

In the community graph version of RDF-star this results in one asserted triple
with subject :liz that is the subject of four triples.  In SPARQL-star, the BGP

:liz :spouse :dick {| :start 1964; :end 1976 |} .

would match against a graph constructed from this input.

In labelled property graphs this would appear to result in two asserted
triples with subject :liz, each with two property-value pairs.  The above BGP
would not match.

So there is a decided visible difference between the community graph version
of RDF-star and labelled property graphs.

If I am correct in reading the (sparse) information available about RDFn, a
-star extension of RDFn would conform to the community group reading.  So
there would be noticeable differences between an extended RDFn and labelled
property graphs.

I am not aware of any proposal for using named graphs that says what the above
would result in there, so it is unclear which side a named graphs version of
-star would fit into.

peter