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

> On Aug 6, 2024, at 7:16 AM, 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.
> 
> 
>> 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.
> 
>> 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?
> 
> 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 )>> .
>  }

To  avoid confusion about what “stated” means, it might be better to write this queriy using the higher-level constructs:

SELECT ?r {
  ?s ?p ?o ~?r
}

The point of this syntactic sugar is to get around the notion that rdf:states entails the triple being in the graph, which if created using an equivalent structure in Turtle, it will. Getting down to raw use of rdf:reifies and rdf:states is probably too low-level for most query authors.
  
> Property paths break up BGPs.
> 
> 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.

I would support this as an alternative to rdf:states, but momentum is going towards using rdf:states with appropriate syntactic sugar, simiarl to what Enrico proposed for the extended baseline..

Gregg

>    Andy
> 
>

Received on Tuesday, 6 August 2024 16:27:54 UTC