W3C home > Mailing lists > Public > public-vocabs@w3.org > January 2014

Re: http://schema.org/CreativeWork: headline and name properties?

From: Dan Scott <dan@coffeecode.net>
Date: Wed, 29 Jan 2014 11:26:48 -0500
Message-ID: <CAJcoVMhNJwuf4iviRsTqDWHxP6RrvUs_aB_S6_9qh7LMbJTUww@mail.gmail.com>
To: Matthias Tylkowski <matthias@binarypark.org>
Cc: SchemaDot Org <public-vocabs@w3.org>
Hi Matthias:

On Wed, Jan 29, 2014 at 10:59 AM, Matthias Tylkowski <
matthias@binarypark.org> wrote:

>  Am 27.01.2014 16:21, schrieb Dan Scott:
>
>  On Sun, Jan 26, 2014 at 3:26 PM, Wallis,Richard <Richard.Wallis@oclc.org>wrote:
>
>>  On 26 Jan 2014, at 08:06, Dan Scott <dan@coffeecode.net> wrote:
>>
>> * That said, the desire to disambiguate multi-type situations is
>> effectively why schemabibex proposed PublicationVolume/volumeNumber instead
>> of just relying on "name": given that one of our scenarios is the
>> combination of Book + PublicationVolume, we needed a way to disambiguate
>> the book title from the volume name.
>>
>>
>>  I think this pragmatic use of Type specific [additional] naming
>> properties in sub-types is a way forward. The headline property would
>> probably sit better in the NewsArtice sub-type than at the generic
>> CreativeWork level.
>>
>
>  _If_ they stick around, then I agree that headline / alternateHeadline
> should indeed get pushed down in the hierarchy... but given that we have
> name/alternateName at the Thing level, I would *really* like to see a
> concrete example of where a tertiary and quaternary level of specificity
> are necessary. It seems like one primary name + (repeated, if necessary)
> alternateName properties should be sufficient.
>
>  Publishers? *tap tap tap* Examples, please! :)
>
> Hello Dan,
>
> looking at some of the news providers that include markup (just picking
> random news entries)
>
>    - BBC News
>     - i.e. http://www.bbc.com/sport/0/football/25917101
>    - The Guardian
>     - i.e
>       http://www.theguardian.com/business/2014/jan/27/vince-cable-george-osborne-economic-recovery
>    - Le Figaro
>     - i.e.
>       http://www.lefigaro.fr/actualite-france/2014/01/29/01016-20140129ARTFIG00472-quelque-650000-euros-retrouves-en-liquide-chez-dieudonne.php
>
> they use schema.org annotations as below:
>
>    - BBC uses "schema:headline" for article title and
>    "schema:description" for the article lead
>    - Guardian uses "schema:name" and "schema:headline" together for
>    article title and "schema:description" for the lead
>    - Le Figaro uses "schema:headline" for article title and
>    "schema:about" for the article lead
>
> "schema:articleBody" is only marked up by Le Figaro.
>
> These values habe been retrieved using our microdata extractor form at
> http://getschema.org/index.php/Main_Page#Microdata2RDF_Service
>
> Should we conclude that "schema:headline" has to be used for article title
> and "schema:description" for article lead?
> (I'm guiding myself from wikipedia news article definition at
> http://en.wikipedia.org/wiki/News_article)
>

Thanks for checking some of the high-profile media sites!

Given that BBC and Le Figaro (the sites that use schema:headline) do _not_
use schema:name at all, and Guardian's use of both schema:name and
schema:headline to mark up the title likely reflects their own confusion
about the lack of distinction between the properties, it actually
strengthens my conviction that the conclusion should be "Use schema:name
for the article title, schema:description for the article lead, and
deprecate the use of schema:headline & schema:alternateHeadline"... because
the data shows that BBC and Le Figaro _could_ be using schema:name for the
title. They're not using schema:name for anything else, and it really is
the obvious choice that fits with the pattern we've established for pretty
much every other type.

Let's try to keep the core set of properties as slim as possible when there
is a clear overlap and no clear reason for minting new properties; that
will make it easier to provide guidance on best practices for those who are
publishing structured data with schema.org, as well as easier for those who
are parsing that data. The search engines and other processors are going to
have to continue to accept deprecated properties, of course, but the
schema.org docs could help direct new implementations towards the cleaner
path.

Dan
Received on Wednesday, 29 January 2014 16:27:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:36 UTC