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. On Sun, Apr 24, 2022 at 1:23 PM Andy Seaborne <a...@apache.org> wrote: > > On 24/04/2022 12:05, Dan Brickley wrote: > > On Sun, 24 Apr 2022 at 11:12, Andy Seaborne <a...@apache.org> 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 <phty...@sbcglobal.net> > >> wrote: > >>> > >>>> > >>>> > >>>>> On Apr 23, 2022, at 12:16, Andy Seaborne <a...@apache.org> wrote: > >>>>> > >>>>> What should the default settings be JSON-LD 1.0 or 1.1? > >>>>> > >>>> 1.1 would better meet my use cases. > >>>> > >>>> Thanks, > >>>> —Paul > >>>> > >>>> > >>> > >> > > >
