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

The Structured Data Linter takes schema:domainIncludes/rangeIncludes as hints, and sees if the declared type on the entity using the property is compatible with any of the listed classes (i.e., specifically that class, or any subclass). If not, it prints a warning message. Note that this site is intended for publishers to make sure that the markup “means” aligns with their intent, and not as a general way to determine if a particular page is “valid”.

Gregg Kellogg
gregg@greggkellogg.net

> On Nov 24, 2016, at 6:32 AM, Richard Wallis <richard.wallis@dataliberate.com> wrote:
> 
> 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 <http://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 <http://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 <http://dataliberate.com/>
> Linkedin: http://www.linkedin.com/in/richardwallis <http://www.linkedin.com/in/richardwallis>
> Twitter: @rjw
> 
> On 24 November 2016 at 12:05, Phil Archer <phila@w3.org <mailto: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 <http://www.heppnetz.de/>
> mhepp@computer.org <mailto:mhepp@computer.org>          @mfhepp
> 
> 
> 
> 
> > On 21 Nov 2016, at 16:39, Alex Prut <mail@alexprut.com <mailto:mail@alexprut.com>> wrote:
> >
> > Hello all,
> > I'm looking at the schema.org <http://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 <mailto:mail@alexprut.com>
> >
> -- 
> 
> 
> Phil Archer
> Data Strategist, W3C
> http://www.w3.org/ <http://www.w3.org/>
> 
> http://philarcher.org <http://philarcher.org/>
> +44 (0)7887 767755 <tel:%2B44%20%280%297887%20767755>
> @philarcher1
> 
>