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

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

From: Dan Scott <dan@coffeecode.net>
Date: Sun, 26 Jan 2014 08:06:15 -0500
Message-ID: <CAJcoVMiwmfbULOqhX1mnZfZEpzGBcPNJXHzJJKeU8mTrjn0Nng@mail.gmail.com>
To: SchemaDot Org <public-vocabs@w3.org>
Per the subject, CreativeWork seems a bit unusual in that the purpose of
its "headline" property appears to overlap the generic "name" property that
it gets from Thing. The examples at http://schema.org/Article and
http://schema.org/MedicalScholarlyArticle use "name" instead of "headline",
and grepping my local mirror of schema.org suggests there are zero usages
of "headline" in the schema.org examples.

I understand that this property came via rNews, perhaps due to a desire to
offer a simple equivalence for organizations already using rNews markup,
but I believe it just complicates usage for those employing native
schema.org markup.

While there are certainly cases where "headline" has been used for native
schema.org markup in the wild (such as the example at
due to the impossibility of predicting how schema.org processors will treat
the property, the most pragmatic suggestions have been to double up both
headline and name - see, for example, Aaron Bradley's tweet on the matter:

The one use case I could envision for maintaining the "headline" property
is in a multi-type situation involving a CreativeWork + some other type
where you want to differentiate the CreativeWork "name" from the other
type's "name". However, this could occur with many other multi-type
situations, and thus might warrant a more generic solution*. (I hesitate to
suggest this, as something like <type>Name for every type seems like the
most likely outcome... but there you have it)

So to promote a best practices approach for CreativeWork types going
forward, perhaps "headline" should be marked as "deprecated" with direction
given to using "name" instead?

Dan Scott

* 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.
Received on Sunday, 26 January 2014 13:07:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:21 UTC