I built an ontology in protege which has the following axioms:
Platform hasLocation SpatialThing
Sensor hasLocation Spatialthing
Lets say a platform and a sensor have the same location.
Then the reasoner infers that the sensor is also of type Platform, and the platform is also of type sensor which is wrong. How do I change that?
That happens with all the reasoners available.
Visually:
hasLocation domain: Platform, Sensor
hasLocation range: SpatialThing
<SensorInstance> owl:Class Sensor
<SensorInstance> hasLocation <SpatialThingInstance>
Reasoner infers:
<SensorInstance> owl:Class Platform
You are asserting that the domain of hasLocation is the intersection of Platform and Sensor. This implies that anything for which hasLocation has a value belongs to both of these classes.
If you are trying to say that Platform and Sensor are part of the domain, but are disjoint, you need to define the domain as the union of these two classes (or, depending on what the domain actually is in your setup, that the domain class is a superclass of Platform and Sensor.
Related
Martin Fowler gives a great example of describing the bounded context concept by the polyseme 'Meter' in the electric utility domain (https://martinfowler.com/bliki/BoundedContext.html) . Depending on the context, 'Meter' at least 3 meanings, which may result in 3 bounded contexts (BCs):
connection between the grid and a location -> lets call the corresponding BC 'geo';
connection between the grid and a customer -> lets call that BC 'customersupport';
the physical meter itself -> lets call that BC 'assetmanagement';
Lets say we want to design Open-Host services for exposing meter information for each bounded contexts: so a public API for meter in geo BC, a second one in customersupport BC and a third one in the assetmanagment BC.
In the electric utility domain we have a Common Information Model - CIM - (https://www.entsoe.eu/digital/common-information-model/) - which is the electric utility industry standard for data exchange, describing both syntax and semantics. For instance it has for entity 'Meter' a 'canonical' model, describing Meter with a global set of attributes that is bounded context independend so to say.
Should the public APIs we intend to design make use of the CIM model as the source model for the published language by selecting the right attributes from the canonical 'Meter' model? We can take the CIM 'Meter' model, select a subset of the relevant attributes according to the bounded contexts and publish the API in json or xml, based on the CIM model and decoupled from the BC application model.
Would this be a way to design Open-Host services for the Meter polyseme Martin Fowler is referring to?
Sure, you can have a grand unified model which encompasses a number of bounded contexts. Those contexts can effectively ignore the aspects of the unified model which don't really concern them (and even add their own attributes if it makes sense for their purposes).
It might get tricky if there's some aspect of the unified model which multiple bounded contexts are going to want to process updates for, but that can be worked around in various ways.
Would this be a way to design Open-Host services for the Meter polyseme Martin Fowler is referring to?
Open Host Service is a pattern involved in bounded context cooperation. The idea is to provide a stable API for your service, hiding implementation changes from clients to protect them. For instance, you could split your persistence into 2 databases and still expose a single unified interface. Using the CIM model for your service is a good way to ensure a stable API to your clients, using an open standard. However this has nothing to do with polysemes.
Polyseme is a concept where the same object can have different properties and meaning depending on the bounded context considered. For instance, in an ecommerce application, a product can have:
a color and size in the customization BC
a unit price and discount in sales BC
a count and size in storage BC
Size in customization and storage BC could have different meanings. Polysemes do not imply cooperation between these contexts, but is rather about splitting your model into distinct bounded contexts, so different business areas stop interfering with each other. This has to do with application architecture regarding RDBMS as write performance bottlenecks in monolithic applications. Why have your database read-lock your product price and discount information when the storage team update the count from their latest inventory ?
Quoting Martin Fowler:
In those younger days we were advised to build a unified model of the entire business, but DDD recognizes that we've learned that "total unification of the domain model for a large system will not be feasible or cost-effective". So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model - essentially a way of structuring MultipleCanonicalModels.
Here, he is explicitly referring to stuff like the CIM model when is writes about a unified model of the entire business. Basically, what is saying is that you should not use the whole CIM model for your contexts.
Should the public APIs we intend to design make use of the CIM model as the source model for the published language by selecting the right attributes from the canonical 'Meter' model? We can take the CIM 'Meter' model, select a subset of the relevant attributes according to the bounded contexts and publish the API in json or xml, based on the CIM model and decoupled from the BC application model.
The CIM model is designed for data exchange in this domain. It sounds like a good starting point for your Ubiquitous Language. However, if you don't need your overall system to comply with the CIM model standard, you should definitely split that into smaller bounded contexts.
I have read about meta-modeling (including M0,M1,M2,M3)
I understood the goal of M0 (runtime execution), but I don't understand the meaning of M1,M2, can someone give a good example to where and how to define a profile? and what is the meaning of the tagged values in a profile?
They are abstraction levels. The higher the number the more abstract the definition. The M3 level describes a framework in which you build your system. This framework is called profile. Imagine a car factory. They build cars. So in the profile you define such a car with what it would need. Then you can create a car class in a concrete model and it is distinct in certain respects (e.g. it must have 4 wheels, a motor etc.). Or take requirements: A requirement can simply be a piece of text. But in your modeling environment you might require them to have a distinction functional/non-functional, a source, a priority, whatever. So you define those as attributes in the meta-model and when you use the so defined Requirement stereotype the concrete class will have tagged values with the name of the attributes.
I need a tool (preferably online, but at that stage I don't care anymore) which allows me to modelize relationships (similar to BPMN) which can be represented as compound graphs (though most of the times, it will be a simpler nested graph). I can't seem to achieve my goal using BPMN formalism (swimlanes are the closest but they do not allow arbitrary nesting). I am thinking to reuse UML modelization tools but I don't know enough about UML to know if UML covers my use case.
Imagine an integrated circuit which is made of chips connected with wires. So three chips : A,B,C and Chip A -> Chip B, Chip C. Each chip has input ports and output ports, and some of the output ports of A are connected to the input ports of B, some are connected to those of C. Now Chip A itself can be considered as an integrated circuit, and as such can be decomposed in another graph : Chip A :: Chip A.1, Chip A.3 -> Chip A.2. Each Chip A.1 can also be decomposed etc. This is what is called a compound graph. Each node of a compound graph can have children which are themselves graphs.
I do know about the Harel's and UML's statecharts formalism, which allows for hierarchical graphs to describe hierarchical nested state machines (hence any nested graph can potentially be expressed with statechart formalism), though I do not know any online tool which allow to draw statechart. The question is whether UML has a mechanism or tools which allow to specify a compound graph, and if so, what is the nesting mechanism?
Level 1
-------
---|ChipA|---ChipB---
| |---ChipC---
|-----|
Zoom on Chip A
-----ChipA.1---ChipA.2---- (...linked to ChipB input port
|--ChipA.3-| |-- (...linked to ChipC input port
An example of compound graph from the litterature :
In response to your comment,
The question is whether UML has a mechanism or tools which allow to specify a compound graph, and if so, what is the nesting mechanism?
At the infrastructure level, it uses the Element::ownedElement association to represent containment. The Namespace::ownedMember associate subsets this association, as do the association between classes and their members, packages and nested packages, components and their contained items, and so on. All of these are conceptually compound graphs, but are not rendered in a similar way to you diagrams.
In terms of you 'Chip made up of chips', the CompositeStructures package in the UML superstructure ( section 9 of the 2.4.1 superstructure ) uses these association to create composites, or for a domain specific example built on top of UML then SysML is the UML dialect created for systems engineering.
A systems engineering block diagram consists of blocks created with ports and connectors; blocks can have internal structure of further network of blocks. The connectors carry flows, whic can be information, energy or matter.
An example block diagram for some plant shows the custom rendering used to show owned elements in the same diagram as their containers:
See http://www.omgsysml.org/ or http://sysmlforum.com/sysml-faq/ for further information.
Tools for sysml are listed on the http://sysml.tools/ site.
Start with the component diagram in UML.
Your chips can be treated as components, ports will be... well, ports ;-) but also you should define some sort of interfaces (functions offered/needed by those ports). As I understand it the arrow direction depicts some sort of dependency (so the chip at the end with arrowhead provides something and thus will have a provided interface while the other end will have a required interface and a proper connection between them).
If a specific port is realised with internal structure you'll use a delegation connector for that.
Is this UML consistent with the text below?
Instead of trying to either define many subclasses or introduce
multiple inheritance, we can instead define a set of roles that the
device is meant to play. (It should be noted that this is another
reason why the concept of a managed device is a good one – now, we can
define a base concept of a managed device, and model its functionality
by associating one or more roles to it as appropriate). This solves
the mess of having the same generic function (such as routing)
assigned to two different types of devices that implement that same
generic function in different ways, producing different subsets of
functionality.
I believe that the UML specifies that each Device can have 0 or 1 DeviceRoles. A colleague asserts that the UML specifies that each DeviceRole can belong to a maximum of one Device. In either case, the UML seems to not reflect that a Device can aggregate a set of roles.
The UML and text is extracted from TMForum's Information Framework (SID):
Physical Resource Business Entities
Information Framework Suite
GB922 Physical Resource
Release 15.0.1
November 2015
Thanks, Greg
The UML diagram is consistent with the text. It clearly says that the device aggregates zero or more device roles and a device role can be played by zero or one device. In UML, multiplicity is notated adjacent to the type it quantifies.
It would help if the property names were written at the ends of the associations.
I have worked on this document and created a data model from it. In real world experience a resource, for example a physical resource like a mikrotik router can have roles of a router and firewall at the same time. So the model has to let you fulfill the need of several roles for a single resource.
I hope this example will clarify the subject.
Considering the following block diagram:
I would like to model a continuous flow from PressureSensor.pressure to LPF.input.
Is it compliant to the SysML 1.4 specification to model this flow without using ports like in the following diagram?
Or do I have to use ports like in the following diagram?
From the SysML spec (1.3):
The main motivation for specifying ports and flows is to enable design
of modular, reusable blocks with clearly defined ways of connecting
and interacting with their context of use.
In other words: you can of course use direct connectors, but you will loose the ability to specify more details about what is going on along those connectors.
There is a difference between a non-abstract block and a port typed with an interface. A non-abstract block cannot be substituted. In contrast, something with a matching interface is easily substituted.
Think about two analogies:
One brand of HDTV will only work with one brand of cable TV box. If you want to use another brand of HDTV, you would have to emulate the original brand of HDTV completely because of some undocumented inter-dependency.
Any brand of HDTV that has an HDMI interface will work with any brand of cable TV box that has an HDMI interface.
Which situation would you rather have in your living room?