Uniform way to add multiple descriptive properties

Question

We use Schema.org 'types' and 'properties' to organize many kinds of data. The application is driven by the vocab and structure of Schema.org, rather than it uses schema.org for SEO. The application structures and relates finished and unfinished works of creative people like scientists, artists, composers etc. Their efforts are not limited to "Creative works" such as articles and artworks, but include also organizations, companies, events and products initiated by them.

Starting this year, we use Schema.org because we had problems in semantic structuring our data in the past. Now we are using Schema.org we make good progress.

For each item that we collect we use name and description (Thing properties) as descriptive fields. To be even more elobarate we want to add headline and alternativeHeadline or a similar Schema.org vocab for each item we store in our database.

The following default property list would be adequate for all the items our application deals with:

• name
• headline
• alternativeHeadline
• description
• image (non-descriptive)
• url (non-descriptive)

For all types derived from schema.org/CreativeWork the properties headline and alternativeHeadline match schema.org, but, for example, Event or Product do not have these properties. We could use the Thing properties alternateName or about, but these properties are obviously not equivalents of headline and alternativeHeadline.

In short: We look for a uniform way to add four basic descriptive fields to each item in our application, regardless its type. What would be the best solution?

Answer 1

I wouldn’t recommend to use only the Schema.org vocabulary. It’s not Schema.org’s goal to provide properties for all cases. It’s intended that authors use more specific vocabularies where needed.

Being RDF-based, it’s easily possible to use many different vocabularies for your data: schema:name for Schema.org’s name property, foaf:name for FOAF’s name property.

And this also allows you to use your own vocabulary for cases where you don’t find a suitable property.

The rest of this answer assumes that you have to use Schema.org for everything.

---

I don’t think that using headline/alternativeHeadline for Event or Organization makes sense. What is the headline of a company? What is the alternative headline of an event? While some might have an idea, there would most likely be no broad agreement, everyone would use it differently; so consumers wouldn’t know what to expect, rendering this property useless.

From your Organization example, I get the impression that you use these properties for something like a tagline/slogan/motto/catchphrase. It might or might not make sense for Schema.org to provide a property for such a purpose, but it shouldn’t be headline.

In the absence of such suitable properties, I would say that the content you have used headline/alternativeHeadline for should be either part of name or description.

Taking the Event as example:

• The headline could become part of the name: "The Entangled Universe: The extraordinary capabilities of the humand mind".
• The alternativeHeadline could be omitted, because it just gives the event location in prose, while this information is already conveyed to consumers with location. If the sentence really has to be part of the structured data (and not just displayed on the page), then it could be included in the description.

With the old extension mechanism, you could generate more specific properties based on existing properties. But it’s deprecated, and I wouldn’t recommend publishing data with such properties. But it might still be useful for internal use, as it allows you to use separate fields. For example, you could use properties like name/subtitle, description/where, or description/slogan.