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

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

Received on Friday, 16 May 2014 08:51:46 UTC