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

> On 6. Aug 2024, at 16:16, Andy Seaborne <andy@apache.org> wrote:
> 
> 
> 
> On 05/08/2024 16:37, Thomas Lörtsch wrote:
> > some help from SPARQL.
> 
> If it is RDFS-star entailment regime, there is nothing extra to do in SPARQL.

Yes, if … but in general we can’t rely on RDFS entailment to be available to us.

> 
>> 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
> 
> The WG has been using use cases. It would be helpful to have a use case to justify a feature - is it common enough to motivate special syntax given it can already be done in RDFS-star.

See my extra mail on that [0]

>> 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").
> 
> Breaking the relationship of pattern matching and simple entailment is a major step. Why this feature and not others?

Because we are only working on RDF-star, not other issues, and because it might help very much in ironing out the kinks in RDF-star. At least that’s the idea.

> No configuration options. A query should give the same answers at all endpoints with the same data.
> 
> With simple entailment, the user writes:
> 
>  SELECT ?r {
>    ?r rdf:states|rdf:reifies ?T .
>  }
> 
> and for statements and stated terms (mentioned else thread)
> 
>  SELECT ?r {
>    ?r rdf:states <<( ?s ?p ?o )>> .
>  }
> 
> Property paths break up BGPs.

Not sure why you mention property paths here - maybe I’m missing something. But since you mention it, I was about to ask the following anyway: why is using property paths on triples in annotation syntax not allowed (see Example 14 in the CG report [1])? 

> From a data access point of view, multiple properties are a burden in query writing, it would be better to qualify the reifier:
> 
> Data:
> 
>   :r rdf:reifies <<( :s :p :o )>> .
>   :r rdf:type rdf:Stated .
> 
> then
> 
>  SELECT ?r {
>    ?r rdf:reifies ?T .
>  }
> 
> finds all reifiers
> 
>  SELECT ?r {
>    ?r rdf:type rdf:Stated .
>  }
> 
> finds stated ones
> and
> 
>  SELECT ?r {
>    ?r rdf:type rdf:Description .
>  }
> 
> finds describing reifiers.
> 
> This is open - there can be other characteristics related to reifiers e.g source.

We discussed this already: it solves the problem to some degree, but it adds considerably to the triple count. Would you want the canonical mapping from 

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

to n-triples to be

   :s :p :o .
   _:r rdf:reifies <<( :s :p :o )>> .
   _:r rdf:type rdf:Stated .
 
?

You were concerend about additional query complexity if a second property like rdf:states as a subproperty of rdf:reifies is introduced. How would the necessity to query for an extra typing triple compare to that?

Thomas


>    Andy
> 

[0] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0032.html
[1] https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html#example-14

>

Received on Thursday, 8 August 2024 11:37:35 UTC