cmungall
commented
4 years ago I represent the Open Bio Ontologies Foundry (http://obofoundry.org), which includes all the major ontologies used in the biosciences, including the Gene Ontology (http://geneontology.org, which I am also a principal investigator on).
Our community has been relying on JSON-LD contexts to bridge the gap between the prefixed identifiers (essentially CURIEs) used by the non-semweb world (for example GO:0006915) and URIs (e.g. http://purl.obolibrary.org/obo/GO_0006915).
All of the OBO ontologies use URIs of the same form, e.g http://purl.obolibrary.org/obo/$NS_, so the recent change to not automatically expand these will cause breaking changes, we are still evaluating what needs to be done.
Perhaps this is our fault for missing some key announcement but we don't see anything in the latest W3 recommendation for JSON-LD 1.0 that indicates that our expected behavior would only work for cases when the URI prefix ends in hash or slash.
I agree with @hsolbrig's summation.
This will also introduce quite a bit of complexity. We are still evaluating our actions but it seems likely we will have to publish two contexts, one for 1.0 toolchains and one more verbose one for 1.1 toolchains. This will be pretty confusing for our community.
It's also possible we may decide to abandon JSON-LD in many toolchains, and just keep the existing context files as our own simple json lookup files, with our own defined behavior for them. This would protect us against any future changes.
The OBO and prefixcommons communities have been maintaining prefix libraries as JSON-LD contexts. Many of the URI's in these libraries do not end with the standard set of terminators, the most common being '_'. These libraries (example: https://github.com/prefixcommons/biocontext/blob/master/registry/monarch_context.jsonld) serve several purposes: 1) As a mechanism to map prefixes in JSON to URI's via a JSON-LD processor. 2) As a formal database of maps that are accessed using plain JSON 3) As human-readable documentation
Note: Ignore the empty prefix in the front of these files -- they can, and probably should, be removed.
The current JSON-LD 1.1 specification requires the various context documents in these libraries to be changed from:
"BFO": "http://purl.obolibrary.org/obo/BFO_",toBFO": {"@id": "http://purl.obolibrary.org/obo/BFO_", "@prefix": true},This, however, breaks both 2) and 3) above and would require extensive, non-backward compatible edits.
There have been discussions about solutions on https://github.com/w3c/json-ld-syntax/issues/329, but it was decided that the solution to this issue would be postponed.
As a short term solution to this issue, we have tested a fork of the python rdflib-json-ld where pass a "prefix" parameter to the API that instructs the processor to treat everything it sees as a prefix.
@davidlehn has indicated that he would be open to incorporating a change of this nature into the javascript JSON-LD implementation and, if we can get something similar into the Java library that the OBO community is using, we should be able to "limp by" and maybe even have a vetted proposal ready to go assuming the W3C adopts the upcoming (ref?) incremental specification proposal