Support @graph

[rob-metalinkage]

@graph is a bit of magic required to handle nested objects such as a STA datastream - where the top level is an anonymous object with no id.

check out
https://tinyurl.com/23ht6l35

however this gets munged to this if we try to set the schema of the values in that array.

"value": {
  "@context": {
    "@iot.id": "@id",
    "@iot.selfLink": "orel:iana/1.0/self",
    "phenomenonTime": "sosa:phenomenonTime",
    "result": "sosa:hasSimpleResult",
    "resultQuality": "sosa:resultQuality",
    "resultTime": "sosa:resultTime",
    "validTime": "sta:validTime",
    "Datastream@iot.navigationLink": "sosa:isMemberOf",
    "FeatureOfInterest@iot.navigationLink": "sosa:hasFeatureOfInterest"
  },
  "@id": "@graph"
},

test case @ https://ogcincubator.github.io/bblocks-sta/bblock/ogc.api.sta.Datastream.Datastream-Values-ObsCollection/semantic-uplift

[avillar]

The problem seems to be that rdflib doesn't process the @context inside the value property, while the JSON-LD playground does (provided that you set a base URL in the options for the bblock example!).

Reading the JSON-LD Processing Algorithm doc, I'm not 100% sure if it should, but I'm leaning towards yes (13.4.5 declares that @graph can be a property and that it should be recursively processed).

I'll see if I can apply a quick fix to rdflib; otherwise, as a workaround, we could treat '@graph' differently when building contexts.

[rob-metalinkage]

I think we will need to use the proper context, but if we have a single container with homogeneous entries the context would be ok at the parent level, so we could implement that with a caveat or check only one graph property is allowed/safe?

[avillar]

I've implemented the workaround in opengeospatial/ogc-na-tools@71b576d. Basically, if a @graph is found, it's inner context is appended to its parent, not to the term itself.

Check out the new context and the example's ttl.