- From: Olaf Hartig <olaf.hartig@liu.se>
- Date: Thu, 26 Oct 2023 14:30:30 +0000
- To: "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
- CC: "tl@rat.io" <tl@rat.io>
On Thu, 2023-10-26 at 15:40 +0200, Thomas Lörtsch wrote: > > On 26. Oct 2023, at 15:14, Olaf Hartig <olaf.hartig@liu.se> wrote: > > [...] > > Let me focus only on the following part of it. > > > > []{:Alice :buys :Car} :purpose :Commuting ; > > :type :PickUp . > > > > Since you wrote that you consider a nested graph to be a pair > > consisting of an IRI or a blank node (considered as the name of the > > nested graph) and an RDF graph, I assume the nested graph that is > > serialized in this snippet of Turtle-like syntax is the pair (b,G) > > where b is an arbitrary blank node and G is the singleton RDF graph > > that contains the triple (:Alice, :buys, :Car); i.e., G={t}. > > Yes. > > > Next, it seems that this nested graph is the subject of two > > triples, but by the current definition of the notion of an RDF > > triple, that would not be possible (because the subject can only be > > an IRI or a blank node, not a nested graph). > > No. There is a misunderstanding. The notion > > > []{:Alice :buys :Car} :purpose :Commuting ; > > :type :PickUp . > > is syntactic sugar for > > [_:x]{:Alice :buys :Car} > _:x :purpose :Commuting ; > :type :PickUp . I see. But how was I or anyone else from the group supposed to know that? The text in your original email didn't say that and I also don't find anything explicit about it by skimming through your longer text. > So, no new term. Okay, no new kind of term. Yet, something else seems to be going on now that is diverging from the way things are defined in RDF Concepts 1.1. When I look at these three new lines of Turtle-like syntax that you wrote now and try to map these three lines to the concepts defined for RDF, I don't find a way to map the first line. My interpretation now is that these three lines are meant to be a serialization of some extended notion of an RDF graph, namely, a notion of an (extended) RDF graph that is a set consisting of RDF triples and nested graphs. Is this interpretation correct? Are you proposing to extend the definition of the notion of an RDF graph? > > Consequently, my interpretation is > > that you aim to extend the definition of the notion of an RDF > > triple > > such that the subject of an (extended) RDF triple may be a nested > > graph, an IRI, or a blank node. Assuming such an extension, the > > snippet > > of Turtle-like syntax above would then be a serialization of the > > following two (extended) triples. > > > > ( (b,G), :purpose, :Commuting ) > > ( (b,G), :type, :PickUp ) > > > > Does my interpretation up to this point match up with what you have > > in > > mind? > > No, see above. To put it more abstract: the name refers to the pair > of graph and name, which is essential to establish that: > A we are talking about tokens of graphs, not graph types and > B the name can not also refer to something else. > That is the construction of Named Graphs by Carroll et al 2005 (vulgo > Pat’s semantics), modulo referential opacity of the graph. > > I think this establishes precisely what the name in the name graph > pair refers to. An annotation to that name refers to that pair. Does the latter sentence imply that "an annotation to that name" does *not* refer to the RDF graph that is the second element of the pair? ... and it also does not refer to the triples that are contained in that RDF graph? > Now, the proposal defines more, namely fragment identifiers, to refer > to indivudual parts of the graph - subject(s), predicate(s), > object(s), triple(s), the graph itself - which [...] I see that, in your longer text, you provide a definition of the notion of a fragment identifier (namely, it can be one of five syntactic elements). However, at the moment, it is a standalone concept. I mean, I cannot find any definition that brings the notion of a fragment identifier and the notion of a nested graph together. Olaf > > I hope that helps, > Thomas
Received on Thursday, 26 October 2023 14:30:38 UTC