Use a graphical tool to generate OWL from a UML Diagram

[RaggedStaff]

Currently we are manually editing our ontology files in Protege. This is a highly technical tool, with an obscure interface. In order to discuss/demonstrate concepts we are creating UML diagrams to discuss/review, before translating those into OWL.

In the Connector work, @lecoqlibre is manually creating a UML diagram, from the OWL files, to feed into the code generator.

At last weeks Ontology call, @Alcoz mentioned Chowlk - a tool that can generate our OWL files from diagrams.

If we used the UML diagram as the basis for our ontology, it would:

1. Simplify the process of creating/updating ontology files.
2. Provide a source for the Connector code that is complete & requires minimal further modification (I think the Connector model has a super class to contain everything, perhaps we could automate the creation of that 🤔 )
3. Provide a clear visual representation of our ontology that can be easily understood by a much wider, non-technical, audience.

Can we start doing this as soon as possible?

Does it make sense?

What do you think @simonLouvet , @lin-d-hop , @RachL , @carolinebrakel ?

[RaggedStaff]

@Alcoz I'm wondering how much effort it would be to create the initial diagram to generate the ontology files, or if there's a facility to generate it from the owl files?

[RachL]

Makes sense to me, thanks @RaggedStaff but I'm not impacted by this decision, so let's see what the rest of the ontology team thinks!

[lin-d-hop]

This sounds like a great approach to reduce errors, increase maintainability and include more people in the discussions. I would be in favour of exploring this more.

But also agree with @RachL - this primarily needs to buy in of the ontology team. Has everyone been tagged? i don't know who is in the ontology team to tag them to comment.

[RachL]

You can use @datafoodconsortium/ontology-maintainers but I think we got every one already :)

[lecoqlibre]

This looks like a great idea indeed.

We did think about it at the beginning of the UML design. We probably started with an UML model to reduce the complexity and also to validate the connector approach in the first place.

Data models (UML) and ontologies (OWL) are different objects. Ontologies describe a domain, its concepts and relations while a UML model designs a particular implementation in that domain (the connector is a particular application in the DFC domain).

The UML model copies a lot of information that is contained in the ontology but it also adds missing information it needs to achieve its particular goal. I understand it sounds like frustrating and I agree that it would be nice to generate the connector directly from only one source of truth of the DFC project.

But if we want to generate the ontology from the UML model we will need a way to express some information that is not part of the UML language. We can do it because UML is extensible but it this really a good idea? Doing this might be like reinventing the wheel of the OWL language...

Another option would be to use the Shapes Constrain Language (SHACL). As it allows to constrain ontologies, it could be used to generate code. Like the abstract says:

[SHACL] may be used for a variety of purposes beside validation, including user interface building, code generation and data integration.

This option would require us to update the Shapes when we update the ontology. We will be able to generate the connector code directly from the Shapes or from a UML model generated from the Shapes.

[lecoqlibre]

We also discussed about using VocBench to edit the ontology collaboratively. So we would have one tool to work on ontology and taxonomies. But we don't know yet if VocBench would provide the same tools like Protege. Baptiste will investigate this question.

We decided that I will investigate on using Shapes to generate the connector source code from.

[lecoqlibre]

I had Etienne Juliot from Acceleo on the phone. It's possible to use Shapes in Acceleo but we need a meta-model in EMF + a parser. I will have a meeting with a technical export from Acceleo soon to have more details. Acceleo can do it for us or help us. They charge 1200€/day. @RaggedStaff

I got some advises from Thomas Francart on this thread (French).

My colleagues from Inria also mentioned TreeLDR.

I will also ask the Solid community.

[lecoqlibre]

Thomas Francart recommends to follow the SEMIC rules. The Semantic Interoperability Centre Europe (SEMIC.EU) is using UML to generate all semantic artifacts (ontology, shapes...) : https://semiceu.github.io/style-guide/1.0.0/arhitectural-clarifications.html#sec:transformation.

One of my INRIA colleague is currently in seminar at Dagstuhl. They are also working with UML to generate semantic artifacts (with Acceleo).

So UML might be the way to do it... We would have one UML model which generates our ontology, shapes and code....

ping @RaggedStaff @simonLouvet

[RaggedStaff]

This seems like the way to go for me. I haven't had time to look in detail, but I will before next Monday's Tech Call. P
ing @RachL - can I add this to the agenda ?

[RachL]

@RaggedStaff @lecoqlibre @simonLouvet from our last tech meeting, here is an issue to list and estimate the work needed datafoodconsortium/data-model-uml#15

Please feel free to transfer it to another repo, I was not sure this was the best place.

One thing is unclear to me: can Maxime invoice the time he will spend doing this list and estimate? And if so,on which budget 🙈

[RaggedStaff]

Thanks @RachL

Current FDC funding doesn't cover v2 improvements - we will definitely be including it in future funding requests though.

I'm thinking that, at the moment, the only pot we have for all the v2 work we're discussing is the general DFC maintenance/improvement budget, unless there's specific FR funding to cover this piece of work ?

I don't think we quite got to an agreement on how that would work in our last governance call, but it would be good to get it pinned down before our next call - lets follow up on slack.

[lecoqlibre]

At the TPAC 2023 there has been a session about the subject w3c/tpac2023-breakouts#8.

This discussion led to a breakout day https://www.w3.org/2024/03/breakouts-day-2024/#b-fb7b6d9f-fc2f-456f-9fff-3a516f3ec7ab.

There is a tool comparison here https://github.com/w3c/wot-thing-description/blob/egekorkan-patch-3/toolchain/tool-analysis.md.