Precision of data and specifications in schema.org design (was Re: Article Proposal)

On Thu, Dec 12, 2013 at 6:40 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>
>
> On 12/12/13, 2:38 PM, Dan Scott wrote:
>
>> Hmm, I don't think possible limitations of the software creating the
>> data should be a strong rationale for designing the vocabulary. If a
>> developer claimed they couldn't parse extremely simple cases like
>> "123-456" or "pp. 34-45" into the appropriate pageStart / pageEnd
>> properties, they should probably start looking for a new set of tools
>> or a new job :)
>
>
> Dan, It is not up to us to decide what people's programs will or will not do
> nor what their data is or should be, or whose code is not "good enough." Our
> task here is NOT to determine what people SHOULD be doing, but to help them
> mark up what they do have. And when what they have could be just about
> *anything*, it is best to be generous.

I don't think this perspective can survive first contact with
http://schema.org/OpeningHoursSpecification, the affiliated primitive
types http://schema.org/DateTime and http://schema.org/Time, and the
http://schema.org/DayOfWeek enumeration on which it relies. Those all
have clear definitions of what people should be doing in their
schema.org markup if they hope to be understood correctly by search
engines.

I'm sure you know that in many cases the human-readable content will
remain as-is, but there will be a @content property or link@href
embedded in the markup that provides the machine-readable version of
the same content. As an example of where numberOfPages could handle
library-centric description/display practices and thus not have to be
conflated with the proposed "pagination" property, one could mark up
the number of pages for a book with 21 pages of preface/intro/ToC or
whatever and 356 pages of core content to conform to the current
definition of the property like so:

<span itemprop="numberOfPages" content="377">xxi, 356p.</span>
<-- Good for the humans, good for the machines! -->

schema.org sets standards for data quality because that makes it
possible for search engines and other processors to treat the data
uniformly across sites. We know, of course, that the search engines
will apply Postel's Law and try to deal with what they come across (in
areas where they are motivated to do so). But that's not a reason for
our group to conflate property definitions or put forth an ambiguous
specification in the first place. It is up to us to set the targets
for web publishers with the hopes that the web will offer better
quality machine-readable data as a result.

> I find this kind of remark to be ... unfortunate, let's say.

On the contrary, I think it's really important to have a clear idea of
what schema.org is about so we have a common understanding and common
goals in our efforts as a group.

Received on Friday, 13 December 2013 15:37:22 UTC