Re: RDFn

Hi Peter and Olaf,

Thanks for the questions you sent. Below I outline my current thoughts on these. Please note that not everything I say below is written in stone. Things could change based on discussions or feedback from the WG members.

Peter wrote:
>> except that the interaction between triples and edges is unclear.
>> Does an edge entail the triple that is its first three components?

Souri answers:
Trying to keep things simple, I am trying to keep the (existence-based) "conceptual" graph (involving triples) and the (occurrence-based) "physical" graph (involving edges) as independent as possible. So, my current thought is that the presence or absence of an (s, p, o) triple should have no bearing on the presence or absence of an (s, p, o, n) edge and vice-versa.

Peter wrote:
>> Does a SPARQL query for :a :b :c . match :a :b :c :n. ?

Olaf wrote:
>Regarding the latter question, I understand that Souri also has in mind
to extend SPARQL with a notion of "edge patterns" that are meant to
match RDFn edges in an RDFn graph. Yet, even with such edge patterns,
the question that Peter asks remains.

Souri answers:
No, a triple-pattern, say ?s ?p ?o, will not match any edges. Similarly, an edge-pattern, say ?s ?p ?o | ?n, will not match any triples.

Peter wrote:
>> But why the first note?  There doesn't seem to be any issue with circular naming.

Olaf wrote:
>I think the issue is not about circular naming but about circular use
of such names. For instance, there may be the following two RDFn edges,
where the first one has the name of the second one as its subject and
the second one has the name of the first one as its subject.

> (:n2, :p, :o, :n1)
> (:n1, :pp, :oo, :n2)

Souri answers:
That's exactly what I meant – "circular use of such names" – as Olaf put it.

Olaf wrote:
> Another question that I would add to the ones that Peter asks:
Regarding the functional dependency mentioned in the third note in
Section 3.1.2, what is the scope of the constraint expressed by this
FD? Does this constraint need to hold only among the RDFn edges within
a given RDFn graph or is it supposed to be of some global nature?
(Notice that this question is relevant only for edge names that are
IRIs, not for edge names that are blank nodes.)

Souri answers:
This question came up in my mind too as I wrote about the FD: n -> (s, p, o). I thought that the scope of the FD constraint should be local to a single RDFn graph. Thus, in two different RDFn graphs, one can use the same IRI, say :e, to name two distinct edges: (:s1, :p1, :o1, :e) in graph :G1 and (:s2, :p2, :o2, :e) in graph :G2.

If the two graphs :G1 and :G2 are being merged, an exception will be raised about the violation of the FD. If both those graphs are part of the same dataset (being queried), then a SPARQL query having FROM :G1 FROM :G2 will raise an exception, but otherwise would work fine (see Example 1 below). A multi-graph SPARQL query against this dataset could exploit such shared naming to retrieve each of the corresponding edges (one per graph) from those two graphs (see Example 2 below).

Example 1:
SELECT ?g ?s ?p ?o ?n
{  graph ?g { ?s ?p ?o | ?n } }

Example 2:
SELECT ?s1 ?p1 ?o1 ?o1a
             ?s2 ?p2 ?o2 ?o2a
WHERE {
  graph :G1 { ?s1 ?p1 ?o1 | ?n . ?n :p1a ?o1a }
  graph :G2 { ?s2 ?p2 ?o2 | ?n . ?n :p2a ?o2a }
}

--------------
My hope is that we'll be able to come up with RDF1.2 that is:
- backward-compatible: does not break anything that the current users may be using
- simple: is simple to use because of easy mapping of concepts to the prevalent mental models amongst (RDF and PG) graph users
- capable: has enough capabilities to easily support all popular usage scenario (leaving out niche use cases, esp. if supporting those would add significantly to complexity)
- implementable: allows reasonably efficient implementation even when data size and/or query complexity goes up

Thanks,
Souri.
________________________________
From: Olaf Hartig <olaf.hartig@liu.se>
Sent: Thursday, January 4, 2024 1:36 PM
To: public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
Subject: [External] : Re: RDFn

On Thu, 2024-01-04 at 11:45 -0500, Peter F. Patel-Schneider wrote:
> Thanks.  I think I understand this RDFn,

I agree. Thanks Souri for providing this recent document which makes
the fundamental concepts that you have in mind more clear.

> except that the interaction between triples and edges is unclear.
> Does an edge entail the triple that is its first three components?
> Does a SPARQL query for :a :b :c . match :a :b :c :n. ?

These are also the two questions that came to my mind when reading
Souri's recent document.

Regarding the latter question, I understand that Souri also has in mind
to extend SPARQL with a notion of "edge patterns" that are meant to
match RDFn edges in an RDFn graph. Yet, even with such edge patterns,
the question that Peter asks remains.

> But why the first note?  There doesn't seem to be any issue with
> circular naming.

I think the issue is not about circular naming but about circular use
of such names. For instance, there may be the following two RDFn edges,
where the first one has the name of the second one as its subject and
the second one has the name of the first one as its subject.

 (:n2, :p, :o, :n1)
 (:n1, :pp, :oo, :n2)


Another question that I would add to the ones that Peter asks:
Regarding the functional dependency mentioned in the third note in
Section 3.1.2, what is the scope of the constraint expressed by this
FD? Does this constraint need to hold only among the RDFn edges within
a given RDFn graph or is it supposed to be of some global nature?
(Notice that this question is relevant only for edge names that are
IRIs, not for edge names that are blank nodes.)

Best,
Olaf


> peter
>
>
> On 1/3/24 19:23, Souripriya Das wrote:
> > Hi Adrian,
> >
> > Attached is the PDF for Sec 3 and Sec 4 – except for the addition
> > of section
> > 3.1.2 (RDFn Edges), hardly anything changed.
> > We can use this as reference, but the email I sent on Jan 1^st
> >  captured all
> > of these changes anyway.
> >
> > Note that the extension to SPARQL would be to support "edge
> > patterns" (that
> > would correspond to RDFn Edges).
> >
> > Thanks,
> > Souri.
> >
> > -------------------------------------------------------------------
> > -----------
> > *From:* Adrian Gschwend <adrian.gschwend@zazuko.com>
> > *Sent:* Wednesday, January 3, 2024 3:04 PM
> > *To:* public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
> > *Subject:* [External] : Re: Event Updated: RDF-star WG biweekly
> > long meeting
> > On 03.01.24 17:12, Adrian Gschwend (W3C Calendar) wrote:
> >
> > > 1. Discussion of Andy's updated post [1]
> >
> > If there are any other updates, let us know.
> >
> > @Souri IIRC you wanted to write down more details as well, did you
> > had
> > time to do it already?
> >
> > regards
> >
> > Adrian
> >
> > --
> > Adrian Gschwend
> > CEO Zazuko GmbH, Biel, Switzerland
> >
> > Phone +41 32 510 60 31
> > Email adrian.gschwend@zazuko.com
> >
> >
>