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

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