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

Yes, but this implicit new type is automatically marked as being a subtype of both types involved.

If you say

:foo a schema:Person, schema:FictionalThing.

it is clear for any data consumer that this is an instance of foo:Person, even if that client is unaware of the type schema:FictionalThing.

That is the power of using multiple types as "facets" in multi-typed entities.

Multi-typed entities have only one potential problem when it comes to properties: If the same property exists for both basic types, it is unclear to which "facet" of the entity the value of the property refers. But this is no real problem in schema.org, since we so far use a global meaning for all properties.

So as many have already argued: Let's take the multi-entity approach: It is clean, by andlarge backwards-compatible, and saves us from adding many new classes.

Martin



On 22 Oct 2014, at 05:55, <Simon.Cox@csiro.au> <Simon.Cox@csiro.au> wrote:

>> 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 11:11:11 UTC