Re: RDF-star semantics: option 3 (first DRAFT)

On 17/02/2024 14:02, Peter F. Patel-Schneider wrote:
> On 2/17/24 04:04, Pierre-Antoine Champin wrote:
> ...
>>> I think what you are trying to say is that if tripleOccurence is part 
>>> of RDF graphs then pattern matching has to be extended. Well, yes, 
>>> just like if tripleTerm is part of RDF graphs pattern matching has to 
>>> be extended as well. It is just that the extension for the latter is 
>>> simple.  To match tripleTerm, just match the components.  The 
>>> situation for tripleOccurence is a bit more complex - if there is 
>>> something like rdf:nameOf then there is a post-graph expansion and 
>>> then regular pattern matching; if there isn't then part of pattern 
>>> matching is to construct a side partial mapping from IRIs to triple 
>>> terms use that mapping to expand matching for IRIs.  But the point is 
>>> that no matter what additions are made to RDF graphs pattern matching 
>>> has to be expanded.
>>
>> Note that I wrote "no SIMPLE pattern matching".
>>
>> As you point out, extending the current "pattern matching" (more 
>> formally, the notion of graph instance in the semantics [1]) to triple 
>> term would be straightforward.
>>
>> Granted, we could maybe extend this definition to cover the entailment 
>> suggested in my email. But I'm concerned that it would 1) depart from 
>> the intuitive notion of pattern matching, 2) be computationally more 
>> expensive, and 3) have strange consequences on SPARQL (see my other 
>> email [2]).
>>
>> [1] https://www.w3.org/TR/rdf11-semantics/#dfn-instance
>> [2] 
>> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Feb/0030.html
>>>
>>> peter
> 
> 
> So let's look at pattern matching in RDF 1.1.   It's not a simple 
> operation at all, at least if one wants to write an optimized algorithm, 
> being equivalent to sub-graph matching.  Blank nodes add a lot of 
> complexity.  A nondeterministic algorithm, however, is dead simple.
> 
> If triple terms are added then pattern matching has to be extended to 
> handle a totally new kind of node.  In essence, a triple term node acts 
> like a little part of the graph, which has to be pattern matched against 
> other triple terms.   As triple terms are trees, albeit of unbounded 
> size, this matching is not as complex as the regular RDF 1.1 pattern 
> matching, but there are still decided complications from the presence of 
> blank nodes in triple terms.

What complications? Yes, you have to match terms, that's not 
complicated. Implmentations of CG-RDF-star are doing it. Blank nodes in 
triple terms are no different to triple terms in BGPs in SPARQL 1.1 
matching via RDF instance mapping.

Triple term trees are fixed order S/P/O at each branch so are easier to 
match than a general, unordered-branch trees.

If they are annotations, as per the original RDF-star by Olaf, the 
triple can be used to index them.  If not a term table might be useful 
but isn't necessary. (Or used named graph if not being used for anything 
else.)

We discussed on Friday that nested triple terms would be unusual because 
we have named occurrences, and occurrences can be used in occurrences by 
name.

>  So it is not a trivial extension.  Note 
> that a nondeterministic algorithm is still dead simple.
> 
> I'm actually not in favour of the "red" semantics for triple 
> occurrences. 

I agree.

https://github.com/afs/rdf-star-notes/blob/main/reif-atoms-interpret.md#semantics

> Why include triple occurrences if they are just semantic 
> shorthand for something that can be expressed in a different way?  But 
> in this semantics pattern matching can proceed by first expanding triple 
> occurrences to the equivalent triple with predicate rdf:nameOf before 
> using the pattern matching above.  Of course a nondeterministic 
> algorithm is still dead simple.
> 
> In a semantics where triple occurrences use some special connection 
> between the IRI or blank node and the triple pattern then in an RDF 
> graph IRIs and blank nodes can have triple terms associated with them.  
> Pattern matching has to be extended to these triple terms, as above.  
> The additional bit is that matching a node with associated triple terms 
> against a node with associated triple terms a decision has to be made as 
> to which triple terms are matched with which.  This isn't trivial 
> either, but is a cut-down version of matching the edges going out of a 
> node.  Note that a nondeterministic algorithm is again still dead simple.
> 
> If there are both triple edges and triple occurrences in this semantics, 
> both extensions are needed.  Of course a nondeterministic algorithm is 
> again still dead simple.
> 
> It thus appears to me that the most difficult extension is handling 
> triple terms.
> 
> 
> peter
>

Received on Monday, 19 February 2024 21:32:13 UTC