- From: Dan Scott <dan@coffeecode.net>
- Date: Sun, 26 Jan 2014 08:06:15 -0500
- To: SchemaDot Org <public-vocabs@w3.org>
- Message-ID: <CAJcoVMiwmfbULOqhX1mnZfZEpzGBcPNJXHzJJKeU8mTrjn0Nng@mail.gmail.com>
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 http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#json), 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: https://twitter.com/aaranged/status/365969834636349441 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? Thanks, 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