Re: expanding work from quoted triples to graph terms

Dear Niklas,

I could add some information about graph terms in N3 if you give me access. I also have some trouble understanding some of the terms in your table (just as Thomas). What would be the best way to keep track? Do you want them here in the list or maybe as a comment? I also like your idea to discuss these things in a meeting.

Kind regards,
Dörthe

Am 23.10.2023 um 01:37 schrieb Gregg Kellogg <gregg@greggkellogg.net<mailto:gregg@greggkellogg.net>>:

On Oct 22, 2023, at 1:15 PM, Andy Seaborne <andy@apache.org<mailto: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<mailto: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