Re: two new issues: schema.org booleans; xsd Time and DateTime

On 20 April 2012 22:25, Daniel Dulitz <daniel@google.com> wrote:
> Yes, it's great to have these issues opened. Not sure if I should comment
> here or on the individual threads... I guess I'll start here.
>
>> 1. http://www.w3.org/2011/webschema/track/issues/14  "Schema.org
>> booleans (True/False) vs RDF 'true/false'"
>
>
> This is the third time this question has come up: Martin raised a related
> issue in Aligning GoodRelations and Schema.org ("Action 3"). And in the
> Activity/Action proposal we ask whether schema.org should host generic
> instances of selected action types.

Thanks. That counts Martin twice, since I created the action as a
result of discussion regarding Good Relations integration.

> Have the schema.org sponsors already designed a general solution for this?
> If not, would it make sense to:
>   1. Retire any instances masquerading as types (such as schema.org/True and
> schema.org/InStock),
>   2. Define a few generic instances like
> http://instance.schema.org/Boolean/true,
> http://instance.schema.org/ItemAvailability/inStock, and (if the
> Activity/Action proposal is accepted)
> http://instance.schema.org/Action/review, and
>   3. Specify that when a property of type http://schema.org/Foo has text
> value bar, it is shorthand for the value http://instance.schema.org/Foo/bar
> ?

I like the idea of treating e.g. boolean properties with text value
'true' as a kind of shorthand. I don't see much value for using the
full URL http://schema.org/True in practice. I'm not yet sure about
the broader model you're proposing, but it doesn't sound implausible.

Martin's issue tracked in
http://www.w3.org/2011/webschema/track/issues/14 suggests people are
using (or expected to use) <link itemprop=”propertyname”
href=”http://schema.org/True” /> ... however I'm seeing no evidence
that people have adopted that idiom in practice. From the data I've
seen, textual values are more common.

To summarise some boolean investigations:

a) most boolean-valued schema.org properties receive 'true', 'false'
values, but there's also a lot of 'True', 'False', '1', '0' and
variations, in large part because we don't state very clearly how
these are supposed to be written out in practice. I'm not seeing URLs
like http://schema.org/True in the wild, though; anyone else?

b) the property http://schema.org/MediaObject  requiresSubscription 
(Boolean) has text "Indicates if use of the media require a
subscription (either paid or free). Allowed values are yes or no.".
... and is subsequently getting a lot of 'yes', 'no' values, but also
some true/false etc too. I consider this an error, but any changes out
to respect initial in-good-faith adoption (proposal below).

c)  mainContentOfPage (not officially a boolean)  appears in two
examples, with <meta itemprop="mainContentOfPage" content="true"/>
notation; consequently it is often being used that way in the wild.
See http://schema.org/Table and http://schema.org/ItemList

In this light I think we're ok with saying
 - the preferred use of a boolean-expecting property is with strings
'true', 'false' (this looks ok in both microdata and rdfa lite)
 - requiresSubscription documentation is in error; I'd suggest a new
text along these lines: "Indicates if use of the media require a
subscription (either paid or free). Expected values are 'true',
'false' (but note that an earlier version allowed 'yes', 'no')."
 - add an expected type of Boolean to mainContentOfPage (and evaluate
whether its existing expected type, WebPageElement is useful)

How does that look to you all?

> It may make sense to handle these internal enumerated values in a way
> similar to/compatible with ExternalEnumerations.
>
>> 2. http://www.w3.org/2011/webschema/track/issues/15 "Add Time for
>> xsd:time, DateTime for xsd:datetime"
>>
>> Daniel, could you take a look at (2.) in case it impacts on the
>> actions/activities model?
>
> Since issue 15 just defines datatypes, I think it's orthogonal to the model.
> Proposal looks good to me.

I think we should go ahead and add these though I would be happy to
see more scrutiny from others on the specifics, since this (as
Jean-Pierre points out) can be a slippery topic.

Proposal was:

"We need http://schema.org/DateTime for xsd:datetime A combination of
date and time of day in the form [-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm]
(see Chapter 5.4 of ISO 8601).
and http://schema.org/Time for xsd:time A point in time recurring on
multiple days in the form hh:mm:ss[Z|(+|-)hh:mm] as subtypes of
http://schema.org/DataType."

cheers,

Dan

Received on Friday, 11 May 2012 15:42:50 UTC