Re: Nested Graphs - a graph-based proposal

> On 26. Oct 2023, at 15:14, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> Hi Thomas,
> 
> I tried to understand your proposal, for which I find it important to
> have a clear, unambiguous idea of the concepts that your proposal aims
> to introduce. To this end, I asked you for a definition of the notion
> of a nested graph. You gave me one but that was too informal to be
> unambiguous. Therefore, I asked you how particular words in your
> definition are meant to be understood.
> 
> Instead of giving me an answer to these questions, you are insisting
> now that I look at your examples, which are examples that illustrate
> how the notion of a nested graph may be represented and used in a
> particular syntax. I don't find that very helpful because the examples
> do not tell me what a nested graph actually is (otherwise, I would not
> have asked in the first place). Or do you want me to come to my own
> interpretation of what the notion of a nested graph is, based on how
> you represent and use them in the examples? I wouldn't find that very
> helpful either, because my interpretation may not match up with your
> idea of a nested graph, which then also makes it pointless to try to
> discuss the questions of type vs token etc for nested graphs.
> 
> But let me try one more interpretation of your examples. The first
> example in your initial email looked as follows.
> 
> [:X]{
>     []{
>         []{:Alice :buys :Car} :purpose :Commuting ;
>                               :type :PickUp .
>     }   :source :Dean ;
>         :year 2015 .
>     []{
>         []{
>             []{:Bob :likes :Car}#o :ownedBy :Alice .
>             []{:Alice :buys :Car} :purpose :JoyRiding ;
>                                   :type :Coupe
>                                   :year 2023 .
>         } rdfs:comment "Alice's MGB" .
>     } :source :Eric.
> }
> :X :ingestedFrom :DataLake_127
> 
> 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 .

So, no new term.

> 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. 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 increases the expressivity of the construct and helps to disambiguate annotations on the whole graph (eg provenance) from those on the relation or individual nodes. The texts provided so far describe that and I will go into it in the Telco later today. But the essential part is that through the name that graph can be addressed, either in toto, or more targeted.

I hope that helps,
Thomas


