Think more and come to some conclusion about JSON Schema and JSON-LD

[kdaily]

Placeholder for now. Briefly discussed ways of/reasons for modularizing the annotations. A common solution is JSON-LD:

https://json-ld.org/

[jaeddy]

+1

[sgosline]

🤔

[sgosline]

... 🤔 ... 🤔 ...

[sgosline]

Done.

[jaeddy]

The Human Cell Atlas (HCA) project seems to use JSON-LD for their schemas (see comment in #339). I don't quite get how it works yet, but might be a useful example for us to check out.

[sgosline]

@jaeddy and @kdaily and @karawoo will test drive some of our annotations using json-LD to get a feel for how it works.

[sgosline]

Oh wait, now you're asking for conclusions? Jeeezzzz

[sgosline]

Ooh, a cartoon description: https://www.youtube.com/watch?v=4x_xzT5eF5Q

[sgosline]

Meeting notes on updates: 1- Working branch is here: https://github.com/Sage-Bionetworks/synapseAnnotations/tree/sgosline-jsonld/synapseAnnotations/json_schema 2-Figure out which of our annotations are core vs. types vs. modules -cancer - @sgosline -neuro @kdaily -ngs-related stuff @jaeddy -analysis related stuff @blogsdon 3-Create ontologies under json_schema directory @karawoo 4-populate files

[sgosline]

Would this work as a validator? https://github.com/Julian/jsonschema??

[sgosline]

Another proposal from @jaeddy: store ontologies in OWL format (https://github.com/stain/owlapi-jsonld) - places like http://www.obofoundry.org/ store all ontologies in this format so we can go between custom/general formats with same tools.

[jaeddy]

To expand on this idea: we had already talked about storing any Sage-generated terms (that we couldn't link to public ontologies) in local ontology files. By using OWL (or a YAML/JSON format that can be translated to OWL), then I believe we could use the same graph restriction approach to define allowed terms — e.g.:

        "ontology": {
            "description": "An ontology term identifier in the form prefix:accession",
            "type": "string",
            "graph_restriction":  {
                "ontologies" : ["obo:chebi", "obo:efo", "obo:obi"],
                "classes": ["EFO:0004446"],
                "relations": ["rdfs:subClassOf"],
                "direct": false,
                "include_self": false
            }
        }

[karawoo]

I edited the title of this issue because I think so far we've really been talking more about using JSON Schema than using JSON-LD, and as far as I can tell HCA isn't using JSON-LD in any of their examples. @jaeddy I'd definitely love to talk about how we want to store our own ontologies. Maybe it's time for another meeting?

[jaeddy]

I didn't read this comment carefully until this morning. You're totally right! I don't think that JSON Schema and JSON-LD are mutually exclusive at all, but it seems like JSON Schema is a better fit for specifying (and validating) our... schema.

JSON-LD could enhance the functionality of annotation data, as JSON objects/documents generated based on our JSON Schema structure would include context and references. Whether this is something implement for managing annotations or ask the engineering team to support in Synapse is probably worth "thinking about" in a separate issue.

In the meantime, +1 for JSON schema and local ontologies (which I'm sure we'll figure out tomorrow)!

[milen-sage]

In case this is relevant, I'm working on an example using JSON schema validation on JSON-LD + a framing call, using our existing JSON annotations setup with contexts and refs. We can have a short discussion on that at next week's annotations working group meeting?

[milen-sage]

I've been in touch with Chunlei Wu from Scripps regarding CD2H efforts on JSON-LD/Schema.org based data models and metadata. Will update this issue based on our discussion. But for now, in my opinion, there are a few reasons to have annotations compatible with JSON-LD (even if that requires some changes to the annotation release code and annotation files; the latter can be automated to a large extent). Perhaps we can discuss at our next annotations' meeting?

[karawoo]

As this is now the purview of the metadata working group and has expanded beyond the scope of a single GitHub issue, I am closing this.