- From: Simon Spero <sesuncedu@gmail.com>
- Date: Tue, 21 Oct 2014 15:09:55 -0400
- To: Charles McCathie Nevile <chaals@yandex-team.ru>
- CC: W3C Web Schemas Task Force <public-vocabs@w3.org>, Dan Brickley <danbri@google.com>, "Wallis,Richard" <richard.wallis@oclc.org>, "Peter F.Patel-Schneider" <pfpschneider@gmail.com>, Thad Guidry <thadguidry@gmail.com>, Karen Coyle <kcoyle@kcoyle.net>, Dan Scott <dan@coffeecode.net>, "Young,Jeff (OR)" <jyoung@oclc.org>, Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Message-ID: <5446AF83.3000903@gmail.com>
On Oct 21, 2014 10:59 AM, "chaals@yandex-team.ru <mailto:chaals@yandex-team.ru>" <chaals@yandex-team.ru <mailto:chaals@yandex-team.ru>> wrote: I agree that it is important not to get too hung up on metaphysics. But it is also important not to get hoisted on our petards… Spot on! And it's the engineers who get hoisted... * Let me try and explain the /real world/ consequences of the proposed FictionalThing mixin. ------------------------------------------------------------------------ *BLUF* 1. If you define a FictionalPerson as ( FictionalThing and Person ), central parts of the schema.org data model have to be changed. 2. Every application that only wants to handle non-fictional things must be rewritten to implement these changes, and perform all necessary inferencing. 3. It is not self-evident that such use cases make up only a small minority of schema.org applications. 4. "Elves" have to do more typing. ------------------------------------------------------------------------ /For purposes of this example, assume that the Person type is restricted to actual persons, living or dead (the kind who fictional characters resemble only "coincidentally")./ The following table compares and contrasts the Mixin approach to an approach using a separate class, derived from Person, but not a subclass thereof. My primary concern is to illustrate the implementation burdens of the different approaches. A Fictional Person is an instance of (FictionalThing and Person) A Fictional Person is an instance of a class derived from Person e.g. "Fictional(Person)" What is needed to assert that something is a Fictional Person? Two types must be asserted for each instance One type must be asserted for each instance. Is every Fictional Person a FictionalThing? Yes Yes What changes are needed to infer this? None Either: 1. Specify simple Function mechanism so that Fictional(?X) is a subclassOf FictionalThing; or 2. Explicitly assert that Fictional(Person) is a subclass of FictionalThing /Note that FictionalThing could be defined as equivalent to Fictional(Thing)/ Where do these changes need to be made? N/A Expansion and related inference can be handled on schema.org, or on the client side. If Person is a subclass of Mammal, what changes are needed to infer that a Fictional Person is a subclass of a Fictional Mammal? None Either: 1. Allow Functions to be specified so that they preserve subclassing; or 2. Explicitly assert that Fictional(Person) is a subclass of Fictional(Mammal) Where do these changes need to be made? N/A See above *Is every Fictional Person a Person? * *Yes * *No * What changes are needed to infer this? None None What changes are needed to infer that a Person is not a Fictional Person? *The data model of schema.org needs to be changed to support negation. Either: * 1. *Define a mechanism to allow explicit negative assertions; or * 2. *Specify a set of inference rules including Negation as Failure, explicitly defining the scoping rules for determining what facts are relevant. * *The data model must also be changed to handle inconsistency. * None Where do these changes need to be made? 1. *The specifications of the new semantics need to be defined by the schema.org partner.* 2. * Some changes to existing standards may require WHAT-WG approval; * 3. *Some changes to existing standards may require chartering new W3 working groups.* *Once these specifications are in place, all inferencing must happen on the client side. * None What changes need to be made to applications that only wish to handle Non Fictional instances. *All changes listed above. * None What changes must be made to applications that want to handle instance of various types, but do not care whether an instance is Fictional? Check for the presence of the specific type. Either: 1. Check to see if types include either [<type> or Fictional(<type>)]; or 2. Create implicit union by giving both types in rangeincludes axioms; or 3. Define a RealOrFictional function, such that RealOrFictional(Person) is a super class of Person and Fictional(Person). What changes must be made to applications that wish to handle only instances of various Fictional types? Check to see if the types for the instance includes both the desired type and FictionalThing Check to see if the types for the instance include Fictional(<type>) Unless most applications are indifferent to whether individuals are real or fictional, imposing such a significant burden on applications that only wish to handle non-fictional individuals requires justification. Simon * Statement issued by Hamlet following his stabbing of Polonius several times through a closed Arras, claiming to mistake him for a Rat.
Received on Tuesday, 21 October 2014 19:10:26 UTC