5 likes
·
2.6K reads
6 comments
Is is worth tying these ideas into the concepts of open-world and closed-world views, and the consequent fairly natural match with RDF, and JSON-LD ?
My understanding is that an open world allows for indeterminate truth values. Unless there's an error in the schema, it's always possible to determine whether a given instance is valid with respect to a given schema. It's just that the starting point (the empty schema) allows everything. So that would seem to me to be a closed world approach.
Does indeterminacy in an open world express a limitation of modeling a world, or indeterminacy in the model itself? (The map is not the territory, but given a map can truth be indeterminate?)
All sorts of vagueness exists in the real world, "Fred is bald" includes at least two: "which Fred?" and "what is bald?" But does an open world model require that subjects have a unique instance id and that the "bald" attribute is a binary type (or an integer threshold for number of hairs on the head)?
I'd assume that an open world model does not allow vagueness-based indeterminate truth (it follows the law of the excluded middle). Are there different scenarios where indeterminate truth is permitted in the model?
(Attributes can be optional, and if a subject does not have a "bald" attribute then the question cannot be answered for that subject. But that applies to both closed and open worlds.)
While I understand the point this is making, it seems that many of the popular uses of JSONSchema are for "Definitions" (API Contracts). These typically are then used directly for "Code Generation".
Would you say that this is outside the scope of what JSONSchema was designed for?
Yes, and since I'm also very involved in the OpenAPI Specification, I'm very familiar with this mismatch and the problems it causes. We did try to address that in an appendix to the modern JSON Schema drafts , to show how to bridge that gap, but it hasn't really caught on so far. (apologies for the very long delay in replying, see my "Coming Out of Hibernation" post for an explanation)
This is a very eloquent articulation of an aspect of JSON Schema I've struggled to describe, making do with "in code we often describe what a thing is; JSON Schema describes what a thing isn't".
May I ask though: why? JSON Schema is--I presume--intended to serve programmatic uses. Why choose a constraint model that's at odds with a structural (or "object oriented") approach?