/additionalType should explicitly allow Text

[danbri]

Reasoning:

• people do it anyway
• we create busywork for folk creating URLs or 404s by demanding URLs here
• computers are getting better at extrapolating sensibly what such things mean

[jvandriel]

I can live with that and actually have used it as such in the past to define very specific Product sub types (e.g. hair dryer, multi-styler, etc). Although it was mostly used for internal analytics and not aimed at external parties.

[rrlevering]

I'm so torn on this topic, personally. On one hand, I would be strongly opposed to it if I really cared about additionalType. This waters down the usefulness of the field as any sort of actual standardized type usage. It turns it into "typing hint".

However, since it was a hack to put it for a "mistake" made in the Microdata spec I don't really care. Google currently doesn't consume it as anything more than text for special cases ever (we don't map it automatically in some ways like we do for rdf:type-ish syntax).

[danbri]

@rrlevering yeah, I feel your pain. It's close to our "strings where we'd prefer things" pragmatism, but for the special case of this already awkward property. The message should always be if you want to be fully unambiguous, don't leave it as a string.

In terms of LLM capabilities, all of Claude+, ChatGPT(4.0) and Bard give sensible and reasonable answers to this super toy example:

For each JSON-LD example, resolve the string Minister to either a Wikidata entity URI for Q83307 (politician sense), or to Q1423891 (Christian cleric sense), or leave it as a string if unsure. Convert each example to Turtle syntax optimized for readability. The URL syntax is "https://www.wikidata.org/entity/Q{integer}", but remember to only do this if we are not leaving it as a string.

{ "@vocab": "https://schema.org/", "@type": "VideoObject", "name": "Footage of saturday's sermon", "about": { "@type": "Person", "additionalType": "Minister" } }

{ "@vocab": "https://schema.org/", "@type": "VideoObject", "name": "Footage of Friday's announcement", "about": { "@type": "Person", "additionalType": "Minister" } }

{ "@vocab": "https://schema.org/", "@type": "VideoObject", "name": "qfwrghethqxy", "about": { "@type": "Person", "additionalType": "Minister" } }

However they differ (reasonably) on whether the second example is best handled with one of the explicit URIs or with a string. So like I say, for unambiguity, pointing to a real schema makes sense. I just want to avoid adding friction if people want to quickly add a bit more detail without creating a maintenance burden.

[rrlevering]

One thing I will agree with is that people do it anyway.

From my data, I can see that it's more often used incorrectly than correctly. I can see a lot of cases of "Product" or something like a schema.org co-type (even in JSON-LD) without an absolute URI, assuming that it would work like @type where a vocab prefix is assumed.

[danbri]

Yes - been seeing that as well in people's expectations.

[github-actions]

This issue is being nudged due to inactivity.

[jvandriel]

To add another use case, if Google Merchant Center ever decides to support additionalType as an alternative for their [product_type] attribute, allowing Text will mean the values GMC has to deal with can be used 1:1 in any markup.

cc: @rrlevering, @alex-jansen

[alex-jansen]

Looks like this was already included in Release 16.0 on 2023-05-16, so closing the issue.