Semantics of schema.org (was Re: ItemList)

Message A:
On Wed, May 14, 2014 at 1:14 PM, Markus Lanthaler <markus.lanthaler@gmx.net>
 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). This basically
> result in an entity which has two types, ItemList *and* CreativeWork
> regardless of whether ItemList a subclass of CreativeWork or not.
>

On Wed, May 14, 2014 at 1:53 PM, Dan Scott <dan@coffeecode.net> wrote:

> [*Citing Message above*:]
> 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.
> """
>

The semantics of the schema.org primitives, like the semantics of named
graphs in RDF-1.1, are rather underspecified;  the primary difference is
the precision with which they aren't specified.

 schema;domainincludes and schema;rangeincludes necessarily have different
semantics to domain and range specifications in RDFS/OWL.

1. If we have two rdfs:range's for a property:

likes rdfs:range CreativeWork, Vehicle .

the range for likes is  (CreativeWork and Vehicle).

If the two types are disjoint(incompatible), the property is unsatisfiable.
 If the two types are not incompatible, then any value for the property may
be inferred to have both types.

2. If we have two schema:rangeIncludes for a property:

likes rangeIncludes CreativeWork, Vehicle .

the effective range for likes is (CreativeWork or Vehicle).

3.  It is *possible* that the effective domains and ranges of
schema.orgproperties serve as contraints, rather to license
inferences; if a value is
not known to be of an appropriate type, then a statement by not be
semanticaly well formed.

4. The effective range for a schema.org property can vary over time;  a
range can be extended by adding a rangeIncludes statement to the canonical
source.  However, the effective range at a given point in time is fixed,
and  statements when a given version of the range is in effect ought to be
expected to be one of the licensed types.
Inferences are thus not necessarily diachronically non-monotonic. Yeah, I
went there.

5. It is *possible* that the effective domain and ranges of
schema.orgproperties implicitly include schema:Thing, and that the
explictly listed
values are only intended to serve as documentation.

6. If  effective ranges and domains may be used to license inferences for
data and schema gathered at appropriate times, then there is an obvious
mapping to OWL.

If they are constraints, then reasoners that support negation-as-failure
(e.g. trowl) is useful.
A regular reasoner can be used to check a set of statements for
consistency, or  if an object is explicitly typed, it can be explicitly
declared to be not an instance of any non-superclass (or more concisely,
any non-superclass mentioned in an applicable range or domain.

7. Because there is no way to make negative assertions without using OWL,
only very limited inferences can be made from 'or'ed ranges.