Re: Person and fictional Re: VideoGame proposal

First: Thanks for the table! The upper part of it clearly shows that the MTE approach is much simpler. As for the last statements, I disagree: It is not necessary to change the whole bases for schema.org nor to add negation, if we regard being fictional as a special form of being at all.

In more pragmatic terms: As long as all/most publishers of data that adopt the "new" mechanism for fictional stuff actually use the multi-type approach, we are all set. All fictional entities would be recognizable by the fact that they are schema:FictionalThings. A client that want to be sure that it does not list fictional things must include one more filter in its queries. But of how many applications are we speaking in here?

schema.org is evolving and it is tacit consensus that applications and data may have to updated over time as schema.org evolves, because we sometimes value an improvement higher that full backwards compatibility.

Martin



On 21 Oct 2014, at 21:09, Simon Spero <sesuncedu@gmail.com> wrote:

> On Oct 21, 2014 10:59 AM, "chaals@yandex-team.ru" <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
> 	• If you define a FictionalPerson as ( FictionalThing and Person ), central parts of the schema.org data model have to be changed.
> 	• Every application that only wants to handle non-fictional things must be rewritten to implement these changes, and perform all necessary inferencing. 
> 	• It is not self-evident that such use cases make up only a small minority of schema.org applications.
> 	• "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: 
> 	• Specify simple Function mechanism so that Fictional(?X) is a subclassOf FictionalThing; or
> 	• 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: 
> 	• Allow Functions to be specified so that they preserve subclassing; or 
> 	• 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: 
> 	• Define a mechanism to allow explicit negative assertions; or
> 	• 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?	
> 	• The specifications of the new semantics                       need to be defined by the schema.org partner.
> 	•  Some  changes to existing standards may require WHAT-WG approval;
> 	• 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: 
> 	• Check to see if types include either [<type> or Fictional(<type>)]; or
> 	• Create implicit union by giving both types in rangeincludes axioms; or 
> 	• 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 Wednesday, 22 October 2014 11:23:44 UTC