W3C home > Mailing lists > Public > semantic-web@w3.org > February 2016

Re: Handling multiple rdfs:ranges

From: Reto Gmür <reto@wymiwyg.com>
Date: Fri, 26 Feb 2016 12:04:15 +0100
Message-Id: <1456484655.3897234.532588698.3239BF28@webmail.messagingengine.com>
To: Jiří Procházka <ojirio@gmail.com>
Cc: Pat Hayes <phayes@ihmc.us>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, semantic-web@w3.org
On Fri, Feb 26, 2016, at 11:31, Jiří Procházka wrote:
> From what I know, thinking about rdfs/owl:range as defining what "can be" as range of the property is incorrect - it is defining what the range of the property *is*, inferring a triple like: :x ex:prop1 :y . => :y rdf:type :Dog

I fully agree.

> http://schema.org/rangeIncludes doesn't infer anything, so in case the
> dataset with  :x ex:prop1 :y doesn't contain triple :y rdf:type :Cat
> then there is no contradiction, and :y is a :Dog.
schema:rangeIncludes doesn't infer anything regarding the instance data,
but it says that there is at least a possible (even expected) universe
in which a value of ex:prop1 is of type :Cat

> This means defining a property using both rdfs/owl:range
> http://schema.org/rangeIncludes is not advisable, as these
> inconsistencies could appear. You should decide if your properties
> define the types of range (using rdfs/owl:range), or you rely on them
> appearing in the dataset. I would recommend to do so (including unions
> as range), since it is stronger definition of the relationship, better
> maintaining the intended meaning when another type information (:y
> rdf:type :Cat) is added to the dataset.
>
> (It may help to think about property defined using
> http://schema.org/rangeIncludes as a class of properties, which one of
> the class is being used, being determined by the external type
> information)
Sure, still I think that schema:rangeIncludes is not meaningless (as it
restricts the rdfs:range statements that are possible) and that it has
some pragmatic usefulness such as when building editors that suggest
values for a specific property. Of course a generic editor should allow
entering any individual that is not excluded by known rdfs:range
statements, but :Garfield, :Catbert and :Superkatt should be on the
lists of suggestions if schema:rangeIncludes :Cat.

Reto

>
> Cheers, Jiri
>
> On Fri, Feb 26, 2016 at 9:52 AM, Reto Gmür <reto@wymiwyg.com> 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?
>>
>> 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
>>
>> 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.
>>
>> 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
>> > >
>> > >
>> > >
>> >
>> > ------------------------------------------------------------
>> > IHMC                                     (850)434 8903[1] home 40
>> > South Alcaniz St.            (850)202 4416[2]   office Pensacola
>> > (850)202 4440[3]   fax FL 32502
>> > (850)291 0667[4]   mobile (preferred) phayes@ihmc.us
>> > http://www.ihmc.us/users/phayes
>> >
>> >
>> >
>> >
>> >
>> >
>>



Links:

  1. tel:%28850%29434%208903
  2. tel:%28850%29202%204416
  3. tel:%28850%29202%204440
  4. tel:%28850%29291%200667
Received on Friday, 26 February 2016 11:04:42 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:41:50 UTC