W3C home > Mailing lists > Public > public-schemaorg@w3.org > November 2016

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

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>
Message-ID: <eaf7904f-ed1a-7ce1-1949-31f3fd864e78@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

This archive was generated by hypermail 2.3.1 : Thursday, 24 November 2016 15:17:11 UTC