- From: Phil Archer <phila@w3.org>
- Date: Thu, 24 Nov 2016 15:16:57 +0000
- To: Richard Wallis <richard.wallis@dataliberate.com>
- Cc: "schema.org Mailing List" <public-schemaorg@w3.org>
Done https://github.com/schemaorg/schemaorg/issues/1444 On 24/11/2016 14:32, Richard Wallis 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 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 >> >> > -- Phil Archer Data Strategist, W3C http://www.w3.org/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Received on Thursday, 24 November 2016 15:17:11 UTC