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

On 5/16/14, 6:23 AM, Simon Spero wrote:

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


I empathize with Simon here. Scrolling through schema.org I often 
experience a kind of mental whip-lash over things like the above. My 
training and experience warn me against fuzzy categories and seemingly 
narrow-minded declarations of category membership. The video game 
discussion shows me that we've gotten hip to these problems and are 
catching them earlier.

All discussion of taxonomic correctness aside, the key point seems to me 
to be: does it work? As folks actually create more data, it appears that 
"doesn't work" comes up frequently and there are attempts to iron out 
the problems. Perhaps the main question then is: is there any 
alternative to this trial-and-error approach to schema.org development? 
If not, then we should optimize for rapid change rather than up front 
perfection. The flat nature of the schema.org class and property names, 
along with the presumption that there isn't much, if any, reasoning 
being done on this data today, would argue for rapid change and a loose 
interpretation of already loose structure of the schema.

kc


>
> 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 <http://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 <http://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 <http://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
> <mailto:sesuncedu@gmail.com>> wrote:
>
>  > Message A:
>  > On Wed, May 14, 2014 at 1:14 PM, Markus Lanthaler
> <markus.lanthaler@gmx.net <mailto: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
> <http://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
> <mailto: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 <http://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.org <http://schema.org> properties 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 <http://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.org
> <http://schema.org> properties 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.
>  >
>  >
>  >
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Friday, 16 May 2014 19:30:43 UTC