(this isn't a JSON-LD 1.0 vs 1.1 issue)
On 24/04/2022 18:49, Dan Davis wrote:
The dependency exists whether it is explicit or not, because the ecosystem
of packages that validate JSON documents revolves around JSON Schema, and
is not as mature for JSON-LD, at least in my limited experience. I mostly
lurk here because I maintain https://id.nlm.nih.gov/mesh/, which is MeSH in
RDF. Because it is just a representation in RDF, it is not truly Linked
Data. I keep wanting them to extend it to MEDLINE or link more
thoroughly to PubChem in RDF, but I am the implementer/maintainer. So, it
is on life support.
However, when we worked with the Cedar/BioPortal team it was very clear
that I would need to use JSON schema packages for Java to validate that a
JSON document matches JSON-LD. It wasn't only for me a format for output -
I needed to be able to validate that my instance was a valid instance
before submitting it to Cedar in code, because only the Cedar GUI did so.
So, aside from specmanship, I guess my question is how to validate that a
JSON documented matches JSON-LD for a particular ontology.
Sounds like you want to validate the RDF triples (SHACLC, ShEx) against
the ontology. It can be more complicated and deeper validation than just
validating the JSON input syntax - it's the triples that matter to MeSH.
Checking the syntax of the input is useful and this isn't an either-or.
Checking errors early can get them fixed more easily.
Andy
On Sun, Apr 24, 2022 at 1:23 PM Andy Seaborne <[email protected]> wrote:
On 24/04/2022 12:05, Dan Brickley wrote:
On Sun, 24 Apr 2022 at 11:12, Andy Seaborne <[email protected]> wrote:
Hi Dan,
Could you point to this dependency in the specs because I can't find
mention of JSONschema.
"schema" mentions are schema.org (for examples), XMLSchema (for
datatypes) and RDF schema for termninology.
I (a different Dan) dug around out of curiosity. I could not find a
formal
dependency in the W3C standard but there does seem to have been some
communication and collaboration between JSON Schema and JSON-LD teams, eg
to characterise (subsets of) the former using the latter.
Dan
Hi danbri,
Thanks for the research. That would place the interaction at the
writing/framing point of an output pipeline. Sounds interesting;
presentation of JSON-LD driven by domain-specific forms is more of a
"business logic layer" issue.
The Jena default output, as would be experienced from Fuseki, is
currently compacted, using prefixes as @context from the RDF data, and
has @version added. It is an JSON object, not an array, and carries the
information in the RDF data (triples and prefixes/@vocab). i.e. it
round-trips.
In the trade-off between better presentation, and switching over at the
next version, I think delays in switching 1.1 is delayed will slowly
becoming more painful and complicated for users to navigate mixed forms.
A hybrid JSON 1.1 input with JSON 1.0 output hasn't worked out.
Andy
Andy
On 23/04/2022 20:21, Dan Davis wrote:
It has always bothered me that JSONSchema is not an official standard
in
the way that XML and RDF/XML are. I know that JSON-LD 1 and 2 are more
standardized under W3C, but they depend so much on JSONSchema. Last I
checked, JSON Schema DRAFT 4 was the closest to a schema. Is the story
any
better now?
On Sat, Apr 23, 2022 at 2:40 PM Paul Tyson <[email protected]>
wrote:
On Apr 23, 2022, at 12:16, Andy Seaborne <[email protected]> wrote:
What should the default settings be JSON-LD 1.0 or 1.1?
1.1 would better meet my use cases.
Thanks,
—Paul
