Re: expanding work from quoted triples to graph terms

> On Oct 22, 2023, at 1:15 PM, Andy Seaborne <andy@apache.org> wrote:
> On 22/10/2023 01:42, Gregg Kellogg wrote:
>>> On Oct 21, 2023, at 10:20 AM, Andy Seaborne <andy@apache.org> wrote:
>>> [snip]
> 
>> In the abstract syntax graph terms do not have identifiers (similar to blank nodes), but they are required for most concrete syntax usage.
>> The notion of Graph Isomorphism needs to be extended for any such definition and is distinct from graph equality. Two triples might contain the same graph term or triples might contain graph terms which are not the same, but are isomorphic.
> 
> I have been assuming the scope of blank node identifiers is the document. Isomorphism is still a mapping on blank nodes.

There are isomorphism considerations for both triple terms and graph terms; they are pretty identical in this regard, although we never considered an identifier for a triple term as we have a graph term.

> Is that not the case for JSON-LD/VC?

As JSON-LD is RDF, the Isomorphsim case is the same. But, at least for VC, Canonicalization is not norm, rather than Isomorphism. I think of Dataset Canonicalization and Dataset Isomorphsm as being essentially equivalent, as both result in a bijection; it’s just that canonicalization also includes canonical labeling of blank nodes.

>> IMO, Thomas’s Nested Graph proposal seems overly reliant on concrete syntax and I would like to see this more formalized as an extension to the abstract syntax; I’m nor sure how difference in transparency are reflected in the abstract syntax.
>>> ---
>>> 
>>> My understanding at the moment is that the "blank graph" variants are compatible with the graph component of a named graph pair [*] being a graph term.
>>> 
>>> 
>>> "Blank graph" variants:
>>> _:a { :s :p :o }
>>> 
>>> { :s :p :o } is a graph term, _:a is a resource for the occurrence.
>>> 
>>> "Graph terms"
>>> _:a rdf:occurrenceOf{ :s :p :o }
>>> 
>>> { :s :p :o } is a graph term, _:a is a resource for the occurrence.
>> One thing in favor of the Blank Graph proposal is it seeming has a limited impact on the data model, although it requires some re-interpretation of what named graphs identified by blank nodes means. It’s also the view that specs based on JSON-LD have taken (e.g., Verifiable Credentials).
> 
> The way JSON-LD/VC treats graphs in the document as graph and appendices - that will work in either approach. For a blank graph, there is a fixed relationship to the graph term (graph literal).
> 
> If we go for a blank graph approach, then the data model would now have to have account for this so I think it will have an impact, maybe more.

My thought was that the abstract syntax does not need to accont for anything other than IRIs, Blank Nodes, and Literals. There is a separate map of blank nodes to (named) graphs, which can be constructed by finding blank nodes which are the subject and/or object of one or more triples and also the graph name of a named graph. This would be a change from RDF 1.1 where there is no direct relationship between a resource used as subject or object and as a graph name, which would continue to apply for IRIs.

At least in my N3 implementation, this is how graph terms are managed for a quad store based implementation. If graph terms were not based on blank node named graphs I would create an equivalent mechanism to blank nodes for managing internal references, and to be used for serialization purposes.

> I don't see how we can keep the graph term out of the data model completely although a separate map of blank node to separate graph might work (this also occurs in SPARQL with path{0}). However, why treat one data element differently to the other 3?

Yes, I’m not advocating for keeping it out of the data model, I don’t think it necessarily needs to be reflected in the abstract notion of triples and named graphs; a separate map handles this. But, I’m fine however we decide on this.

Gregg

> Viewing as only a packaging outside the RDF data model doesn't fit with SPARQL very well [1].
> 
> There is no way to find out whether blank does identifies a graph nor to find out what the graph contains except by retrieving the whole package and processing locally. For VC, that's reasonable but it isn't for all RDF on the web.
> 
> Some of the blank graph proposals talk about special handling for blank nodes in the graph name position such no in "GRAPH ?g".
> 
> And the separate of blank from URIs seems a little "porous":
> 
> _:a { :s :p :o }
> _:a owl:sameAs <http://example/abcde> .
> 
> Blank Graph proposals can be syntax forms over a more general description. It also gives an account for RDF 1.1 migration.
> 
>    Andy
> 
> [1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Oct/0009.html
> 
>> Gregg
>>>    Andy
>>> 
>>> [*] A named graph is a pair (resource reference, graph)
>>> https://www.w3.org/TR/rdf11-concepts/#dfn-named-graph
>>> 
>>> On 20/10/2023 17:17, Niklas Lindström wrote:
>>>> Dear all,
>>>> I picked up the suggestion in the telecon and have drafted an overview
>>>> of the options (and proposals) that (AFAIK) are on the table ("RDF
>>>> options for triples about triples"). Right now it's in a Google
>>>> Spreadsheet at:
>>>> https://docs.google.com/spreadsheets/d/1pzA5AYkzEO-Mr6ClV4KNjUf4bAsrCz_ZWS9dMEFgh1o/edit?usp=sharing
>>>> I can move this to our wiki [1] if that's preferable. (I think so, but
>>>> it demands a bit more to edit it as a markdown table. Otherwise I can
>>>> grant everyone edit rights one by one, unless we already have a shared
>>>> Google Docs folder I've missed?)
>>>> I'm trying to single out features from these, to simplify assessments.
>>>> I've made some footnotes and questions in the sheet for starters.
>>>> If anyone wants to have a call hashing out these details, I'm all for
>>>> it. (Perhaps we could use next week's cancelled Semantics TF timeslot
>>>> for that? It depends on where we are after the regular call of
>>>> course.)
>>>> All the best,
>>>> Niklas
>>>> [1]: https://github.com/w3c/rdf-star-wg/wiki