-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keyword to indicate/restrict the schema of a target document of a property of type URI/IRI #55
Comments
Hey Simon, thanks for coming and sharing your suggestion. This sounds like quite a specific use case. Is this something you believe many people would want to do? Have you got an examples of people doing similar in the wild? Regardless, this sort of thing might be a good candidate for creating a new vocabulary. I'll move this Issue to the vocabularies repo. If you want to try making one and have questions, feel free to reach out. |
You can express this relationship with JSON Hyper-Schema. Hyper-schema allows you to represent links given a plain JSON document. Through those links, you can do things like hint at what the schema is for the resource at the other end of that link. Notice that's just a hint, not a contract. The result of following that link should self-describe what it's schema is and that is the authoritative schema that describe the resource. {
"$schema": "http://json-schema.org/draft-04/hyper-schema",
"type": "object",
"properties": {
"friend": {
"type": "string",
"format": "iri-reference",
"links": [
{
"rel": "full",
"href": "{$}",
"targetSchema": "/schemas/person"
}
]
}
}
} "friend" can also be just an identifier and you can use a URI Template to construct the href. "friend": {
"type": "string",
"format": "uuid",
"links": [
{
"rel": "full",
"href": "/person/{$}",
"targetSchema": "/schemas/person"
}
]
} Note: This example uses an older version of hyper-schema that I prefer, but you might choose to use a more recent version. |
Subobjects are helpful to aggregate dependant objects to a main object and we can use a subschema or
$ref
to restrict their structure.However, this is often not a good solution for independant but linked object, e. g. a friend is a standalone object that should not be nested or duplicated as a subobject.
As a solution you can make friend a property of type IRI that points to the target Person:
But in this case we will loose the information what schema an application should expect for the object pointed to by the given IRI. To solve this problem my suggestion would be a keyword somehow inbetween $ref (indicating a target schema) and $dynamicRef (only validated at runtime), e. g. $valuesFrom (similar to owl:someValuesFrom) or $range (similar to rdfs:range):
This would be helpful e. g. for web forms to generate the target object ad-hoc with the indicated schema but store only the reference (IRI) in the main object or in generated class structures where the iri is replaced with an object-memory-reference at runtime after creating instances from json input.
This would also close a main gap to schema languages for linked data (OWL/SHACL) so that interoperability (in combination with JSON-LD) could be achieved (see also json-ld/json-ld.org#612 (comment)).
Related:
The text was updated successfully, but these errors were encountered: