Domain modelling with Mangle

[charlie2clarke]

Hey there, I've read all the documentation and examples on this repo, however I was unable to answer if Mangle could fulfil my use case, could you please clarify this for me?

I appreciate that this project is still a WIP, but on the README it says Mangle "can be used to model domain knowledge". I am looking for a means to create a domain model and query its metadata (amongst other things). I notice many approaches to do so (e.g. OWL) have had attention in the research domain but not so much in commercial applications, in addition they don't have the best tooling, and lots are quite old. Hence, when I was reading Mangle's documentation it seemed to suggest that it could be what I am looking for.

Would it be possible to get some clarification on Mangle's use for domain modelling and how this could be reasoned with, perhaps with an example (for dummies)?

[kamahen]

There is Prolog support for OWL and RDF, for example: https://www.swi-prolog.org/web/

• https://swi-prolog.discourse.group/t/owl2-infrastructure-thea/1062
  (There are a few Discourse discussions - you can search for "OWL" and "RDF")

I don't know whether it's feasible to translate any of this to Datalog (Mangle). And I've never used OWL or RDF.
(Disclaimer: I've not used RDF or OWL ... when I've done data modelling, ordinary Prolog was sufficient; it's quite possible that ordinary Datalog/Mangle would also be sufficient)

Pointers to resources for OWL, RDF, and other knowledge representation systems: http://www.jfsowa.com/ikl/
(I found this, plus other stuff, by searching for [john sowa owl rdf])

[charlie2clarke]

Thanks for your reply and for providing some useful resources.

I'm not sure if one of use have misinterpreted one another, but I am not looking to literally translate an OWL ontology to Mangle. Instead, I'm wondering whether Mangle could be a suitable alternative to model domain concepts.

[burakemir]

I will try a concise answer. People may have different ideas of what constitutes a model, but I won't go into that. Pragmatically, a model is something that represents aspects of reality, for a particular purpose, that is valid for some slice of time (cf. Stachowiak "Allgemeine Modelltheorie").

In the context of software, a domain model is some representation of the "business" concepts - the things users perceive as important and how they are related to other things. Entity relationship diagrams, UML class diagrams and even wire formats and class definitions serve the purpose of domain model, even boxes and wires diagrams on a whiteboard.

Sometimes, it is useful or necessary to define a formal (machine-readable) domain model. In knowledge representation (which may have other purposes than building sotware) a domain model is a set of formal definitions that captures the concepts of some domain of knowledge. These definitions are called ontology. So ontologies as a more formal, logic-based approach for domain models which also implies that it is machine-readable.

A language for expression an ontology is always based on some formal logic. The logical language is what enables precise specification by means of statements and formulas. There are many kinds of formal logic: they differ by the kind of statements that are possible. The "standard" first-order logic would be attractive however it is very expressive which means that many operations that one would like to do on ontologies are undecidable. Research has led to more restricted logics like description logics (DL). These talk strictly about (formal) "concepts" and "roles" and one usually aims at preserving decidability at the cost of expressivity. Importantly, the roles are always binary relations and there are many variations of DL.

Datalog is a language based on first-order logic, however with the important difference that it deals with syntactic objects (facts). The "assertions" of description logic which relate instances to classes, e.g. "milka is the name of a cow" and that "grass is some kind of food" can be easily expressed by unary predicates:

cow(/milka).
food(/grass).

The relations can be expressed as logical formulas.

# Every cow eats grass.
eats(X, /grass) :- cow(X).

We may want to create more general concepts, so we don't need to repeat ourselves:

lion(/simba).
carnivore(X) :- lion(X).
# All carnivores eat meat.
eats(X, /meat) :- carnivore(X).

These simple definitions are not different from class diagrams (the "is_a" relationship). It is easy to see that it is easy to express binary relationships.

However, with plain Datalog, there are some limitations. In order to express more advanced relationships, extensions are necessary. These extensions look like constraints about facts. For example, there are equality-generating constraints and tuple-generating constraints. These integrity constraints are also very useful as a database schema. We'd eventually want some of the operations on ontology definitions implemented in Mangle, by ways of these constraints.

[charlie2clarke]

Thank you so much for your detailed response, I really appreciate it. I would also like to apolgise for my naiveness; this is the first time I am looking to create/use a formal domain model definition.

In the process of looking for a method of doing so, it strikes me as odd that there is no common approach to doing so (that isn't dated, has good tooling, and is used commercially).

Am I right in saying that you intend to replicate some of the expressiveness you are able to define when using ontologies in Mangle?

[burakemir]

I obviously agree that domain modeling (and requirements in general) does not get the attention it deserves! There was a time when people talked about "Object-oriented analysis and design" and an underestimated advantage of the OO paradigm is that it enabled a straightforward approach to modeling.

One factor that makes ontology difficult is probably also that formal logic may not be very accessible. For practical purposes, people turn to visual representations, diagrams and leave the "details" to be figured out by software engineers (which introduces a risk of misunderstanding); people rely on prose (requirements captured as text) which may fail to capture how users think about their domain. The different perspectives of user gropus and their implicit contextual knowledge is frequently underestimated in software projects; users may use the same word with different meanings.

Certainly a goal of Mangle is to make logic, datalog and domain modeling accessible and practically useful, and also combine it with achievements that are meanwhile standards like structured data types, static checking and inference established by decades of programming language research.

That said, I do believe there is an ecosystem around OWL and RDF that has users and tools. My interest is more in leveraging the captured knowledge for static checking and possibly multi-stage programming and optimization (but I would also like to see the graphical tooling that lets us manage more general ontologies).

[rkrishnasanka]

There was a extension of my Ph.D. project that I wanted to use static checking of the datamodel, etc. But if Mangle's objectives are static checking and multi-stage programming and optimization, I think I'd definitely like to contribute. I however need to spec out that extension project more thoroughly and figure out some milestones. Do you have a roadmap for development ? I'd love to be able to contribute.

[menzeliano]

It's also worth mentioning that there exists a direct mapping between already established languages used to express domain models like ORM (Object-Role Modeling check out http://ORM.net) which is more expressive than say ER or UML and datalog+/- languages.
Reference: https://www.semanticscholar.org/paper/Mapping-ORM-to-Datalog%3A-An-Overview-Halpin-Curland/4a1eff1cd53a67bb3cf111445ca1f9c21c9e1140

[kamahen]

@rkrishnasanka - are you suggesting using Mangle for static type checking? If so, I have some thoughts, based on my experiences with using Prolog with constraints for type-checking of Python (it's trickier than I had anticipated, and I ended up using some quite different techniques).