Reusing well-known JSON schemas

[Markus-Elfring]

Various data structures are popular, aren't they?

💭 Thus I imagine that they would be described also by the means of JSON schemas which should be reusable.
Where may schemas be referenced from public sources for information like the following? 🤔

• Events
• Persons
• Companies
• Products (example: GTIN)
• Dates
• Sales

[Relequestual]

Some work has been done to convert schema.org defined structures to JSON Schema.

https://github.com/postman-open-technologies/schemaOrgJSONSchema

These are not official in any sense, and not maintained, but you should be able to use the tool to update the schemas.

Maintaining such structures and their semantics are outside the scope of the JSON Schema organization.

[jviotti]

@Markus-Elfring What is your use case out of curiosity? I'm hoping to start maintaining a well-versioned curated collection of JSON Schema definitions here: https://github.com/sourcemeta/schemas (see https://schemas.sourcemeta.com). If there are a few you need, they are well defined and its easy to create small test suite, then I'm happy to take them in and maintain them myself.

[Markus-Elfring]

💭 I became curious if the community will evolve further also for sharing files (and related information) in the data format “JSON schema”.

🔮 Will development interests grow for corresponding data model descriptions?

[jviotti]

Will development interests grow for corresponding data model descriptions?

What do you mean by corresponding data model descriptions?

[Markus-Elfring]

💭 Some data types (also in their JSON representation) will usually be combined to data models, won't they?
🔮 How many efforts would software users like to invest in detailed descriptions?

[gregsdennis]

I think one major roadblock to this is specific domain business requirements. Many businesses have requirements around domain models that are specific to them.

Consider a Person model. While most businesses will require a firstName and lastName, some may consider that sufficient, while others also require dateOfBirth. How would you model these in a publicly (shared) person model schema? Would you only use the common denominator of properties?

If you don't, then some consumers has what they want, while others either have too much or not enough defined.

If you do, then it's likely it will be insufficient for all consumers, meaning that the schema we store is merely a starting point for them, and they'll have to either compose it with some other properties (e.g. with $ref) or copy and augment for their own uses, at which point, they're not referencing ours.

In the end, I think the best we can hope for is defining schemas to be used as a template rather than to be used directly. I'm not sure that accomplishes what you envision.

You may be able to create schemas for some standards, like Cloud Events, but even that is merely a template (meaning that the payload is still open for definition). $dynamicAnchor and $dynamicRef are perfect for this.