OEM needs JSON-LD extension to support linking OEO entities

[christian-rli]

Linking to entities in OEO should be supported by oemetadata. It is not clear how this is done best.

It is nice to have the discussion public for later reference and also to have it in one place. Since this is intended to end up in the metadata string, I suggest discussing and making changes in this issue, rather than at the original LOD-GEOSS location.

I added file originally commited by @yum-yab . Feel free to make changes in the opened branch add new files and so on. We can clean up the branch before merging or restart with a tidy branch later.

[christian-rli]

We talked over the metadata extension and to me it seems most suitable to add the currently proposed keys with tiny adaptions plus another addition. To summarize the "diff":

• At the top level we will add something like"@context": "https://raw.githubusercontent.com/LOD-GEOSS/databus-snippets/master/oep_metadata/context.jsonld" to the json string. The target of this link should move to the metadata directory itself. It includes ontology links of a range of keys in the original json. Currently, most of those links don't point to the OEO. It was just a dirty draft from Uni Leipzig. By now I think we should be able to replace a few links with OEO references. The point is mainly that there is a public link of what's meant by the metadata keys in ontology terms. This should be specific to the version of the metadata string and ideally all terms should be covered by the OEO
• Add links like "@id": "https://databus.dbpedia.org/denis/lod-geoss-example/api-example/2021-05-10/api-example_type=turbineData.json" at the top level to link to the resource via the databus. @yum-yab what are the added benefits of routing this through the databus? I see that there is a benefit of having a direct link to the raw data, but shouldn't the registrations at the databus work independent of that?
• Added at top level: "subject": "oeo:OEO_00000448" to reference the topic of that data table (if that applies)
• Added at table column level: "is_about": "oeo:OEO_00230002" to describe the column head. @jannahastings is that a good name for the key or an abuse of the topObjectProperty?
• Finally, there should be a second field describing the column, which I am spontaneously going to name "value_reference":"some_rdf_snippet". The idea is, that there is a difference between the header of a column and the values within. The values can require a complex description. In my view this could be a solution to many terms that the IAMC templace wants from the OEO. There are many terms that are conceptually the same, but can use a little addendum to be specific, e.g. sulfur emissions from transport and sulfur emissions from industry. I am quite uncertain about this last suggestion. @jannahastings or @MGlauer is it possible / does it make sense to add a more complex rdf description within the (json)metadata string? Are there better ways? Am I misunderstanding a concept?

Sorry for the long comment, I'd appreciate feedback even for just smaller part of this.

@giannou @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q @JJ-Author

[christian-rli]

@jannahastings you commented in the issue linked above _https://github.com/OpenEnergyPlatform/oeo-extended/issues/4 that there are pre-composition and post-composition approaches. I think my last suggestion would fall under the post-composition approach, which you advised against. Is it still useful to keep such a field for the occasional ontology nerd or should we drop the idea altogether? @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q pointed out that we had a point on the two approaches on the agenda of an ontology developer meeting (namely # 16) but I can't quite figure out whether we got to it in any depth or postponed the topic without picking it up again. The notes in the wiki are inconclusive to me.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

I think my last suggestion would fall under the post-composition approach, which you advised against. Is it still useful to keep such a field for the occasional ontology nerd or should we drop the idea altogether?

From my understanding, both approaches are compatible with another and not exclusive. I can see ontology development being done by "experienced users" (or one-eyed kings with thick sunglasses among the blind, like me) in post-composition and integrated via pre-composition in the ontology proper after testing, discussion, and consensus.

[jannahastings]

@christian-rli I think your proposal above sounds sensible, and I think for a use case linking such closely related projects such as the OEP - OEO, having a pipeline that supports post-coordination is absolutely sensible to avoid unneeded frustrating delays. Of course, as @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q says, some of the post-coordinated expressions will make their way into the ontology class definitions over time.

(I also think that the column name is about is fine where you suggest it :-).)

[JJ-Author]

• Add links like "@id": "https://databus.dbpedia.org/denis/lod-geoss-example/api-example/2021-05-10/api-example_type=turbineData.json" at the top level to link to the resource via the databus. @yum-yab what are the added benefits of routing this through the databus? I see that there is a benefit of having a direct link to the raw data, but shouldn't the registrations at the databus work independent of that?

@yum-yab I think this identifier does not necessarily need to point to the databus file, right? or we could inject it when transforming the json to the RDF using the context. the connection via the databus file and the OEP metadata is given primarily already through the "Databus OEP annotation mod"?

• Finally, there should be a second field describing the column, which I am spontaneously going to name "value_reference":"some_rdf_snippet". The idea is, that there is a difference between the header of a column and the values within. The values can require a complex description. In my view this could be a solution to many terms that the IAMC templace wants from the OEO. There are many terms that are conceptually the same, but can use a little addendum to be specific, e.g. sulfur emissions from transport and sulfur emissions from industry. I am quite uncertain about this last suggestion. @jannahastings or @MGlauer is it possible / does it make sense to add a more complex rdf description within the (json)metadata string? Are there better ways? Am I misunderstanding a concept?

@christian-rli I need a concrete example for this, for one column please (so is_about and value_reference filled out)

[christian-rli]

@christian-rli I need a concrete example for this, for one column please (so is_about and value_reference filled out)

I updated the example string with the help of @chrwm . is_about works like subject:

"subject": "OEO:00000448", "is_about": "OEO:00140000",

I'd like to discuss value_reference in our meeting again. As of now it's basically a placeholder to allow for RDF formatted references. As I am not actually familliar with RDF, I need to check back in, to establish what's a reasonable way to fill that field.

[Ludee]

Did the implemented new values meet the requirements from the OEO? As far as I see it is solved and can be closed?

[jh-RLI]

@chrwm The issue will be closed as soon as the relase branch for version 1.5.0 is merged. Please let me know if you want the issue to stay open.