I tried to use the same object property between multiple classes, but I got a warning that the same object property has been set multiple times as follows, can you please let me know what is wrong with that and how to solve it? Does this restrict reasoning later on (i.e. confuse the reasoner since the same object property is set multiple times)?
Thanks
Contrary to the comments it actually is very problematic to use the same object property between multiple classes.
What you don't see in your visualization is that in RDF/OWL, the starting point of your relation arrows is modelled as rdfs:domain and the target point of the arrows is modelled as rdfs:range.
The semantic of an OWL class is that it is a set of individuals and rdfs:domain and rdfs:range specify the domain, respectively range of a relation. That is, they specify the sets of allowed values in subject, respectively object position of a triple with that relation in the predicate position.
If you express your example in RDF Turtle it would look like this:
:hasPart rdfs:domain :ClassA, :ClassB;
rdfs:range :ClassB, :ClassC, :ClassD.
This causes multiple problems:
Intersection
The semantic of multiple domains, respectively ranges, is the intersection of those classes, not the union!
Even if we disregard the relation between :ClassB and :ClassD, this means :hasPart is only allowed by individuals that are instances of class C and class D at the same time!
For example, lets say class A is "car", class B is "tire" and class C is "motor". Now you want to say that a car can have tires and motors but what you actually specify is that a car can only have things that are a motor and a tire at the same time!
Unwanted but allowed usage
If you fix the first problem but specifying the union instead of the intersection, it will be very messy in serialized RDF because you need a large amount of triples to represent OWL restrictions such as unions. But even if you do that, you could now connect an instance of class A with an instance of class D, which is not allowed in the image.
Solution
The solution is simple, just separate those relations, for example into :hasB, :hasC and :hasD, although in a real scenario you can probably find a more suitable naming scheme, where the "has" prefix is often not used. For example, in DBpedia, the property for the country of a city is expressed using dbo:country, not dbo:hasCountry.
Related
I am reading Autosar document and in one of the document (Autosar_TemplateModelingGuideline.pdf), it says that:
Composite aggregation, forming a whole-part relationship
Regular association, expressing a reference from the associating to
the associated model element
My question is: what is the difference between these two in practice? How do I have to interpret them in a class diagram, e.g. the Com Module in Autosar.:
The AUTOSAR COM module’s Configuration Overview
Consider Specified class ComGwSignalRef surrounded with a red rectangle. This class has a composition relation with ComGwSignalRef class and two regular association with ComGroupSignal and ComSignal.
How would you interpret this as a developer and how do you implement in C?
if regular association is a reference to an object that has independent life from ComGwSignalRef why designer do not use instanceRef here?
if it is not a reference, why did the designer not use composition?
PS. There is a concept in Autosar "InstanceRef" which is used for reference for independent object with independent lifecycle.
Maybe you should also consider the following:
The Com Configuration is an instance of the EcuC configuration meta-model as defined in the AUTOSAR_TPS_EcuConfiguration.
The ComGwSignalRef is of type EcucChoiceContainerDef, and as such, the two destination associations of ComSignal and ComGroupSignal have a meaning. Only one of these "choices" can be selected in the final configuration as a reference. In AUTOSAR metamodel, that is the definition of how EcucChoiceContainerDef works, in UML you might need here an additional constraint element to define the XOR relation of two associations.
An object can only be composed as part of one object.
A <>- C -<>B
In the diagram above C is composed in A and B. This would lead to the following instances:
a: A <>- c: C -<> b:B
Now the specific instance c is now part of both a and b.
What happen would with c if b goes out of scope? By the semantics it should be destroyed and not be destroyed (a still exists).
Or more pointed:
Take Alice,Bob, and Collar Bone as examples. Alice’s collar bone cannot be part of Bob.
UML is a modeling language and has not the same expressiveness as, say a C compiler. This is by design to simplify things.
Remember: All models are wrong, but some are useful. — George E. P. Box
In OWL, is there a way to state that an individual of a particular class must be related to another individual via a specific object property?
For example, I would like to state that:
forall(x) Object(x) -> exists(y) Shape(y) ^ hasShape(x, y)
i.e., "For all objects, there exists a shape that is the shape of the object."
so that if there is an individual of the type Object that has no shape associated with it, a reasoner would find it to be inconsistent.
I tried an axiom:
Object SubClassOf hasShape min 1 Shape
but it's not working.
It seems like the issue is because Object Property in OWL has no identity, but is there a workaround for this issue?
(I'm using Protege 5.2.0)
You are correct that the meaning of Object SubClassOf hasShape min 1 Shape is that every individual of Object is associated with an individual of Shape via the hasShape property.
So if you create an individual x of type Object without x being associated with an individual of Shape, why does the reasoner not determine that your ontology is inconsistent? The reason for this is due to the open world assumption. Informally it means that the only inferences that the reasoner can make from an ontology is based on explicit information stated in the ontology or what can derived from explicit stated information.
When you state x is an Object, there is no explicit information in the ontology that states that x is not associated with an individual of Shape via the hasShape property. To make explicit that x is not is such a relation, you have to define x as follows:
Individual: x
Types:
Object,
hasShape max 0 owl:Thing
Btw, this problem has nothing to do with identity as you stated.
One solution I found was to make the ontology "closed world", by making owl:Thing equivalent to the set of all individuals defined so far.
On Protege 5, we can make an assertion on a individual by two different ways.
individual1 type property1 value individual2
individual1 property1 individual2
I don't know what's the difference of them.
Plus, is there a way to put some restrictions on individuals in terms of cardinality? Based on Open World Assumption, It would be interpreted that the individual1 may have other relations. I want to make the individual1 only have one kind of property, ie. property1.
This question is about Ontologies , I am implementing an ontology about potential physical attacks on wireless sensors as devices.
I created class Modification_Attack meaning attacks which modify in the sensor itself. I created Programming_Modification as an instance of this class, is this logical, is it better a sub-class or neither an instance nor a sub-class?
What is the main difference between instances and sub-classes?
This question isn't really unique to OWL ontologies; it comes up in object-oriented programming, and in set theory in mathematics. A class is a collection of its members. E.g.,
Person ≡ { person1, person2, … }
Suppose you have another class:
TallPerson ≡ { person63, person102, … }
A class A is a subclass of the class B if every element of A is also an element of B:
(A ⊆ B) ≡ (x ∈ A → x ∈ B)
So, for instance, if every member of TallPerson is also a member of Person, then TallPerson is a subclass of Person.
I created class Modification_Attack meaning attacks which modify in
the sensor itself.I created Programming_Modification as an instance of
this class , is this logical , is it better a sub-class or neither an
instance nor a sub-class?
This is a choice that you need to make. It really depends on the context and how you intend to use the ontology. If you're observing attacks in the wild and trying to categorize them, you probably want a subclass, but you'll want to have instances of Programming_Modification. That is, you'll want something like:
Programming_Modification ≡ { attack24, attack89, … }
But if you've got some other kind of use case, where you you want to talk about Programming_Modification as a single entity, then it might make more sense for it to be an individual.
I have been thinking through the same issue. And I think the same thing can be both an instance and a subclass depending on whether you plan to use it conceptually or not, which can be simplified to whether you would describe it using the or a.
For example, I am working on a materials ontology, where the main class is Material. A particular type of material is Steel. If I say the steel then steel an instance of Material. If I say a steel then Steel is a subclass of Material. Further, steel is an instance of Steel. And it would be more appropriate to also give it some kind of meaningful identifier like steel-1.
It all seems to come down whether you are using a term as a conceptual class or as a name for some instance of that class. In your case, I think it would probably be more appropriate to say Programming_Modification is a subclass as you could probably have many of such modifications which you would refer to as the first Programming_Modification or the second Programming_Modification . Would love to see what you came up with though if you have a solution.
I have a SportsCentre class which contains an array of Employee objects.
Which is the right way to show that an attribute's data type is an array of objects?
I have found two different versions online:
the first one uses the ArrayList<> keyword:
SportsCentre
- listOfRegistered : ArrayList<Employee>
getRegisteredList() : ArrayList<Employee>
the second one uses square brackets []:
SportsCentre
- listOfRegistered : Employee[0..*]
getRegisteredList() : Employee[0..*]
Both are correct, but the second one, when multiplicity is set to more than one, is used more naturally, and it is not necessary to define the collection class as it is shown in the first picture of your example.
Simply said, multiplicity defines how many instances of a specific type can be stored by attribute. This set of instances can be ordered, or duplicates in it may be allowed. Parameters of multiplicity elements have an impact on the type of collection which should be used, Set, Vector, Array, etc.
But, if you need precise info about this issue, read UML Superstructure. Search for Property and Multiplicity Element. here is the UML website