Re: Semantics of schema.org (was Re: ItemList)

Would that I were working on a more detailed specification 😕. It's as much
as I can do to work on more detailed questions...

Text marked up with ambiguously defined labels is ambiguous. Ambiguous
mechanisms for defining labels make things even worse.

Creating *too* loosely defined terms is almost as good a way to have them
misapplied as having too rigorously and complexly defined terms.
Friends who did quantitative studies of Dublin Core term usage were only
slightly surprised at the number of times titles were stored as subjects
(looks up at headers on this message...).

domainincludes and rangeincludes are worrisome constructs in this context.
If they are more than documentation or general suggestions, then they must
be told so as to be understood so they will be believ'd. *

Even in the "canonical machine readable" RDFa, there are duplicated
properties with inconsistent comments and duplicated includes statements.

What does "expected" mean? Expected as in "England expects", or expected as
in "I was expecting someone taller"?

DayOfWeek is not a day of the week; it's part of an
OpeningHoursSpecification. That's not a valid value for openingHours though
it is for openingHoursSpecification.
Only the latter is defined for Place. Both are defined for LocalBusiness.
What if both are used? Double opening hours! Double opening hours! What
does it all mean?

Enough! Or too much.*

Simon

* The crow wished everything was black; the OWL that everything was white.
http://www.blakearchive.org/exist/blake/archive/object.xq?objectid=mhh.h.illbk.10&java=no
Thanks for your efforts to work on a more detailed specification of the
schema.org semantics. I am a bit sceptical about the impact, though. The
effect of this will be mostly limited to better govern the evolution of the
schema - e.g. avoiding inconsistencies in the specification. Data published
on the Web will not increase by adding more axioms to the ontology or being
more precise in the specification, because the human minds that add
schema.org types to their markup do not process axioms. They read textual
descriptions.

Also, the quality of data will typically depend on the consistency of the
databases that power the Web sites. If a booksellers database mixes used
books (individuals) with book titles (product models), then schema.org has
little means for adding this distinction to the structured data exposed by
the site.


Martin



On 14 May 2014, at 22:31, Simon Spero <sesuncedu@gmail.com> wrote:

> 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.
>
>
>