- 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