Term definitions in context that support multiple values for @type?

[tcole3]

As noted in another issue, #20 (comment), and elsewhere, schema.org has several properties that can take a value which can be either a schema:Text or a schema:URL. For example, regarding the schema.org property encodingFormat (which supersedes the fileFormat property), schema.org suggests that values for this property be a:

"Media type typically expressed using a MIME format (see IANA site and MDN reference) e.g. application/zip for a SoftwareApplication binary, audio/mpeg for .mp3 etc.). ... Unregistered or niche encoding and file formats can be indicated instead via the most appropriate URL, e.g. defining Web page or a Wikipedia/Wikidata entry."

Their 3 examples use string values for encodingFormat: image/png, audio/mpeg, text/html, text/javascript, and text/css, but as explicitly specified in the definition quoted above, a URL would also be an acceptable value for encodingFormat.

Term definitions like this suggest a need for a new feature in json-ld that supports defining a term in a context so as to say that values for that term may be either a string or an @id (and similar combinations of primitive data types).

Or possibly a way in json-ld context to support user defined types that are unions of primitive data types.

Is this functionality already supported in some way? Or did this idea for a feature extension already come up in the Community Group and get rejected for some reason?

[gkellogg]

I think that for such terms, the default is to treat them as text. This is where it's useful to redefine terms if you want string values to be interpreted as URLs, dates, or whatever. Google does some sniffing to determine the format, but I don't think we want to try to get this right in the spec.

Tools like my own Structured Data Linter can be used to help identify when values aren't interpreted properly. Otherwise, to try to create a "smarter" @type definition on a term requires something like regular expression matching to try to parse between IRI, MIME, or whatever, which we've rejected in the past.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Close #121 wontfix, as the solution that isn’t ambiguous is very very complicated {: #resolution11 .resolution}

View the transcript

Term definitions in context that support multiple values for @type?
Rob Sanderson: ref: #121
Rob Sanderson: this came out of the sealing discussion
… timc notes that schema.org has properties that take either text or resource
… should we be able to say that a property accepts either type A or type B but not type C
Gregg Kellogg: schema.org should have different properties for differently-typed values
Ivan Herman: not really practical for schema.org users
Rob Sanderson: you can rep this in the instance doc itself, inline
… I say close won’tfix because it is unambiguous but ugly
Gregg Kellogg: e.g. if you have a property ‘author’ it could have values of many different types
Rob Sanderson: validation is not JSON-LD’s job, just mapping
Ivan Herman: in the context of schemo.org, can they properly define that something is say, a resource or a text?/
Ivan Herman: is it a case of “if it can be parsed as a URI it should be treated as such”?
general: no, that’s too error-prone
Ivan Herman: they (schema.org) have a canonical order of expectation
Gregg Kellogg: and schema.org doesn’t really use linked data
Proposed resolution: Close #121 wontfix, as the solution that isn’t ambiguous is very very complicated (Rob Sanderson)
Ivan Herman: +1
Adam Soroka: +1
Rob Sanderson: +1
Gregg Kellogg: +
David Newbury: +1
David I. Lehn: +1
Benjamin Young: +0 (missed most of the debate)
Gregg Kellogg: also http://linter.structured-data.org, which does it’s best to figure it out.
Gregg Kellogg: +1
Jeff Mixter: +1
Resolution #11: Close #121 wontfix, as the solution that isn’t ambiguous is very very complicated {: #resolution11 .resolution}
Harold Solbrig: +1