Re: Proposal to extend rangeIncludes of DataTypes predicates in schema.org

Dear Mark:

On 12 Nov 2014, at 10:19, Marc Twagirumukiza <marc.twagirumukiza@agfa.com> wrote:

> Hi Folks, 
> This is a nice discussion and may certainly raise several other points but let's first see if extending the rangeIncludes of some data type may be a way forward. 
> The unique goal here to be "that major search engines tolerate XSD dataType information instead of plain strings for schema.org properties in RDFa." as Martin discussed. 
> If we could have a consensus on this I can submit a pull request in Git repo.Your position? 

As I have tried to express, I am against this proposal, because:

1. it will not have the intended effect and
2. it will cause confusion for average Web developers.

Simply adding XSD datatypes to rangeIncludes axioms will not guarantee that the Google validator, and more so, the Google/Bing/Yahoo/Yandex production systems will properly process typed RDFa literals with XSD datatypes.

For developers, changing "expected type" information from "Number" to "Number OR xsd:integer OR xsd:decimal OR xsd:float OR xsd:double" will make things worse, not better.

Also, schema:Number as a range definition does not match a single XSD datatype - you would have combine many.

I agree that it would be good if Google/Bing/Yahoo/Yandex tolerated XSD-typed literals in RDFa markup, but I think it is bad to broadly encourage developers to do so. Currently, the only ones who face the problem you describe are sites that want to publish data for Google/Bing/Yahoo/Yandex AND implement parts of the W3C Semantic Web vision. That is a minority. Of the 750 k sites that Guha mentioned, most of them are just publishing for major search engines.

Personally, I think that typing literal values at the instance level, as in RDF, is a bad idea, and rather a bug than a feature. We should not propagate that bug into schema.org.

Martin

PS: The problem with http://schema.org/Boolean is a different one.




On 12 Nov 2014, at 10:19, Marc Twagirumukiza <marc.twagirumukiza@agfa.com> wrote:

> Hi Folks, 
> This is a nice discussion and may certainly raise several other points but let's first see if extending the rangeIncludes of some data type may be a way forward. 
> The unique goal here to be "that major search engines tolerate XSD dataType information instead of plain strings for schema.org properties in RDFa." as Martin discussed. 
> If we could have a consensus on this I can submit a pull request in Git repo.Your position? 
> 
> Kind Regards,
> 
> Marc Twagirumukiza | Agfa HealthCare
> Senior Clinical Researcher | HE/Advanced Clinical Applications Research
> T  +32 3444 8188 | M  +32 499 713 300
> 
> http://www.agfahealthcare.com
> http://blog.agfahealthcare.com
> Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer 
> 
> 
> 
> From:        Simon Spero <sesuncedu@gmail.com> 
> To:        martin.hepp@ebusiness-unibw.org 
> Cc:        W3C Web Schemas Task Force <public-vocabs@w3.org>, Marc Twagirumukiza/AXPZC/AGFA@AGFA 
> Date:        10/11/2014 17:44 
> Subject:        Re: Proposal to extend rangeIncludes of DataTypes predicates in schema.org 
> 
> 
> 
> BLUF: Booleans are hard. Let's go shopping. [1]
> On Nov 10, 2014 5:14 AM, "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org> wrote:
> 
> > The only use-case where I see a need for datatype information attached to literal values is when the vocabulary allows multiple datatypes that the client could not distinguish automatiocally (e.g. think of a property that allows a xsd:string and xsd:boolean - then "True" may be a string or a boolean value). But that is a rare exception.
> 
> I am pretty sure that there is a property where this is almost happens, though the values are "Yes" or "No", not schema:True or schema:False.
> 
> And after cheating, I see it's legacy for  schema:acceptsReservations! 
> 
> schema:Boolean does not seem to be a true datatype in the way that Text is ; it has two instances, schema:True and schema:False. These values are described on the schema.org/Boolean page as being "more specific types" , but I am pretty sure they are instances (and clicking on the links goes to pages that render as instances).
> 
> The place where things might get confused is with Text and URL, since these are both literal valued and URL is sub-datatyped from Text.  This can occur on eg applicationCategory.
> 
> I believe that in this case a URL will not be recognized as a URL unless it is explicitly typed (unless microdata magic applies).
> 
> I expect that the documentation for Boolean could stand to be rewritten SMTP style - write the spec to match the implementation. That would give a lexical space different from xsd:boolean, and would handle the URI forms as constant strings.
> 
> BTW, requiresSubscription has a Boolean range, but does not appear on the Boolean page.
> 
> Also, Boolean is not a schema:Enumeration, despite having an enumerated set of values.
> 
> Simon
> 
> [1]  http://youtu.be/DzTWF1jVwH4
> 
>

Received on Wednesday, 12 November 2014 10:57:14 UTC