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