> Olaf
> 
> 
> On Thu, 2023-10-26 at 13:53 +0200, Thomas Lörtsch wrote:
>> 
>> 
>>> On 26. Oct 2023, at 13:37, Olaf Hartig <olaf.hartig@liu.se> wrote:
>>> 
>>> On Thu, 2023-10-26 at 12:30 +0200, Thomas Lörtsch wrote:
>>>>> On 26. Oct 2023, at 09:49, Olaf Hartig <olaf.hartig@liu.se>
>>>>> wrote:
>>>>> 
>>>>> Hi Thomas,
>>>>> 
>>>>> On Wed, 2023-10-25 at 23:43 +0200, Thomas Lörtsch wrote:
>>>>>> [...]
>>>>>> A nested graph is a pair consisting of an IRI or a blank node
>>>>>> (the graph name), and an RDF graph.
>>>>> 
>>>>> Okay, according to this sentence, a nested graph is
>>>>> structurally
>>>>> the same as a named graph. Fine.
>>>>> 
>>>>>> The name denotes the pair of name and graph.
>>>>>> Nested graph names are unique within an RDF dataset.
>>>>>> A nested graph may contain other nested graphs, recursively.
>>>>> 
>>>>> This sentence is a bit too vague for a proper definition. It
>>>>> needs
>>>>> to be made more clear what exactly "may contain" means.
>>>>> 
>>>>> I assume it means that a nested graph ng = (n,G) may have
>>>>> another
>>>>> nested graph as the subject or the object of some triple in the
>>>>> RDF
>>>>> graph of ng. In other words, there may be a triple t=(s,p,o) in
>>>>> G
>>>>> such that s or o is another nested graph ng' = (n',G').
>>>>> 
>>>>> Is that what you mean?
>>>>> 
>>>>> If so, notice that you are introducing a new kind of term that
>>>>> can
>>>>> be used in RDF triples (in addition to IRIs, blank nodes, and
>>>>> literals)!
>>>> 
>>>> No, it’s not what I mean.
>>> 
>>> In this case, is it possible for you to adapt my attempt of
>>> defining
>>> your notion of "may contain" such that we have a definition that
>>> captures what you mean?
>>> 
>>>> A nested graph may occur as "stand alone" graph, not only in
>>>> subject-
>>>> or object position.
>>> 
>>> What does ''occur as "stand alone" graph'' mean? In particular,
>>> *where*
>>> else do you mean it may occur? As one of the named graphs of an RDF
>>> dataset?
>> 
>> No, it is ot a named graph. As I said and as the examples show, it
>> may occur inside the default graph or inside a named graph.
>> 
>>>> If it occurs in subject- or object-position, then that is
>>>> syntactic
>>>> sugar for separately stating it and making statements about it
>>>> (referenced through its name). [...]
>>> 
>>> I am not sure I understand exactly what you mean here. Can you
>>> please
>>> make the meaning of this sentence more accurate by defining a) what
>>> exactly the form of syntactic sugar is that you have in mind and b)
>>> how
>>> this form of syntactic sugar maps to a something that does not use
>>> this form of syntactic sugar. And please give this definition in
>>> terms
>>> of concepts that are well defined (IRIs, literals, blank nodes,
>>> triples, RDF graphs, etc) rather than based on some made-up Turtle-
>>> style syntax.
>> 
>> You asked for abstract definitions and I gave you one. Now you are
>> asking for a formal definition of the syntax. That I can’t give you
>> yet, but I think it is reasonably clear from the examples, at least
>> clear enough to discuss questions that are much more essential, like:
>> - type or token
>> - referntially transparent or opake
>> - how to avoid rewriting of existing data when adding annotations
>> - qualification
>> - avoiding the gap between assertion and annotation
>> and some more
>> 
>>>>>> A nested graph may occur in the default graph as well as in
>>>>>> named
>>>>>> graphs.
>>>>> 
>>>>> "may occur" is also a bit too vague, and should be made more
>>>>> accurate in a way similar to what I am outlining above for "may
>>>>> contain".
>>>> 
>>>> Doesn’t that amount to a discussion of the difference between a
>>>> glass
>>>> half-full and half-empty? Nobody is required to use nested graphs
>>>> for
>>>> anything, that’s why I wrote "may". But if you use it, you may
>>>> use it
>>>> in the default graph as well as inside named graphs, the latter
>>>> being
>>>> especially noteworthy IMO.
>>> 
>>> Now you got hung up on the fact that I included the word "may" when
>>> quoting your sentence. Yet, this was not the important part.
>> 
>> So what is important is a moving target now?
>> 
>>> My
>>> question really was primarily about the meaning of "occur". So,
>>> rephrasing my question in terms of what you wrote now, can you
>>> define
>>> what you mean by "use it in the default graph" and by "use it [...]
>>> inside named graphs" (where "it" is a nested graph ng=(n,G) I
>>> assume) ?
>> 
>> The terms "occur" and "occurrence" are used in accordance to their
>> usage in
>> https://www.w3.org/TR/rdf12-concepts/
>> of which you are an editor and I’m not aware of any other way in
>> which they may be used.
>> 
>>>>> But also notice that another aspect that should be clear from
>>>>> the
>>>>> definition is whether a nested graph can occur multiple times
>>>>> in
>>>>> the default graph and/or in the named graphs?
>>>> 
>>>> I think that is clear by the way the denotation of the nested
>>>> graph
>>>> name is defined. [...]
>>> 
>>> No, it is not clear; not as long as you do not tell us what the
>>> word
>>> "occur" (now "use", see above) means in your definition.
>> 
>> See above.
>> 
>>>>> If the answer to the latter question is some form of yes, then
>>>>> how
>>>>> is this related to requirement that "nested graph names are
>>>>> unique
>>>>> within an RDF dataset"?
>>>>> 
>>>>> Also, are there any constraints regarding the graph names of
>>>>> nested
>>>>> graphs that "occur in the default graph as well as in named
>>>>> graphs"
>>>>> and the names of the named graphs of the dataset?
>>>> 
>>>> I think that the way names on nested graphs are defined rules out
>>>> the
>>>> possibility that the name is used to refer anything else, neither
>>>> web
>>>> resources nor real world concepts nor named graphs nor etc.
>>> 
>>> Note that my question was not only related to what the name of a
>>> nested
>>> graph denotes/refers to. Your definition, as given so far, does not
>>> rule out that there is an RDF dataset D = {G0, (n1,G1), ...,
>>> (nm,Gm)}
>>> and a nested graph ng = (n,G) such that a) ng "may occur in the
>>> default
>>> graph as well as in named graphs" of D and b) n=ni for any i in
>>> 1...m.
>>> Hence, it may be an additional constraint that the name n of a
>>> nested
>>> graph ng=(n,G) must not be the name of any of the named graphs of
>>> the
>>> RDF dataset in which ng "may occur".
>> 
>> I don’t find this discussion constructive. I gave you a lot, and the
>> rest you have to glean from the examples. We are not at the stage
>> where we need to formally define what "contains" "may" "mean". Look
>> at the examples. And don’t call a syntax "made up" that encodes a new
>> primitive for which there necessarily is no established syntax. One
>> could say the same about the double pointy brackets syntax, and it
>> would be besides the point just as well.
>> 
>> Thomas
>> 
>>> Best,
>>> Olaf
>>> 
>>> 
>> 
>

Received on Thursday, 26 October 2023 13:40:53 UTC