Re: fewer entailments is better?

On 10/03/2023 19:00, Peter F. Patel-Schneider wrote:
> On 3/10/23 12:50, Pierre-Antoine Champin wrote:
>>
>> On 10/03/2023 16:22, Peter F. Patel-Schneider wrote:
>>> On 3/9/23 16:13, Pierre-Antoine Champin wrote:
>>>> dear Peter,
>>>>
>>>> On 07/03/2023 18:43, Peter F. Patel-Schneider wrote:
>>>>> I've been hearing claims that having fewer entailments for quoted 
>>>>> triples is somehow better because one could always just craft a 
>>>>> semantic extension that adds in the extra entailments.  I don't 
>>>>> view this as a valid argument because, as far as I have seen, 
>>>>> there has not been a semantic extension created for this purpose 
>>>>> and so it is not possible to determine whether the extension is 
>>>>> reasonable.
>>>>
>>>> The argument is not that /one/ particular semantic extension could 
>>>> be created to support all extra entailment that people could think 
>>>> of. The argument is that it is the job of semantic extensions /in 
>>>> general/ to specify additional entailment on top of the base 
>>>> semantics.
>>>>
>>>> The rationale for "less entailment is better" is that, because RDF 
>>>> semantics is monotonic, any entailment that we bake into the core 
>>>> semantics would have to be "inherited" by /all/ semantics 
>>>> extensions, including RDF-S and OWL...
>>>>
>>>> Does that make more sense?
>>>>
>>>>>
>>>>> peter
>>>>>
>>>>> PS: See 
>>>>> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Jan/0013.html 
>>>>> for a claim along these lines.
>>>
>>> I believe that this argument rests on the assumptions that there is 
>>> one kind of quoted triple and that all quoted triples share a 
>>> semantic core of semi-opacity.
>> While I favor this assumption, I don't believe that this argument 
>> ("less entailment is better") rests on this particular assumption. 
>> Whichever semantics the WG adopts, all semantics extensions will have 
>> to deal with it and all the entailments that it, well, entails.
>
> Yes, semantic extensions only add entailments.  But this does not 
> imply that a particular semantics for a particular form of quoted 
> triples is better than other semantics for other forms of quoted 
> triple just because the semantics has fewer entailments.  If this was 
> the case, then a semantics that produced no extra entailments at all 
> would be the best.
>
> I think that the argument has to go along the lines that a particular 
> semantics for a particular kind of quoted triples is best because it 
> produces the right entailments for the kind of quoted triples.  If 
> semantic extensions of this semantics produces the right entailments 
> for other kinds of quoted triples then that is a bonus.

I agree in theory. The problem is: I don't think we have come up with a 
consensus on what the "right" entailments are, and I am not sure that we 
can find one definition of "right" that satisfies all use-cases 
(although I would be happy to be proved wrong on that).

In this situation, I'd rather go with too few entailments than with too 
many -- because, again, people in the future can fix "too few" with a 
semantic extension, but fixing "too many" will be much harder.

But granted, aiming at "exactly the right entailments" is better and 
more ambitious than aiming at "too few entailments"! Let me give it a shot:
in RDF 1.1 Semantics, Simple entailment has a number of nice properties 
<https://www.w3.org/TR/rdf11-mt/#simple_entailment_properties> that make 
it very, well, simple. I would really like those properties to still 
stand for Simple entailment in RDF 1.2 Semantics.
In particular, the interpolation lemma guarantees that basic SPARQL 
(i.e. without any specific entailment regime) coincides with simple 
entailment <https://www.w3.org/TR/sparql11-entailment/#sec-intro>. I 
really wish we keep this in RDF 1.2 / SPARQL 1.2 as well.

   pa

>
>>> Neither of these has been adopted by the working group.  For 
>>> example, Enrico's proposals appear to have several kinds of quoted 
>>> triples. See also the original proposal for RDF* that has a 
>>> different semantic basis.
>>    pa
>>
>>>
>>> peter
>
> peter
>