Re: ItemList

On Wed, May 14, 2014 at 07:14:14PM +0200, Markus Lanthaler wrote:
>On Tuesday, May 13, 2014 9:26 PM, Jason Douglas wrote:
>> Those are only there because it inherits from CreativeWork.  If people want to
>> use ItemList for all ordered lists, than we need to move that inheritance down
>> the chain, which is what Justin is proposing.  So only EditorialItemList would
>> inherit CreativeWork (and ItemList), while ItemList would not.
>
>No, that's not true (even though the way schema.org is rendered
>suggests that it is the case). You can use any property, not just the
>ones whose domain is that specific class (or a super-class thereof).

Hmm. That assertion appears to be at odds with
http://schema.org/docs/datamodel.html which states:

"""
2. We have a set of properties
  1. each property may have one or more types as its domains. The property
     may be used for instances of any of these types.
  2. each property may have one or more types as its ranges. The value(s) of
     the property should be instances of at least one of these types.
"""

In addition, under "Conformance" on the same page is the opening
statement: "While we would like all the markup we get to follow the
schema, in practice, we expect a lot of data that does not."

Those statements in the official schema.org docs suggest that the
domainIncludes statements for properties are, in fact, meaningful and
prescriptive. I do not think we should interpret statements that
"schema.org processors will try to do the best they can with what
they're given" as carte blanche to attach properties to any types we
like.

At least, I believe we should do our best to carefully situate
properties and types in the schema.org hierachy when we're discussing
the evolution or creation of new types and properties. If subsequent
data shows that practitioners consistently use an unexpected pattern of
type/property in the wild, that should certainly be brought back to
public-vocabs.

Received on Wednesday, 14 May 2014 17:54:11 UTC