Expand domain of schema:inLanguage to all schema:Thing-s #1064
How does this direction relate to the multi-property situation I mentioned in #1079, ie. that we have already
http://schema.org/availableLanguage (of a ServiceChannel, ContactPoint)
http://schema.org/inLanguage (of a CreativeWork, Event, etc.)
http://schema.org/programmingLanguage (on SoftwareSourceCode)
http://schema.org/subtitleLanguage (Movie, ScreeningEvent, TVEpisode)
... and a fairly plausible proposal for a preferredLanguage Person property in #1084. Would you prefer each of these to be covered by inLanguage instead? Or would inLanguage perhaps be a superproperty? (that wouldn't work on at least subtitleLanguage since that kind of media content would typically have a subtitle language and a main language).
An event like a short meeting being 'in a language' is relatively straightforward. An event like a major historical event e.g. war being 'in a language' seems relatively meaningless. A country being "inLanguage" feels somewhere on a spectrum between those two. Many countries have dozens or hundreds of heavily used languages, as well as a smaller list of official languages. If we extend inLanguage to all scenarios then people will be left guessing which sense is intended for inLanguage applied to that type. Instead we might consider adding 'officialLanguage' and 'widelySpoken' properties associating countries with languages.
Counter proposal (since we are conservative about adding properties to Thing, especially when similar but different properties are available on more specific types):
- "we touched upon the need to expand the use of schema:inLanguage to products and schema:Website. "; -> let's add it to Product. Please note that http://schema.org/WebSite already supports inLanguage with no change needed.
- "We also have a use-case internally to apply that to schema:Country." -> let's investigate that. I've filed a dedicated issue as there are some subtleties. #1108
- "Finally, #561 wants to apply it to schema:EntryPoint." -> I'd suggest just adding it, unless the LinkRole mechanism wins everyone's favour.
let's add it to Product.
That would work for me.
I had a very loose definition for inLanguage in my mind: "The language attached to the item. Please use one of the language codes from the IETF BCP 47 standard."
Maybe it's weird to say that any Thing can be localized? I agree it is scary to add something on Thing but I cannot come up with a good counter example where it wouldn't work. We actually have several proposals about adding inLanguage to new types, without even trying to find a more appropriate term.
Please note that http://schema.org/WebSite already supports inLanguage with no change needed.
By the way, my example at #1065 (comment) wrongly used WebSite. I meant WebPage but it works there as well :-)
"Finally, #561 wants to apply it to schema:EntryPoint." -> I'd suggest just adding it, unless the LinkRole mechanism wins everyone's favour.
schema:inLanguageis currently limited to just a few types.In Question on expressing translations of terms, we touched upon the need to expand the use of
schema:inLanguageto products andschema:Website. We also have a use-case internally to apply that toschema:Country. Finally, #561 wants to apply it toschema:EntryPoint.I believe it should just be extended to all
schema:Things.