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

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


[...]


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

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.  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 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.  If you instead were using 
some shorthands you need to show the expansion, as the macro is then 
irrelevant to the BGP matching process.

peter

Received on Monday, 5 August 2024 16:28:43 UTC