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

On 08/08/2024 15:46, Thomas Lörtsch wrote:
> 
> 
>> 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.

I was looking for something else.
-- It would be helpful to have a use case to justify a required feature

The analysis is about whether a design (of several variants) is 
sufficient for the existing use cases. The question remains as to 
whether the feature is necessary and whether the design is necessary for 
the feature.

A use case helps when considering alternative ways to get the same 
requirement.

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

I believe that it is common for RDF data to be "light weight modelling" 
- just enough to do the job. More detail may be added later.

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

We need a solution for all syntaxes.

Turtle shorthands are nice but the RDF data model is for all syntax choices.

The rest is how to write a Turtle pretty printer. It's not trivial and 
it does not scale. Because of the analysis required, not all Turtle 
output is in the form of maximal use of syntax shorthand forms.

"N-triple+prefixes", or "subject+all triples with that subject" forms of 
Turtle output exist which don't use the pretty features.

     Andy

> Thomas

Received on Thursday, 15 August 2024 09:12:12 UTC