JSON-LD context (and frame)

[VladimirAlexiev]

To ensure that the JSON and RDF representation match perfectly, and to convert between them in the easiest possible way, it is best to use the JSON-LD standard:

• For JSON->RDF (parsing) it's enough to define a JSON-LD context
  • It's important that "pure" JSON can be interpreted as JSON-LD without any change, by using a HTTP header: see 6.1 Interpreting JSON as JSON-LD
• For RDF->JSON (serialization) the same JSON-LD context is reused, and a Frame needs to be added to describe which nodes to insert as JSON sub-objects.

I searched in this project and despite my expectation, didn't find anything about JSON-LD.

I have done this in several projects/communities and have enough experience to do this correctly for AAS:

• GS1 EPCIS (transport/logistics):
  • https://github.com/gs1/EPCIS/blob/master/epcis-context-simple.jsonld uses @vocab to keep the context short and simple. It would blindly convert an unknown key foo into RDF prop epcis:foo
  • https://github.com/gs1/EPCIS/blob/master/epcis-context.jsonld uses scoped (per-property/class) contexts and is quite longer, but is considered "safer"
• Electrical: IEC CIM, ENTSO-E CGMES:
  • https://github.com/3lbits/ElBits_Utillity_Standardization/issues/331#issuecomment-1869411338 : shows how we can assign short JSON keys to long RDF prop names (#43)
• Ontotext KG
  • https://github.com/schemaorg/schemaorg/issues/3455#issue-2104947023 (in YAML form): shows how we can attach different datatypes (date granularities) to the same RDF prop. Attaching datatypes could address #284 but the best way is to use @type in JSON, as specified by the JSON-LD standard

[mristin]

@VladimirAlexiev have you seen: https://github.com/aas-core-works/aas-core-codegen/blob/main/test_data/jsonld_context/aas_core_meta.v3/output/context.jsonld ?

Please contact @wiresio for more information.

[VladimirAlexiev]

@mristin I haven't, thanks! Have you tried it for JSON->RDF, and perhaps RDF->JSON?

[mristin]

@mristin I haven't, thanks! Have you tried it for JSON->RDF, and perhaps RDF->JSON?

I don't use RDF so I haven't -- @wiresio can you please provide more info?

[wiresio]

@VladimirAlexiev - Within the context of W3C WoT standardisation, we implemented a triplestore based Thing Description (TD) Directory API according to: https://www.w3.org/TR/wot-discovery/

For this we needed a proper JSONLD context to realize the roundtripping TD-JSONLD -> RDF -> TD-JSONLD. From the code - which will be soon put to open source - you will see that we had to correct the W3C WoT JSONLD context a bit, to really retrieve the semantically exact JSONLD back from the roundtrip. So, yes we did it for W3C TDs.

We also realized the idea of doing another roundtrip, actually realizing a data format conversion by doing TD-JSONLD -> RDF -> (SPARQL construct query) -> AAS-JSON. For the last step after the SPARQL query, we carried out JSONLD framing with the AAS context mentioned above. So yes, roundtripping should also work for AAS using this context.

[VladimirAlexiev]

https://www.linkedin.com/pulse/aas-core-codegen-just-learned-new-trick-christian-glomb-gr2wf/

[wiresio]

@VladimirAlexiev - Thanks for the extensive list in https://github.com/admin-shell-io/aas-specs/issues/384.

What do you expect from this issue? JSON-LD context for AAS v3 is there (and can be auto-generated for future versions thanks to the integration in aas-core-codegen).

[VladimirAlexiev]

Hi @wiresio and @mristin (and @mhrimaz)! Please see https://github.com/VladimirAlexiev/aas-core-codegen/tree/main/test_data/jsonld_context/trials#readme. The context almost works but needs 2 fixes (and sample data needs 1 fix).

Then see https://github.com/VladimirAlexiev/aas-core-codegen/tree/main/test_data/jsonld_context/trials#next-steps, in particular

• The context should live here with the spec, not over there.
• The context needs to be served from some permanent URL, with Content Type application/ld+json
• we can enrich the context to cover
  • https://github.com/admin-shell-io/aas-specs/issues/284
  • https://github.com/admin-shell-io/aas-specs/issues/382
  • https://github.com/admin-shell-io/aas-specs/issues/43

I'll also make a PR but please give me some feedback about file location and naming:

• Is it ok to replace context with context-fixed?
• Is the trials folder ok where it is?

Cheers!

[mristin]

@sebbader-sap @BirgitBoss should we move the JSON-LD here?

[mristin]

@wiresio can you please patch the json-ld context generator? I know too little about RDF and JSON-LD to know what to fix.

