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

Hi Souri,


thank you for this new slide deck.

I’m still not convinced by the way you name statements. Users that don’t think about the often not so obvious differentiation between type and token will probably annotate a statement via its autogenerated name, which is a function of SPOG, ergo referring to the type per graph. It seems also that this is what you want to be the default. Do you gain anything by making the auto:name a function of (and by extension a reference to) the type itself? Is this an optimization? Do you not expect the multi-edge case to occur very often?
Why not hand out only token identifiers (auto-generated or custom) from the get-go? How often do you expect users to actually want to annotate the type (and not just provide the first and expectedly only annotation on a token of that type)? What if users forget to check if other annotations to the statement already exist? I assume that there will always be a strong inclination to use the already existing auto:name, and that from the second annotation on it will put the soudnness of the new annotation and the pre-existing annotation(s) at risk.

In the new slidedeck I noticed the first time that multiple statements, spread over different graphs, can have the same name. Is that new or did I just overlook it before? It seems like that would extend the expressivity of RDFn quite a bit. The next question would be if one statement can also have multiple names?

One last question: why do the names have to come from specific namespaces? Have you considered using blank nodes?


Best,
Thomas

> On 12. Dec 2023, at 13:08, Souripriya Das <souripriya.das@oracle.com> wrote:
> 
> 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<Outlook-hxqnw1ev.png>
> Souripriya (Souri) Das, Ph.D. on LinkedIn: RDFn: RDF Extension for Unasserted and Named Triples
> RDFn: A Backward-Compatible RDF Extension for Unasserted and Named Triples.
> www.linkedin.com
> 
> 
> <Outlook-rbi2ajmq.png>Souripriya (Souri) Das, Ph.D. on LinkedIn: RDFn: Name Every Triple or Quad: Manually or Automatically
> 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

Received on Tuesday, 12 December 2023 19:43:42 UTC