Re: expanding work from quoted triples to graph terms

On 22/10/2023 01:42, Gregg Kellogg wrote:
>> 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.

Add a graph term pattern to SPARQL c.f. Triple term.

Whether arbitrary nesting support is necessary is unclear to me, nor 
whether it is necessary now (...living standard...).

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

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

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

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?

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

Received on Sunday, 22 October 2023 20:16:07 UTC