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

Am 8. August 2024 13:37:26 MESZ schrieb "Thomas Lörtsch" <tl@rat.io>:
>
>
>> 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 .
     _:r :a :b. 

>?
>
>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:59:47 UTC