[mristin]

@VladimirAlexiev I think it would be best if you schedule a call to decide in a live discussion how we should go about RDF specification. I am irrelevant for the initial talks and decisions, but please insert me in the loop once you want to make changes to aas-core-codegen.

[wiresio]

@VladimirAlexiev - thanks for pointing this out!

@ethieblin - can you please have a look?

[sebbader-sap]

@sebbader-sap @BirgitBoss should we move the JSON-LD here?

Generally, it does make sense to put the context file also into the RDF schema folder. I can also create a proper redirect to have a nice looking URL for it. E.g. "@context": "https://admins-shell.io/3/0/context.json".

My main problem is that the whole RDF (in particular JSON-LD) needs more "love" (aka. "time"), which is currently the limiting factor. I know that the "WG Ontologies" also has a bunch of improvement proposals in their pipeline, which all together would create a sound picture.

If we can combine all these different activities, maybe in late April or so, I can certainly help too.

[VladimirAlexiev]

Hi @sebbader-sap, thanks for the response!

I should be able to give some "love" as part of Manufacturing Data Space project that just started. If IDTA is willing to change the RDF representation to make it better, then Ontotext will be happy to help. I have a call with @wiresio and @egekorkan on Mar 28 and maybe we'll discuss this (and eClass semantic representation).

Where is the "WG Ontologies" and their improvement proposals? https://github.com/admin-shell-io/aas-specs/issues/384 should go in there.

Cheers!

[sebbader-sap]

Where is the "WG Ontologies" and their improvement proposals?

It's an IDTA-internal group, I don't think that there is a public space. Is Ontotext an IDTA member? If so, you can join them.

[ethieblin]

Hello,

Thanks for your feedback on the JSON-LD Context.

I definitely agree that the ontology part of AAS needs more "love" :) And I agree with the " tickets you have created: xs:string, langStrings and the URI formation of the properties.

Regarding the JSON-LD Context:

• I agree that it should be served on the spec and made accessible via a dedicated URL
• I created a PR to add the wrapping "@context" tag in aas-code-gen.
• regarding the "modelType" to transform into "rdf:type" or "@type", we are currently using the jsonld.js to perform roundtripping. Note that it exports the RDF version in ntriples and not turtle. The framing based on the context in this actual form functions correctly. We do AAS/JSON + JSON-LD Context => N-triples that we store in a triplestore, then N-triples (queries from the triplestore) => AAS/JSON by using a frame based on the JSON-LD Context and the URI of the root node.

[VladimirAlexiev]

@ethieblin I use jsonld-cli (npm install -g jsonld-cli) which is also by digital-bazaar and (supposed to be) the same code that powers the playground. jsonld compact produces this, which is bad style

    "globalAssetId": {
      "modelType": "xs:string", // should be "@type"
      "@value": "something_eea66fa1"
    }

it exports the RDF version in ntriples and not turtle.

Yes (ntriples or nquads), that's why I use extra tools to make turtle so I can compare to the Turtle examples.

framing based on the context in this actual form functions correctly.

That's great! But we need more holistic examples to make sure

Please see https://github.com/VladimirAlexiev/aas-core-codegen/tree/main/test_data/jsonld_context/trials#next-steps and comment (here).

Can you please answer:

I'll also make a PR but please give me some feedback about file location and naming: Is it ok to replace context with context-fixed? Is the trials folder ok where it is?

After these trials are merged, we can more easily extend/correct them.

[VladimirAlexiev]

jsonld-cli (v2.0.0) has just been upgraded to jsonld.js v8.3.2+: https://github.com/digitalbazaar/jsonld-cli/issues/18

[ethieblin]

Ah yes you are right on the "modelType" vs "@type". The issue is more general. From my experience with JSON-LD framing, a context that overrides the JSON-LD keywords may often result in errors.

Having one of either of the following solutions should in theory give the same result. In practice, it may fall into an undefined behaviour of the JSON-LD framing libraries.

  "modelType": {"@type": "@id", "@id": "rdf:type"},

or

  "modelType": "@type"

For your comments

I'll also make a PR but please give me some feedback about file location and naming Is the trials folder ok where it is?

I am not a maintainer of aas-core-codegen repository, so I have little impact here. The file locations and naming are fine with me, or perhaps they could be placed in tests/jsonld_context as a report ? cc @mristin

Is it ok to replace context with context-fixed?

In this PR I added the wrapping "@context" tag. Please have a look. To me if modifications are to be made, they should be in the code that generates the context and not in the context itself (that may be overwritten by launching the code again).

[ethieblin]

Regarding the next steps you propose:

