admin-shell-io / aas-specs

Repository of the Asset Administration Shell Specification IDTA-01001 - Metamodel
https://admin-shell-io.github.io/aas-specs-antora/index/home/index.html
Creative Commons Attribution 4.0 International
47 stars 26 forks source link

RDF-native interpretation/profile #384

Open VladimirAlexiev opened 6 months ago

VladimirAlexiev commented 6 months ago

@sebbader in #45 on Sep 1, 2022:

We are also currently working on a way more RDF-native interpretation/profile in addition to the official RDF schema,

Sebastian, can you update us on the status of that effort? There are a number of issues that call for a better RDF representation, and are the subject of discussion. See https://github.com/linkedfactory/linkedfactory-pod/issues/7 by @kenwenzel for the pain one needs to endure writing SPARQL with the current AAS RDF representation.

There are also some bugs (eg in examples) that seem uncontroversial:

cc @mristin @mhrimaz @kenwenzel @arnoweiss

kenwenzel commented 6 months ago

Hi @VladimirAlexiev,

thank you for bringing this up.

We are also currently discussing:

mristin commented 6 months ago

Thanks, @VladimirAlexiev !

I do not use RDF myself, so I can't contribute much.

Pleaee mind that there is a perennial problem with the maintainability. The schemas were originally written by hand which turned out to be unmaintainable over the course of time. We ended up generating the schemas programmatically with aas-core using the formalized meta-model as a single-point-of-truth both for the schemas as well as the SDKs.

Many of the features you suggested are probably not possible right now due to the limitations in aas-core, but this should not be the blocker! If there is enough commitment from the volunteers, it probably make sense to generate the schema by hand, and then write a script to patch the additional features on top.

Alternatively, we could build in the features you need in aas-core. This would require additinal developers, which the aas-core maintainers lack at the moment. Of course, we are open for collaboration, so if anybody wants to work on that, I will gladly mentor.

VladimirAlexiev commented 6 months ago

@kenwenzel thanks! I added the two to the checkbox list in Description, and I'll see if I have anything to add to the discussion.

VladimirAlexiev commented 6 months ago

@egekorkan do you use AAS?

egekorkan commented 6 months ago

@egekorkan do you use AAS?

Yes. We also have integration of WoT into AAS via the Asset Interfaces Submodel where we also have converters for it.

VladimirAlexiev commented 6 months ago

Important comment: https://github.com/admin-shell-io/aas-specs/issues/386#issuecomment-2003555875

VladimirAlexiev commented 6 months ago

@sebbader-sap

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. 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.

Hi Seb!

Thanks for your replies!

kenwenzel commented 6 months ago

@VladimirAlexiev You can also take part in the WG as a non-member but you wont have access to the IDTA's Teams and Sharepoint. The process of the WG is not closed but currently we are just using files on IDTA's Sharepoint. This is something that can easily be changed if requested.

VladimirAlexiev commented 6 months ago

(I added two minor issues to the list on top.)

Thanks @kenwenzel! What is the "RDF-native interpretation/profile" that @sebbader-sap refers to? Is it "only" documents, or also machine-readable files?

@mristin wrote something important above:

it probably make sense to generate the schema by hand, and then write a script to patch the additional features on top.

You're most competent to make this judgement, but the JSONLD context gives us a lot of flexibility that we should leverage to cast the JSON to a reasonable RDF; only then resort to patches. This said, I'll help with the patches!