JSON-LD 1.1 processing module.

[hsolbrig]

At the moment, we aren't certain about the state of PyLD. It appears to have at least some JSON-LD 1.1 processing in it, but it also isn't fully JSON-LD 1.1 compliant. In particular, see digitalbazaar/pyld#149 . We need to consult with the developers to determine where it sits and decide whether to:

• Put some effort into getting PyLD up to snuff and/or
• Use Py4J to wrap the Java JSON LD processor, which is fully compliant and maintained.
• Other possibilities?

The reason we need JSON-LD 1.1, by the way, is because LinkML slots are frequently context sensitive. As an example, in the following:

{
    "patient" : "12345",
    "name" : "Joe Smith",
    "labs" : [
          { "name": "HCT",
            "value": "55"
          }
      ]
}

"name" in the outer case might map to foaf:name and, in the inner case, perhaps fhir:Observation.code.coding. JSON-LD only allows one map per JSON member key.

[cmungall]

I am not in favor of a java dependency

I assume pyld is no longer maintained. There have been no commits to master in over a year. Is one option to make a fork and release on pypi under a different name?

But it seems that another possibility is to use the json-ld support in rdflib6, but this will be difficult as a lot of the linkml ecosystem is pinned to rdflib5? And it's not clear to me if rdflib6 supports the features we need, such as framing?

Another possibility is just to bypass json-ld altogether and do a direct conversion from objects to/from rdf? I think this will be simpler as we seem to keep running into jsonld context issues. I also see a few TODOs in the rdf_loader and it's not completely clear what the path is to fixing these

[cmungall]

Here is an example of how to convert directly from an rdflib Graph to instances of python linkml classes, without relying on jsonld, framing, or contexts - just using metadata about URIs in the schema:

https://github.com/linkml/linkml-sparql/blob/d97ac80773213d893fbaa7e42eb64905f9c3acf7/linkml_sparql/query.py#L107-L136

[hsolbrig]

We should take a close look at rdflib 6. It may be that if we fix the string decode issue, we'll be good to go. There are a number of other really nice features that make it pretty appealing, and, if someone is actively working on the rdflib-jsonld (now built in) the shortest path may be to help them finish that or maybe even just wait until it gets done?

[nlharris]

Can we close this?

[cmungall]

yes. We use using rdflib for jsonld1.1