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

> On 8. Aug 2024, at 15:14, Andy Seaborne <andy@apache.org> wrote:
> 
> 
> 
> On 08/08/2024 12:59, Thomas Lörtsch wrote:
>> 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.
> 
> Then we agree then that it needs to work for simple entailment?

It would certainly be good. That’s why I’m trying to find a way to "emulate" the desired behavior through a combination of syntactic sugar and macros and some tbd SPARQL extra, but without requiring RDFS entailment.

> ...
>>>> 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.
>>> ?
> 
> No rdf:type.
> 
> I don't believe that are only two cases of "stated" and "document". I don't believe we can or should enumerate the possibilities - that is the responsibility of data modelling.
> 
> Most data is "light weight modelling". The most common usage will be reification with no opinion as to stated/document.

You asked for an analysis of use cases and I provided it [0]. Now it seems like you’ve already made up your mind.

> The RDF way is to add information as needed. No information means "not known".
> 
> rdf:type might be inferred by the domain of a property in the annotation block.
> 
> We might even have "rdf:type rdfx:Edge" with special meaning for the LPG use case.
> 
>>> 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?
> 
> subproperty is a feature of RDFS.

Querying for rdf:states is not, no matter if it’s defined as a subproperty of rdf:reifies or not. You were concerend about too many options when querying for annotations, and I wonder if most queries might only be interested in the annotations on stated triples.

> SELECT ?r {
>     ?r rdf:reifies ?T .
>  }
> 
> and if the query is looking for only stated:
> 
> SELECT ?r {
>     ?r rdf:reifies ?reif .
>     ?reif rdf:type rdf:Stated .
> }
> 
> which can be
> 
> SELECT * {
>   ?r rdf:reifies [ rdf:type rdf:Stated ] .
> }
> 
> SELECT * {
>   ?r rdf:reifies/rdf:type rdf:Stated .
> }

Again: I don’t think it's a good idea to require the most ubiquituous use case - annotating something that is meant to be a fact in the graph - to require an extra triple in authoring and an extra clause in querying. And yes, that is my result from the analysis of use cases.

Also, that extra triple would also be needed to make the annotation syntax robust in round tripping. You seem to overlook that aspect.

Thomas


>   Andy
> 
>>> 
>>> 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 14:46:33 UTC