Re: Handling multiple rdfs:ranges

On 02/26/2016 08:14 AM, Reto Gmür wrote:
> On Fri, Feb 26, 2016, at 14:28, Peter F. Patel-Schneider wrote:
>> On 02/26/2016 01:52 AM, Reto Gmür wrote:
>>>
>>> On Thu, Feb 25, 2016, at 06:18, Pat Hayes wrote:
>>>>
>>>> On Feb 23, 2016, at 10:24 AM, Reto Gmür <reto@wymiwyg.com> wrote:
>>>>
>>>>> On Tue, Feb 23, 2016, at 17:05, Peter F. Patel-Schneider wrote:
>>>>>> On 02/23/2016 07:31 AM, Reto Gmür wrote:
>>>>>>> [...]
>>>>>>>
>>>>>>> Granted, the semantics of :rangeIncludes are very weak (under OWA) but
>>>>>>> the fact that you can create contradictions with it shows that it's not
>>>>>>> completely meaningless.
>>>>>>>
>>>>>>> ex:prop1 s:rangeIncludes :Cat .
>>>>>>> :Cat owl:disjointWith :Dog .
>>>>>>> ex:prop1 owl:range :Dog .
>>>>>>>
>>>>>>> The above graph evaluates to false in every possible world, this is not
>>>>>>> the case if you omit any of the 3 triples, this shows that
>>>>>>> `s:rangeIncludes` is not a meaningless decoration.
>>>>>>>
>>>>>>> Reto
>>>>>>
>>>>>> I don't think that this follows from the semantics of :rangeIncludes,
>>>>>> even if
>>>>>> you augment schema.org semantics with disjointness.
>>>>>
>>>>> In the example I also used "owl:range" to create what I thought is a
>>>>> contradiction.
>>>>>>
>>>>>> Perhaps one could also count the documentation of
>>>>>> rangeIncludes as authoritative as well.  So from
>>>>>> https://schema.org/rangeIncludes, rangeIncludes "[r]elates a property to
>>>>>> a
>>>>>> class that constitutes (one of) the expected type(s) for values of the
>>>>>> property" would also be part of the semantics of schema.org ranges.
>>>>>
>>>>> I considered only this definition. And based on that I still think there
>>>>> is a contradiction, if the owl:range of a property excludes :Cat (which
>>>>> is expressed with the statements using owl-properties), :Cat cannot at
>>>>> the same time "be (one of) the expected type(s) for values of the
>>>>> property".
>>>>
>>>> Of course it can. It only follows that the values of this particular
>>>> property are all in some other part of the range. According to the
>>>> schema.org definition of rangeIncludes, this is quite permissible. 
>>>
>>> I'm not getting you.
>>>
>>> from
>>>
>>> (1) :Cat owl:disjointWith :Dog .
>>> (2) ex:prop1 rdfs:range :Dog .
>>>
>>> It follows that: (3) "no value of the property ex:prop1 can be an of
>>> type :Cat".
>>>
>>> Do we agree till here?
>>>
>>> (4) ex:prop1 s:rangeIncludes :Cat 
>>>
>>> means: (5) "The class :Cat is an expected type for values of the
>>> property ex:prop1"
>>>
>>> Do you agree that (5) follows from (4) when using the definition from
>>> http://schema.org/rangeIncludes?
>>
>> No.  This sentence reads as if each expected type for a property is the
>> type
>> of all values of the property.  This is not the case at all in
>> schema.org.
>>
>> Even the slightly weaker statement at https://schema.org/rangeIncludes is
>> not
>> suitable.  The wording there "Relates a property to a class that
>> constitutes
>> (one of) the expected type(s) for values of the property." also reads as
>> if
>> each expected type is supposed to be a type of all values of the
>> property.
>>
>>> Agreeing to both (4) and (5) boils down to:
>>>
>>>  - :cat is an impossible type for values of the property ex:prop1
>>>  - :cat is an expected type for values of the property ex:prop1
>>
>> Not exactly.  "Impossible" is a very strong word here, even stronger than
>> contradictory.  It is certainly possible for a value of a property to
>> have a
>> type that contradicts the range of the property.  It just triggers a
>> contradiction (or maybe even something with even less import), which does
>> what
>> contradictions (or whatever) do in the setup one is currently working in.
> 
> Doesn't "p rdfs:range t" mean that it is *necessary* for all objects of
> p to be of type t? If so by modal logic it is *impossible* for an object
> of p not to be of type t.

Sure, but that doesn't mean that there cannot be a statement to the effect
that p belongs to a type disjoint from t.

> In how far do you see impossible as stronger than contradictory? If I
> ask why something is impossible I'm happy with an answer that proofs
> that it would contradict itself or one of the axioms. What more do you
> need for impossibility?

There are lots of cases where a formal or informal system sees contradictions.
 Contradictions are not impossible, they just have certain consequences, which
can be different in different setups.

>>
>>> Using the first definition of "Expect" from the oxford dictionary as
>>> "Regard (something) as likely to happen", I think there is a
>>> contradiction between asserting that something is impossible and that
>>> something is expected.
>>
>> Certainly there would be something odd going on in an extended schema.org
>> setup if one of the rangeIncludes of a property were disjoint from a true
>> range of the property.  I do not, however, believe that this oddness is
>> anything near a strong contradiction (i.e., something that causes all
>> information to be meaningless).
> 
> I think that for any charitable interpretation of
> https://schema.org/rangeIncludes for "p schema:rangeIncludes t" to hold 
> it must be  *possible* for an object of p to be of type t. 

Why?  Under what definition of possibility?  Is there anything in schema.org
that makes something else impossible?  Is there anything in schema.org that
makes it impossible for a value of p to be of type t?

What is going on here is taking an English word that has a large and varied
meaning and pushing that word into an extension of a particular formal version
of the schema.org language.  How can this exercise end up with anything that
must be the case?

Building a formal account of schema.org and having that account fit into a
larger formal account and then seeing what happens is interesting and useful.
 However, it does not authoritatively answer questions about what goes on in
schema.org.


> Of course being "likely" means more than being "possible" but the former
> implies the latter and possibility is all that is needed to create a
> contradiction with statements of necessity and negation.
> 
> 
> Reto
>>
>>>
>>> I would really like to learn where you think my reasoning is wrong.
>>>
>>> Cheers,
>>> Reto
>>>  
>>>> If you disagree, please suggest how to express the schema semantics as a
>>>> precise model-theoretic condition in such a way that it produces the
>>>> contradiction you expect. 
>>>>
>>>> Pat Hayes
>>>>
>>>>>
>>>>> Reto
>>
>> peter
>>

Received on Friday, 26 February 2016 19:02:45 UTC