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

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

DayOfTheWeek is the datatype for days of the week. It is used to group valid values for openingHoursSpecification, but could also be used for additional properties.

The reason for openingHours and  openingHoursSpecification is that historically, schema.org had a lightweight text-based mechanism, and GoodRelations added a more granular mechanism.

In principle, both should also be valid for Place.

We could also try to harmonize both, i.e.g by merging openingHours and  openingHoursSpecification with a range of Text OR OpeningHoursSpecification

However, this complicates the processing, because the more granular version allows things like seasonal opening hours etc., and it will become very difficult to process data that mixes ISO-8601 text values with OpeningHoursSpecification nodes.

My hope is that more and more sites witll use OpeningHoursSpecification, which Google now recommends for advanced location page markup.

So I think the way to go is

1. encourage sites to use openingHoursSpecification
2. add Place to the domain of openingHoursSpecification

Martin

-------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  martin.hepp@unibw.de
phone:   +49-(0)89-6004-4217
fax:     +49-(0)89-6004-4620
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp 
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================
* Project Main Page: http://purl.org/goodrelations/




On 16 May 2014, at 21:30, Karen Coyle <kcoyle@kcoyle.net> wrote:

> 
> 
> 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 Sunday, 18 May 2014 22:11:32 UTC