Re: rdfs:domain and refs:range in schema.org

Phil,

I agree,  that is a bit confusing, given Martins' example.  We should
probably be more explicit in the scope definition on both domainIncludes
and rangeIncludes.  I myself have tripped up before on them, if you read
both of the side by side....they say nearly the same thing.  rangeIncludes
saying something about the Type of the "value" of a property....and
domainIncludes saying nothing about "value" and only the property.   Both
are not written very well, IMHO :)

Thing <http://meta.schema.org/Thing> > Property
<http://meta.schema.org/Property> > rangeIncludes
<http://meta.schema.org/rangeIncludes>
Relates a property to a class that constitutes (one of) the expected
type(s) for values of the property.

Thing <http://meta.schema.org/Thing> > Property
<http://meta.schema.org/Property> > domainIncludes
<http://meta.schema.org/domainIncludes>
Relates a property to a class that is (one of) the type(s) the property is
expected to be used on.


Regarding openingHours, we probably could expand that so it can also expect
a Type of ContactPoint, and then expand the definition to "The general
opening hours for a business or ContactPoint..."



On Thu, Nov 24, 2016 at 6:07 AM Phil Archer <phila@w3.org> wrote:

> This presents either a problem or an opportunity (and I'd like to know
> which is true).
>
> The opportunity presented by "domainIncludes" is that you can, I think,
> use a property on a class that is not listed as a domain. In something
> I'm doing right now for the European Commission, I want to use
> schema:openingHours on a schema:ContactPoint. Since the domain of
> schema:openingHours 'includes' CivicStructure and LocalBusiness, perhaps
> that's OK? After all, 'includes' suggests it's not an exhaustive list.
> schema:ContactPoint's suggested schema:hoursAvailable property leads to
> a more complex schema:OpeningHoursSpecification that is useful for
> declaring exceptions - and we want to use that too - but it seems overly
> complex for a simple "usually open Monday to Friday 9 - 5" statement.
>
> So here, domainIncludes, as explained by Dan, wins.
>
> But... Martin's example shows that's *not* how it's being used. Rather,
> it's being used as a constraint language, which I regard as a separate
> thing altogether.
>
> If I put a schema:openingHours property on a schema:ContactPoint, the
> structured data tester will say it doesn't understand my data. Does that
> mean my data is invalid for all potential data consumers or just the
> search engines?
>
> If the data is actually invalid then I'd say that rangeIncludes and
> domainIncludes seem to be mis-named. "domainResterictedToOnly" seems
> more honest? Or am I missing something?
>
> Phil
>
>
> ==Dan's reply copied from archive for reference ==
>
> We wanted to leave the flexibility to evolve the schemas incrementally
> without breaking "promises" expressed with RDFS's range/domain, and without
> adding lots of artificial supertypes to group different types within a
> common type.
>
>
>
> == Martin's reply Copied from archive for reference ==
> Hi Alex:
>
> This is because the semantics of RDFS domain and range constructs
> *imply* additional type membership instead of *constraining* the
> applicability of a property to a class or value.
>
> With RDFS semantics, a domain spec like so
>
>      foo:schoolAttended rdfs:domain foo:Human.
>
> in combination with the statement
>
>      foo:myDog a foo:Dog ;
>                foo:schoolAttended "ACME High School".
>
> implies that
>
>      foo:myDog a foo:Human
>
> instead of throwing a constraint violation error.
>
>
> Also, if a property had multiple classes as its range or domain, you
> have to create many useless complex classes in order to avoid unintended
> type membership inferences:
>
> In RDFS, a domain spec like so
>
>      foo:yearOfBirth rdfs:domain foo:Human, foo:Dog.
>
> in combination with the statement
>
>      foo:myDog a foo:Dog ;
>                foo:yearOfBirth 1971.
>
> implies that your dog is a dog and a human:
>
>      foo:myDog a foo:Human, foo:Dog.
>
> i.e. the intersection of being a dog and human, whatever that is.
>
> The only way to avoid this are complex class definitions, like so:
>
>       foo:yearOfBirth rdfs:domain [ a owl:Class;
>                                      owl:unionOf (foo:Human, foo:Dog) ].
>
> which will create many, many of those useless classes in the ontology
> because of combinatorial effects.
>
> Martin
>
> -----------------------------------
> martin hepp  http://www.heppnetz.de
> mhepp@computer.org          @mfhepp
>
>
>
>
>  > On 21 Nov 2016, at 16:39, Alex Prut <mail@alexprut.com> wrote:
>  >
>  > Hello all,
>  > I'm looking at the schema.org raw ontology implementation and
> documentation, but I can’t find a reason why the ontology was
> implemented using the schema:domainIncludes and schema:rangeIncludes
> properties, instead of the standard RDFs rdfs:domain and rdfs:range?
>  > Thanks,
>  > Alexandru Pruteanu (M.Sc. in Computer Science at University of Udine)
>  > mail@alexprut.com
>  >
> --
>
>
> Phil Archer
> Data Strategist, W3C
> http://www.w3.org/
>
> http://philarcher.org
> +44 (0)7887 767755 <+44%207887%20767755>
> @philarcher1
>
>