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

Phil,

I believe it is an opportunity.

As Dan said the approach is there to provide flexibility.

There is some useful background spread across the Conformance section of
the Data Model page <http://webschemas.org/docs/datamodel.html> in the
Schema.org documentation.  With includes a useful reference to Postel’s Law.
<https://en.wikipedia.org/wiki/Robustness_principle>  Particularly relevant
is this:

Applications of schema.org can address conformance in several ways. Tools
such as validators can check for application-specific patterns, such as the
data structures required for some specific functionality. They may also
check compliance with underlying formats (JSON-LD, Microdata, RDFa etc.),
or offer additional hints that go beyond formal conformance (e.g. checking
for readability issues or implausible data).

While it is appropriate and useful for such checkers to warn about
published data that may be difficult or ambiguous for consumers, they are
not obliged to treat unexpected structures as errors. Schema.org's
underlying datamodel is naturally flexible, and provides an extensible
<http://webschemas.org/docs/extension.html> basis for rich structured data.
We encourage both publishers and consumers to continue to explore and share
<https://www.w3.org/community/schemaorg/> new vocabulary ideas for evolving
<http://webschemas.org/docs/schema.org/docs/releases.html> schema.org.


That said some tools, such as Google’s Structured Data Testing Tool, do
complain about some structures and use of the vocabulary that do not fit
well with particular use cases that they have.  That is really an issue for
them and not the vocabulary itself.

As to your particular question about using schema:openingHours property on
a schema:ContactPoint.  It seems you have a valid use case to support a
proposal to extend the domainIncludes for schema:openingHours and/or
schema:openingHoursSpecification.
Would you care to submit it.

~Richard.


Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw

On 24 November 2016 at 12:05, 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
> @philarcher1
>
>