RE: Person and fictional Re: VideoGame proposal

> It saves us from 
[explicitly]
> defining dozens of subtypes

When an entity has more than one type, the implication is that the intersection of the sets is not empty. 
Allowing multiple types just means that you potentially recognise all the intersections. 

Simon

-----Original Message-----
From: martin.hepp@ebusiness-unibw.org [mailto:martin.hepp@ebusiness-unibw.org] 
Sent: Wednesday, 22 October 2014 12:53 PM
To: Simon Spero
Cc: Jarno van Driel; Wallis,Richard; Dan Brickley; Peter F.Patel-Schneider; Thad Guidry; W3C Web Schemas Task Force; Charles McCathie Nevile; Karen Coyle; Dan Scott; Jeff Young
Subject: Re: Person and fictional Re: VideoGame proposal

I do not see the problem with using multi-typed entities. It saves us from defining dozens of subtypes or additional siblings for existing types. Clients who want to see only "real" entities, whatever real means, simply have to filter out entitities of type schema:FictionalThing, which is easy in any RDF- and non-RDF environment.

For http://schema.org/Person, there will be zero change in meaning, because the current definition already includes fictional people.
This is the most likely type for this use-case.

For other types like schema:Place, it may be necessary to filter out fictional entities, but since nobody is and will ever be able to consume raw, uncurated schema.org data at Web scale, I do not see the problem. The big consumers will or already have respective filters. Small consumers can easily add one line of SPARQL if they face problems.

Note that there are hundreds of reasons why a particular entity should not be shown to a matching query. For instance, you have to filter out all the offers from test installations of shop software, expired offers, data from forgotten and long outdated sites, etc.

Of course, we have a trade-off decision in here, but I strongly prefer to keep the additions to the schema.org vocabulary as little as possible, and not to pollute it with dozens of types for fictional variants of existing types. Using a property as a modifier is also conceptually less elegant, IMO.

Martin



On 22 Oct 2014, at 03:10, Simon Spero <sesuncedu@gmail.com> wrote:

> On Tue, Oct 21, 2014 at 5:47 PM, Jarno van Driel <jarnovandriel@gmail.com> wrote:
> "If someone can explain to me what the driving motivator is for taking this metaphysical stance is"
> 
> uh, in my case it has absolutely nothing to do with metaphysical anything. I write markup, and a lots of it. I look at what I need to disambiguate and seek for solutions which help me do so. The easier and more obvious those solutions are, the the bigger the chance is I'll apply them.
> 
> If the MTE route means it makes my life, and that of any other who has to deal with marking up pages, easier, than I'm a happy camper. Do I worry if it makes the work of those who have to extract that data fractionally more difficult? Nope not a bit.
> 
> Jarno - 
> 
> I think I understand what your concerns are now, so with luck I might be able to explain things better.  
> 
> Under the mix-in scheme, the page markup would look like: 
> 
> <div itemtype="http://schema.org/Person"  
>      itemtype="http://schema.org/FictionalThing" ...>
>    ...
> </div> 
> 
> Under the alternative I suggested, the page markup would look like:
> 
> <div itemtype="http://schema.org/Fictional(Person)" ...>
>    ...
> </div> 
> 
> The latter markup does not appear more complicated than the former, and has the advantage of not requiring making massive changes to the core of schema.org just to make extracting data possible!  
> 
> Under the first scheme, an application that knows about schema:Person but does not know about the new schema:FictionalThing will think it's looking at a description of a real Person.
>  There will have to be a new mechanisms devised to allow webmasters to say that something is not a FictionalThing. Then someone will have to explain it to them. 
> 
> Under the second scheme, an application that knows about Person, but does not know about Fictional(Person) will see an unrecognized type.  
> 
> Does this make more sense?
> 
> Simon

Received on Wednesday, 22 October 2014 03:56:06 UTC