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

On 06/08/2024 17:27, Gregg Kellogg wrote:
>> 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 query using the higher-level constructs:

The text in the original message had the basic forms in it.

> 
> 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. 

Expansion in Turtle is an option. But what about N-triples? The effect 
of SPARQL Update?

> Getting down to raw use of rdf:reifies and rdf:states is probably too low-level for most query authors.

It's not quite the same thing as direct expansion of the shorthand 
syntax is two triples.

    { ?r rdf:states <<( ?s ?p ?o )>> . ?s ?p ?o . }

For just finding the reifiers and triple terms, the entailment isn't 
necessary.

A well-formedness condition makes it equivalent in a way an optimizer 
can handle it.  But again, N-triples?

Seems like it has to be in the RDF data model to get consistent 
behaviour across Turtle, N-triples, SPARQL, Canonicalization, ...

We talk about authoring RDF data but let's not forget consuming data.
SPARQL isn't the only way to access data. Should APIs do that as well? 
And what about counting results?

>> 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..

There is a lot of time exploring it. That's not the same.

Hard-wiring something deep into RDF needs a solid basis. The 
justification for the proposal is by various stated intuitions. We need 
data to ground that out in order to make a proposal with enough give 
stability that it can be written up.

> 
> Gregg
> 
>>     Andy
>>
>>
>

Received on Tuesday, 6 August 2024 19:37:15 UTC