Re: An update on [Proposal: described vs stated triple terms]

> On 5. Aug 2024, at 18:28, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:

> On 8/5/24 11:37, Thomas Lörtsch wrote:

>> SPARQL
>> ======
>> In Friday’s meeting we discussed if SPARQL should support stated triple terms by querying for them too, even when the BGP only mentions reified triple terms. To that end 'rdfs:states' should be defined as a subproperty of rdf:reifies.
>> However, upon further reflection it seems to me that the real benefit would be in having any query search not only all (standard) triples but also all stated triple terms. E.g. a query for
>>     ?s ?p ?o
>> over the following graph
>>     _:t1 rdfs:states <<( :s :p :o )>> ;
>>         :a :b.
>>     _:t2 rdfs:reifies <<( :x :y :z )>> ;
>>         :c :d.
>> would return also the triple from the stated triple term, but not from the reified one:
>>     _:t1 rdfs:states <<( :s :p :o )>> .
>>     _:t1 a :b .
>>     :s :p :o .
>>     _:t2 rdfs:reifies <<( :x :y :z )>>.
>>     _:t2 :c :d.
>> This might be made the standard behaviour of SPARQL-star or a switchable configuration option or a keyword (something like "WITH STATED").
> 
> 
> This is a dramatic change for SPARQL unless there is some macro expansion going on behind the scenes here.   I think that such a dramatic change requires a major revision to SPARQL and is beyond the remit of the working group.
> 
> I also do not understand how a standard SPARQL query can return a triple. SPARQL querying returns multisets of bindings.  (This is slightly informal but good enough for the discussion here.)

I confess that my example looked clearer to me then than it looks now. It was just meant to illustrate my intention, not an actual query. Maybe it could also be formulated as "a construct query should return what the example returns", or "a count on the number of triples in the example graph should return 5". 

> If you mean to say that the BGP query ?s ?p ?o . matches against some triple terms in the graph then that just seems like a bad idea.  

No, I think that that’s indeed a good idea. It reflects the intuition that annotations on a rdf:stated triple term do indeed expect that triple to be true in the graph, even if its not (e.g. because it was forgotten to include, because RDF doesn’t support RDFS entailment, etc). 

> If you mean that BGP query matching matches against your proposed RDFS consequences of your rdfs:states property then that seems like a significant break from the current relationship between SPARQL and RDF

No, I hope to match against stated triple terms, not against entailed triples.

> and should trigger a complete rethinking of the relationship so that, perhaps, consequences of rdfs:subClassOf and its interaction with rdf:type should also be matched.  

I don’t think that we need to discuss this now, but please allow me to disagree anyway. Entailing stated triple terms would have a well constrained scope, it would not trigger some uncalculable chain reactions (nested triple terms, but that seems manageable), and it would be directly connected to the task of this WG. So, no, I definitely wouldn’t consider it as drastic a change as you describe it. But as I said, in this updated proposal I’m exploring ways to work around proper entailment and to design a suitable surrogate for it.

> If you instead were using some shorthands you need to show the expansion, as the macro is then irrelevant to the BGP matching process.

I was using nothing, I just tried to illustrate the desired result. I’m obviously challenged to even jot down a simple query, so I’d certainly not dare to draw up some expansion (I have only a vague idea what that means). I observe however that e.g. a query using the annotation syntax ("Turtle with holes") requires a bit of background machinery to map to the N-Triples in the database. IIUC e.g. a query for

    ?s ?p :o {| :a ?b |}

must check for reifications of '?s ?p :o ', i.e. it must scan the triple terms, and I wonder if it isn't possible to apply similar wizardry for the purpose of querying stated terms "as if" those terms were actually stated.

Maybe what you mean by expansion could possibly be formulated this way:

    when searching for something, 
    match not only against the triples in the graph, 
    but also against the stated triple terms in the graph.

I hope this makes it clearer. Note that this doesn’t involve RDFS entailment.


Best,
Thomas


> peter
> 
>

Received on Tuesday, 6 August 2024 08:30:43 UTC