Produce a holistic Turtle example that includes as many submodels as possible, including numbers (decimal/float) and langStrings with real lang tags

We can also rely on the different JSON examples and RDF examples on the specs repository

Load some realistic AAS data in a semantic repository, and work on a Frame to produce several JSON messages according to JSON schemas

Not sure what you mean by "several JSON messages" you mean validation messages, error messages?

The context should live in https://github.com/admin-shell-io/aas-specs/, not in https://github.com/aas-core-works/aas-core-codegen/blob/main/test_data/jsonld_context/aas_core_meta.v3/output/

Agreed

The context needs to be served from some permanent URL, with Content Type application/ld+json

Agreed

Enrich the context to cover langStrings (https://github.com/admin-shell-io/aas-specs/issues/382) by mapping language, text to @language, @value.

That would require a change in the ontology and the specs examples as well

[mristin]

I'll also make a PR but please give me some feedback about file location and naming Is the trials folder ok where it is?

I am not a maintainer of aas-core-codegen repository, so I have little impact here. The file locations and naming are fine with me, or perhaps they could be placed in tests/jsonld_context as a report ? cc @mristin

Let me please clarify a confusion. The JSON-LD does not "live" at aas-core-codegen. It's were the generator lives. We simply recorded the output for V3.0 and used it as a golden data for tests. When the V3.1 comes (and future versions), we will probably not keep the outputs as test data.

The parties interested in the usage of JSON-LD definitely need to clarify whether you want to stick to aas-core-codegen (and patch the generator accordingly), take a hybrid approach (generate a base JSON-LD with aas-core-codegen, but then additionally write a script to patch it automatically or manually make changes), or go back to the manual specification.

It is probably best if you schedule a conference call, and make a decision. I fear that the discussions through GitHub issues are too scattered to come to a viable and thought-through solution.

[VladimirAlexiev]

@ethieblin

rely on the different JSON examples and RDF examples on the specs repository

Can you point me to examples with langStrings and datatyped values? I don't fully grasp the minimal/maximal philosophy, but I still think it'd be nicer to have a big realistic example so you can check all mapping features in one place, rather than having to check multiple files.

work on a Frame to produce several JSON messages according to JSON schemas Not sure what you mean by "several JSON messages"

When I wrote this, I didn't know that your Context also serves as a Frame. My point is this:

• imagine you have a semantic repo with a gazillion triples about a thousand AAS models
• before you Frame some response, you have to write a Query to get the data you need
• That data may be about multiple AAS, one complete AAS, only a submodel of an AAS, etc etc
• Are you sure your "Context as Frame" works for all these different cases? Won't you need to at least specify different "root points"?
• Do you have tests for such different cases?

This goes into future work on realistic use cases, so it may be too early to discuss...

I think most people think of AAS as documents: there are different file/message formats, hopefully with round-trip between them, there's AASX zip format, etc. But to work efficiently with this data, you need to store it somewhere. RDF repositories are databases that can accommodate such flexible data directly, no need for schemas or mapping into tables. Then to get out the documents you need, may require some tweaking of frames, or make

it may fall into an undefined behaviour of the JSON-LD framing libraries.

Please say more. I think mapping a prop to rdf:type shouldn't run this risk, but if it does we need to look at it very carefully. You do use "scoped contexts" but I don't remember whether they are local to type or property?

cover langStrings (#382) That would require a change in the ontology and the specs examples as well

Yep.

Same re Datatyped literals (#284): instead of

<https://admin-shell.io/aas/3/0/Property/valueType> <https://admin-shell.io/aas/3/0/DataTypeDefXsd/AnyUri>

we want to map to

"@type": "xs:anyURI"

@mristin

whether you want to stick to aas-core-codegen (and patch the generator accordingly),

This is definitely the best approach, if it is feasible. As we use more tricks in the context, it may become less feasible. You're best qualified to say whether it is feasible!

[mristin]

@mristin

whether you want to stick to aas-core-codegen (and patch the generator accordingly),

This is definitely the best approach, if it is feasible. As we use more tricks in the context, it may become less feasible. You're best qualified to say whether it is feasible!

I think it has to be a hybrid approach (generaee RDF+SHACL), then patch with a script.

Otherwise, the expressivity of RDF would need to be captured by aas-core-codegen, which is a huge effort.

[mristin]

@VladimirAlexiev

I don't fully grasp the minimal/maximal philosophy, but I still think it'd be nicer to have a big realistic example so you can check all mapping features in one place, rather than having to check multiple files.

Please see: https://www.researchgate.net/publication/374055610_Maturity_Evaluation_of_SDKs_for_I40_Digital_Twins about how we generated the examples.