@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.

/additionalType should explicitly allow Text #3304

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions