Domain-specific vocabularies are crucial for accurate and consistent data interpretation by different individuals and systems. These vocabularies provide a shared conceptualization of knowledge within a particular domain. We observe the emergence of these vocabularies in diverse formats such as Smart Data Models, HR Open and Open Trip Model, which express their vocabularies in JSON or XML schemas.
Semantic Treehouse offers support to the user communities with their data sharing use cases. We provide a variety of features that allow you to publish, edit, browse, and maintain your own vocabularies. In this blog, I will provide further details about our new JSON integration to support JSON based schema design in Semantic Treehouse.
Before I proceed with further explanation, I would like to first clarify the distinction between the following concepts:
Vocabularies (artefacts): common language to ensure accurate and consistent data interpretation. This includes ontologies, reference data models, schema specifications, mappings and API specifications that can be used to annotate and describe data sets and data services.
A vocabulary provider (role): an entity that is responsible for providing(creating, publishing, maintaining) a common language, such as ontologies, reference data models, schemata, etc.
A vocabulary hub (tool): component providing facilities for publishing, editing, browsing and maintaining vocabularies and related documentation.
Semantic Treehouse currently supports vocabularies expressed in OWL ontologies and SHACL shapes. We are actively working on expanding our support to diverse vocabulary formats from various providers. This includes the development of support for vocabularies written in JSON schema. This means that data models like Smart Data Models, HR Open and the Open Trip Model can also be used. You can publish them or use them as a starting point in the FIT wizard to create your own message model.
Example: A very simple product schema
Similar to the ontology input, the concept behind the wizard is to select the required JSON Schema before specifying your own message model. For example, below is a basic JSON schema that Semantic Treehouse can import. It considers the cardinality and value constraints specified in the schema.
{
"$schema": "https://json-schema.org/draft-07/schema",
"$id": "https://example.com/product-0.schema.json",
"title": "Product",
"description": "A product offering and its characteristics.",
"type": "object",
"properties": {
"productId": {
"description": "The unique identifier for a product",
"type": "integer"
},
"productName": {
"description": "The name for the product.",
"type": "string"
}
},
"required": ["productId"]
}
After loading the JSON Schema in the FIT Wizard, it will present a message treeview displaying two potential sub-properties:
- Product
- [1..1] productID
- [0..1] productName
Now it is time to edit, maintain or publish this message model for your own domain-specific use case. In the meantime, we are actively working on enhancing this feature, beginning with the resolution of references to other schemas ($ref).
If you would like to know more, please refer to our documentation page of the JSON Schema input, or feel free to contact us. We are here to help!