Provide RDF mapping for Recipe content type

Problem/Motivation

In the Umami demo profile, the Article and Basic Page content types have have RDF mapping configuration (same as standard profile) but the Recipe content type doesn't.

We're missing a great opportunity here - the Schema.org vocabulary has a recipe type, with properties like our fields! Providing an RDF mapping for the recipe nodes would be an awesome way to show off this capability. RDF mappings with Schema.org can result in "rich snippets" in search engine listings, so It could be a good way to impress SEO evaluators. Also relevant for other linked-data applications.

Proposed resolution

Add a rdf.mapping.node.recipe.yml to Umami profile install config.

Challenges

1. There's no RDF UI in core, so evaluators might not notice this. How do we draw their attention to it?
   • Briefly mention it in a README for the Umami profile
   • Mention Umami recipe content type in RDF handbook page
   • Add RDF UI → module to core. Needs a separate issue, obviously :-)
2. Umami's difficulty field has no obvious mapping to a recipe property in Schema.org. Maybe we could just map it as the generic "keywords" property? or even leave it unmapped.
3. The schema.org prepTime and cookTime are expected to be output as ISO8601 durations (e.g. 15 minutes is PT15M). But our fields are just integer values. We would need some kind of format/converter method, similar to Drupal\rdf\CommonDataConverter\dateIso8601Value(). This could be a custom utility method somewhere in Umami profile, or better still add it as a useful method in RDF module (duration is a common property type in schema.org, several other classes use it apart from recipe).

Opportunities

The Schema.org Recipe class also has some properties which we don't yet have in Umami's recipe type. Maybe we could consider these:

• There's a recipeCuisine property. Now, we already have an unused Recipe Cuisine taxonomy vocab, but there's a proposal to remove it in #2990611: Remove empty taxonomies from Umami Demo → . Demonstrating Schema.org integration might be a good reason to keep it after all.
• There's a suitableForDiet property, which takes a RestrictedDiet enumeration in Schema.org. This is something we could implement using an Options field, or a taxonomy term reference.
• NutritionInformation is a complex sub type in Schema.org - probably too ambitious for Umami.
• A cookingMethod property (e.g. roasting) is available, separate from recipeInstructions.
• The recipeInstructions property provides the possibility of being more structured, but a simple "Text" mapping is also allowed - so that will do for Umami.

Remaining tasks

Figure out how (or whether) to address the challenges and opportunities above.
Patch.
Content update, possibly.

User interface changes

None.

API changes

None.

Data model changes

None.