Candidate Technologies: Can we use RDF/OWL and SHACL ?

[odungern]

• How can RDF/OWL and SHACL aid at defining the CASCaDE metamodel?
• What are the pro's and con's`?

[odungern]

.. thanks for pointing us at the German AI Roadmap, Andreas.

I haven't yet thoroughly read and understood the paper. To what I have seen, it gives examples of how AI can be used in various domains. The needs 05-xx (starting p. 182) are relevant for our goals. In terms of technologies it only talks about RDF, RDFS and OWL.

Andreas: Do you think that we must build on these technologies in order to be aligned with that roadmap?

To what I know as of today, there are other approaches to AI. We must open the door to AI, but we are looking first at collaboration and interoperability: From our persective AI is a collaboration partner in its own right.

To be honest: I am not convinced that RDF/OWL can be the guiding technology. Certainly we must be able to use our data in that format. In my eyes this is perfect for certain reasoning tasks, but it cannot be the base for high-performance transaction processing.

Remembering a discussion with Fabian Neuhaus, as you know one of the authors of DOL, he hinted that OWL can easily lead to unsolvable tasks. When limiting ourselves to OWL-DL, the tasks may be always solvable, but potentially very slow. So his advice was to reduce the solution space as much as we can considering the use-cases and data we need to cover.

Anyways, this is a fundamental issue. Shall we dedicate a "topic of the day"? Or, can we first have a discussion in a smaller group? I must admit I have no practical experience with this technology ... and I want to learn and understand the implications.

[odungern]

.. thanks for pointing us at the German AI Roadmap.

I haven't yet thoroughly read and understood the paper. To what I have seen, it gives examples of how AI can be used in various domains. The needs 05-xx (starting p. 182) are relevant for our goals. In terms of technologies it only talks about RDF, RDFS and OWL.

The reason for this is that in the application contexts of dataspaces and regulations the leading technologies typically come from the Semantic Web Stack, e.g., data catalogs are built using DCAT, which is an OWL-based model, although not using full OWL expressivity (since that is not necessary – but it’s good to know that there are options for extending it). Such “W3C enforcement” is even in place on a regulatory level (à Interoperable Europe Act, which comes with DCAT Application Profiles).

Andreas: Do you think that we must build on these technologies in order to be aligned with that roadmap?

Absolutely yes, at least to that extend that there must be answers on how to be semantically interoperable.

To what I know as of today, there are other approaches to AI. We must open the door to AI, but we are looking first at collaboration and interoperability: From our persective AI is a collaboration partner in its own right.

To be interoperable there needs to be a consideration of the transformations necessary for feeding data to AI. And: the dataspace contexts (Gaia-X, IDSA, etc.) build on W3C even though AI is not the leading use case there. So interchange needs lossless interoperability!

To be honest: I am not convinced that RDF/OWL can be the guiding technology. Certainly we must be able to use our data in that format. In my eyes this is perfect for certain reasoning tasks, but it cannot be the base for high-performance transaction processing.

I think a bit different here: Although I agree that not all representations of RDF/OWL might be most efficient in handling, it’s the logic foundation that opens bridges towards semantic interoperability, traceability and explainability (à e.g., roundtrip interpretation and translation with SysML V2), which is key also to serving legal requirements. In terms of efficiency, of course, there are better approaches, but you can e.g., speed up large-scale RDF querying using binary formats (albeit readonly). Other technologies should be considered regarding their placement and abilities on the logic/semantic spectrum. For instance, if I wanted to have some sort of “best” expressivity and machine-interpretability I might tend to use KIF but the technical infrastructure lacks industrial readiness, although there are/were even ISO standards created on this basis (à Process Specification Language – PSL).

Remembering a discussion with Fabian Neuhaus, as you know one of the authors of DOL, he hinted that OWL can easily lead to unsolvable tasks. When limiting ourselves to OWL-DL, the tasks may be always solvable, but potentially very slow. So his advice was to reduce the solution space as much as we can considering the use-cases and data we need to cover.

Of course, not all OWL features are necessary in all cases. But they offer at least a standardized way of representing and recording knowledge with the option of flexible downstream processing (with or without reasoning) along the semantic spectrum. And, yes, that’s why OWL DL was created in the first place: to offer decidability, and when restricting even more one can sill benefit from that. Still, creating unsolvable tasks can also happen in other cases – one does not need OWL for that, e.g., when using RDF reification or just plain rules.

Anyways, this is a fundamental issue. Shall we dedicate a "topic of the day"? Or, can we first have a discussion in a smaller group? I must admit I have no practical experience with this technology ... and I want to learn and understand the implications.

We can of course start small and extend – I’m open to both approaches if you wish.

[odungern]

Pete: I think we need to separate what we want at the specification level for defining and validating definitions; and formats for interchange (we do care about) from optimal formats for runtime storage and execution (which we don't care about at all, so long as the programming and interchange interfaces are supported)

You can for example implement OWL in a relational database (as does Oracle) and in a very simple key-value store (as does Stardog with RocksDB).

[odungern]

Pete: I think we need to separate what we want at the specification level for defining and validating definitions; and formats for interchange (we do care about) from optimal formats for runtime storage and execution (which we don't care about at all, so long as the programming and interchange interfaces are supported)

You can for example implement OWL in a relational database (as does Oracle) and in a very simple key-value store (as does Stardog with RocksDB).

Yes, Pete, that's a valid point. Thanks!

And yes, RDF is accepted as an exchange format in the internet. In my eyes, the problem arises from the fact, that transformations from and to RDF are not straight-forward from what I keep reading. So I am looking for the sweet spot that allows us to reap the benefits of RDF and have a crystal-clear transformation from and to most well-accepted backend technologies, including the graph-databases following the PG school of thought. Or is this hunting a phantom?

[odungern]

Michael:

Hello Oskar, hello Andreas,

... I also appreciated your contributions and our discussion last night.

You may have noticed that I am much in favor of RDF/OWL. Besides the reasons discussed in the E-Mails this morning, my main reason is that are so many industry-proven parsers, programming frameworks and applications around out there, which would certainly help CASCaDE gain momentum fast and integrate with other approaches seamlessly.

As Pete said standard and implemtations should be considered separately: We have had vendors to “import” our Digital Data Package Ontology as OWL into their proprietary label property graph solutions. But they did not ask me, and I did not tell them how exactly to do that. And I think that´s fine, as long as the OWL ontology, which acts as the interface for collaboration, is subject to the standard.

In any case, this potential conflict of objectives (standardization vs. runtime performance) must be considered carefully in our final selection for CASCaDE.

There is not just a two-peer discussion between RDF/OWL and LPGs. Instead, we need to consider this for ALL solution candidates we are planning to shed a light on during the next weeks.

Thanks again, talk to you later today!

[odungern]

Michael,
.. recently you have mentioned there were numerous libraries and software products to process RDF. I have done some research and found some for Python, Ruby and Javascript. But somehow I get the impression, that these are not widely used and there is no real market for such software: no standards, no comparisons, little experiences, thus no competition.

But probably my search is inept, so can you point me to what you are referring to?

[odungern]

Michael:
Hello Oskar,

I am mainly using the dotNetRDF API in C# to create and interact with RDF ontologies. My RDF XML and TTL derivatives from the DDP information model has been created using this API. The latest version was shared by Uwe Kaufmann in this group and with Elisa Kendall during the Q4 OMG TC meeting.

The API reflects the PIM, and can serialize to PSMs RDF XML and RDF TTL.

As far as I know, there are similar APIs for other programming languages Python, Java – but I am not familiar with these.

For interactive review, visualization and validation, I use Protegé.

I appreciate there is a standardized approach in RDF that allows us to represent nodes and edges at schema and instance levels.

Best Regards,

[odungern]

Andreas:
There are for example:

C#/.Net

• dotNetRDF (which I like to use, and which is IMHO one of the best) – active development
• Trinity RDF (https://github.com/semiodesk/trinity-rdf) – not too active, but usable as long as the standard is being followed
• RDFSharp (lightweight, https://github.com/mdesalvo/RDFSharp) – active development

Java

• Eclipse RDF4j (which is also the basis for many commercial products and projects) – active development
• Apache Jena / Fuseki (which is a main counterpart to the RDF4j ecosystem) – active development
• OWLAPI: Reference implementation for OWL, basis for Protégé and ROBOT, used in biomedical domain (OBO) – active development

C, Python, Perl, PHP, Ruby

• Redland libraries: https://librdf.org/ - not too active, but cross-platform basis used in multiple other bindings
• pySPARQL

R

• RDFlib: https://cran.r-project.org/web/packages/rdflib/index.html - active development
• Redland: https://cran.r-project.org/web/packages/redland/index.html - active development, see note above

Ada

• https://github.com/vporton/redland-bindings/tree/ada2012/ada – not too active, but a start

So there are quite a few options in the open source space.

[rivettp]

RDFlib is also the name of a very active and widely used (22k users) Python library. It has several extensions including pySHACL. See https://github.com/RDFLib/rdflib
BTW I think Python, as the most popular language deserves a subheading to itself!

[odungern]

Here are two approaches to represent a model-element and a requirement related by a 'satisfies' relation:

• according to MOF2RDF: ex-2-mof2rdf
• according to Pete's transformation of SpecIF: ex-2-PR

What do you think - what is better for our purpose? Or yet another approach?

[rivettp]

Note that the MOF2RDF spec (I was a primary author) was not designed as a MDA for generating useable ontologies, but as a complete RDF representation of the original MOF model for management, as opposed to execution, purposes.
That said, there are useful approaches in the MOF Support ontology that could be more generally applicable e.g. for compositions and ordered associations.

There may be a case for making a node/class of the relationship, rather than a single object property as in ex-2-PR, but that depends on the business requirement (WP2).
For example I can see value in having a class Satisfaction with the relationship-related properties for requirement and item, and additional properties covering aspects like:

• completeness (how well is the requirement met?)
• reviewer (which person(s) said the requirement was satisfied?)
• reviewDate (when was the review?)
• evidence (e.g. test results or document)

The point is that RDF has the flexibility to support either approach.
An important question for us is whether we leave the choice of approach to those creating the ontologies (WP2) or we take a stance in WP1 in order to permit common metadata to be managed in the infrastructure. For example we might want a generic class in WP1 called Claim which would be the superclass of WP2 classes such as Satisfaction and supply the generic properties above such as reviewer, evidence etc.
BTW there is a whole Structured Assurance Case Metamodel specification related to Claims in OMG https://www.omg.org/spec/SACM

[rivettp]

An interesting consideration, which would argue for a separate Satisfaction class, is how to handle the case where either the Requirement or the Item "changes" (see separate discussion about what that means). You would not want to delete the Satisfaction/satisfies relationship but mark it as NeedingReview or In Jeopardy .
Another decision point: when doing the re-review you might want to create a new Satisfaction instance or update the original with a new reviewDate and evidence.

[odungern]

That's what I hear when discussing right and left:

• RDF is a "Graph-Assembly-Language". Need a higher-level and more robust representation for higher level tasks.
• RDF is interpreted differently by different tools.
• SparQL is hell. Omit a character and you won't receive a result without warning. Research projects are started to generate SparQL queries so that the desired results are obtained. Again a symptom that RDF is very fine-grained.
• RDF does not support any packaging with public/private visibility like programming languages, MOF/UML or KerML.

Don't know whether all this is true - perhaps resulting from insufficient know-how.

Do you have experience and opinion to share?

[rivettp]

• RDF is a "Graph-Assembly-Language". Need a higher-level and more robust representation for higher level tasks.
  it's a way of representing the data, the ontology will determine the semantics and SHACL the constraints
• RDF is interpreted differently by different tools.
  that's news to me! Importantly the RDF data references its ontologies. Obviously different tools can ignore those ontologies but that's limitations/bugs in the tool not the RDF
• SparQL is hell. Omit a character and you won't receive a result without warning. Research projects are started to generate SparQL queries so that the desired results are obtained. Again a symptom that RDF is very fine-grained.
  SPARQL processors will generally report syntax errors but if you specify bad URIs for properties it won't know whether you're referencing a property it hasn't encountered yet
• RDF does not support any packaging with public/private visibility like programming languages, MOF/UML or KerML.
  Actually MOF declares that all properties are Public. And they need to be if you want to queries and constraints. If you want access control you need to be able to specify rules/policies and user information related to the data. Which RDF allows you to do with a lot of sophistication (e.g. ABAC with inferencing) but rightly does not confuse that with the storage.

[haarer]

Am 26. Februar 2025 21:40:01 MEZ schrieb Pete Rivett ***@***.***>:

Note that the MOF2RDF spec (I was a primary author) was not designed as a MDA for generating useable ontologies, but as a complete RDF representation of the original MOF model for management, as opposed to execution, purposes. That said, there are useful approaches in the MOF Support ontology that could be more generally applicable e.g. for compositions and ordered associations. There may be a case for making a node/class of the relationship, rather than a single object property as in ex-2-PR, but that depends on the business requirement (WP2). For example I can see value in having a class _Satisfaction_ with the relationship-related properties for _requirement_ and _item_, and additional properties covering aspects like: - _completeness_ (how well is the requirement met?) - _reviewer_ (which person(s) said the requirement was satisfied?) - _reviewDate_ (when was the review?) - _evidence_ (e.g. test results or document) The point is that RDF has the flexibility to support either approach. An important question for us is whether we leave the choice of approach to those creating the ontologies (WP2) or we take a stance in WP1 in order to permit common metadata to be managed in the infrastructure. For example we might want a generic class in WP1 called _Claim_ which would be the superclass of WP2 classes such as _Satisfaction_ and supply the generic properties above such as _reviewer_, _evidence_ etc. BTW there is a whole Structured Assurance Case Metamodel specification related to Claims in OMG https://www.omg.org/spec/SACM -- Reply to this email directly or view it on GitHub: #9 (reply in thread) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

Hi Pete, some ideas and thoughts about that: 1. Separation of concerns between "ontology infrastructure" and "ontology". In SAF, we had also this problem. In the practice we worked on both layers while learning about the needs to express facts. The current set of rules and conventions how to model concepts is the result of many iterations and learning. IMO, the infrastructure should be lean, and must be validated by real ontology use. Graph change management should IMO not at all be visible to ontology users. 2. The example about satisfaction: One could Argument that, instead of capturing the information about the reasoning of the satisfaction in the satisfied relation, this should be represented by an other relation "ReasonedBy" between satisfaction and a review object. And all that could be an application of a Claim-evidence pattern. What is your opinion about that? 3.About patterns: In the SAF Specifiation model, we have several use cases to apply a more General pattern to specific ontolgy Elements. An example is the context pattern. We have a General context, having a "Thing in Focus", a "context", and "other Things" This is then e.g. applied to system context at functional Level , at system context at physical Level, and at other places How would you express something like that?

…

-- Gruß, Alexander

[haarer]

Interesting idea, which raised immediately the question in me, wether changes in time should be expressed "inside" "the" graph. I like to think about that in a way that we have one graph that is transformed into another by a "transaction". The transaction groups several "changes" These changes relate the previous. version of one graph to the next. Git has powerful and matured concepts of transactioning. But I understand your idea is about something different, it is not about change control but about evolution of engineering knowledge. E.g. " we learned, that the requirement 34 was barely satisfied in iteration 2 of the work, but in iteration 4 it is OK, certitfied by this review #66.". " and by the way, iteration 2 appeared first in graph version #3635, and iteration 4 appeared in graph version #3679" Having an integrate view both on semantic evolution and change control would be very powerful (and challenging) A feature that most authoring tools don't have, AFAIK.

…

-- Gruß, Alexander