Re: Some interesting things that show up when using a reasoner to classify schema.org

> On Jan 22, 2015, at 11:31 AM, Dan Brickley <danbri@google.com> wrote:
> 
> On 22 January 2015 at 19:15, Simon Spero <sesuncedu@gmail.com> wrote:
>> On Jan 22, 2015 1:31 PM, "Gregg Kellogg" <gregg@greggkellogg.net> wrote:
>>> 
>>> The difference between using the unionOf and domainIncludes variation is
>>> that domainIncludes is open, and allows other vocabularies to extend the
>>> domain for their purpose (as, for example, yoursports.com does). Whereas,
>>> unionOf uses an rdf:List, which can't be extended. Other than the
>>> extensibility issues, then domain/rangeIncludes are essentially the same as
>>> unionOf.
>> 
>> That is one of at least two possible interpretations;
>> 
>> (1) domainIncludes statements are simply documentation, so that all domains
>> are :Thing, and all ranges are ( :Thing or :DataType ) ; OR
>> 
>> (2) domainIncludes for a given time interval form a closed union.
> 
> More the latter. It's a kind of "saying less than we might" to leave
> room for things to change.
> 
> In practice, most of the schema is mostly not changing most of the time.

I think this is something of a departure from the previous "openness" of domain/rangeIncludes.

Although I don't expect Webmaster Tools to look at anything other than schema.org, the Linter actually considers all vocabularies and/or JSON-LD contexts encountered, which could include a definition that adds a range to a SDO class.

Given the importance of schema.org as a foundation vocabulary which other vocabularies may extend, this seems important. Perhaps it should be considered a closed set for SDO classes during that time interval, but not choke on values that have a class defined in another vocabulary.

For example:

* schema:athlete has the domain of schema:SportsTeam, but in our modeling, a SportsEvent might also list the athletes that take part in it, so we "extend" the domain of schema:athlete to include schema:SportsEvent. (Of course, this could probably be handled as an update request for the vocabulary).

* schema:roleName will take Text or URL, but we'd like to be more explicit and define a class ys:Position with instances that describe the specific positions. The (vague) semantics of ys:URL seem to allow this usage, but not having a domainIncludes makes reasoning (such as it is) more difficult.

* schema:comment is limited to be used with CreativeWork, but IMO, it is useful for more things, such as Organizations, People and Events, so we extend it accordingly.

Being able to use schema.org as a base ontology for defining supplementary vocabularies is valuable, and restricting domain/rangeIncludes makes this problematic.

Gregg

>> When the bicycling guitarist was flagged by the Google rich snippet testing
>> tool for using the genre property on MusicGroup, after a domainIncludes had
>> been added to the schema, but before the tool had been modified, it strongly
>> suggests that the interpretation adopted by Google is (2).
> 
> The Google tooling is oriented towards helping publishers get their
> markup in a form that will be understood and used. It might sometimes
> use stricter sounding language than is formally justified by the
> underlying specs. There is also room for improvement around the
> possibility of things having multiple types (Book + Product being the
> canonical...).  Neither schema.org nor the Google tooling says much
> about that right now, although it is a useful option for decoupling
> awkward overlaps.
> 
> Dan
> 
>> Note that if the domain of a property is specified to be a  ( possibly
>> union) class, but ought be applicable to some thing that cannot an instance
>> of that class, then there is an error- either in the definition of the
>> property, the class, or in the specification of its domain.
>> 
>> Note that subclassing is still applicable.
>> 
>> Simon

Received on Thursday, 22 January 2015 22:10:23 UTC