Re: Nested Graphs - a graph-based proposal

> 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 11:53:52 UTC