True On Mon, Apr 25, 2022, 5:36 AM Andy Seaborne <[email protected]> wrote:
> (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 > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >
