Open stain opened 5 years ago
Also related: Schema Playground (link dead for now?) by @chunleiwu et al. — see presentation
I've been making progress with two implementation options: An API payload example using RO-Crate 0.2 and a datastore (static json file) for a digital library PWA template using RO-Crate 0.2. Both of these implementations will need validation once they are live. I'm happy to test using some of the above validator options. Once we get further along, I could draft some documentation about steps for validation and guide folks through the process.
thanks @jasonclark Would be great to see your examples when you're back from holiday (enjoy!)
As a developer of software I want to validate my RO-Crate JSON output so that I can be sure it is valid according to the spec, without having to learn and test for each of the underlying technologies like JSON-LD, URIs and schema.org.
In particular JSON Schema is popular in JSON community, with a plethora of tooling available.
A challenge of validating a graph structure in JSON-LD using JSON Schema is the lack of hierarchy. With our use of
@graph
and flattened-compacted there is a more predictable structure which is easier to validate, at least for each block (given their@type
).So the idea here is not that every RO-Crate JSON would be validate against such a schema, but that if you followed the schema, your JSON would be valid; you would be making JSON-LD "by accident".
As further semantic checks might be needed (for instance the
@id
of aauthor
should point to a neighbouring block that has aname
), it might be possible to use RDF Shapes in SHACL or ShEx. While these are closer to the graph nature and much more natural for this use case, they are not as developer-friendly as they will be removed from the syntax used to make the JSON-LD. Thus a developer would not understand easily the RDF Shapes errors caused by for instance nesting a JSON element at the wrong level.Some related approaches that play along the duality of JSON Schemas, JSON-LD and RDF Shapes: