Re: expanding work from quoted triples to graph terms

> On Oct 21, 2023, at 10:20 AM, Andy Seaborne <andy@apache.org> wrote:
> 
> An extra column could be the effect on the RDF Data Model.
> https://www.w3.org/TR/rdf12-concepts/#section-rdf-graph
> 
> What new RDF terms are there?
> 
> ---
> 
> Based on the strawpoll last week, can we settle on "graph term" and "occurrence"?
> 
> Are there any other conceptual items?
> 
> "occurrence" has been used in CG and WG discussions.

This also seems to be the same as “token” based on the type/token discussion. I think “occurrence” has a more intuitive meaning.

> A graph term is a graph used as a RDF term in the RDF data model. It's quoted triple (triple term) but for graphs. (It has value-equality (structural equality)).
> 
> Using this terminology is not implying any particular choice of semantics.
> 
> There is work-in-progress going on
> https://github.com/w3c/rdf-concepts/pull/67
> 
> so bringing that PR conversation together with the "options" would be a way forward.

There are definitely a couple of views on what this means. In the “Blank Graphs” interpretation, the data model is pretty unaffected with a dataset containing a default graph and zero or more named graphs. In this case, the graph name is a blank node which is also used as the subject or object of another triple (considering the limitations on graphs not referencing themselves). We could consider a topology based on tracking down these references, similar to how SPARQL deals with property paths.

In the other pure Graph Term model, graphs are, themselves, resources. A graph may be the subject or object of a triple, and the set of such graph terms is disjoint from the set of named graphs. BGP matching works similar to N3 with variable substitutions, but elements from arbitrary graph terms can’t be selected without introducing something like a property path mechanism. 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.

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).

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
>

Received on Sunday, 22 October 2023 00:43:14 UTC