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

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.  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.  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 Saturday, 17 February 2024 14:02:55 UTC