I want to create an ontology describing a process with Protégé. I have a concept "process" connected with 5 other concepts (process tasks) by the relationship "is_composed_of". How to express this in Protégé. Do I create an ObjectProperties and I specify the domain and range in this case I will have 5 relationship "is_composed_of".
Is each instance of Process must be related to 5 instances of ProcessTask by the object property isComposedOf, then you'd use an axiom like:
Process ⊑ = 5 isComposedOf.ProcessTask
In the Manchester syntax, which is what you'd use in Protege, you'd go the Process class and add the following as a superclass:
isComposedOf exactly 5 ProcessTask
For more about quantified cardinality restrictions, see Meaning of OWL exact cardinality restrictions. Defining cardinality of data property in OWL include another example.
Related
I have following structure
One organization can have many environments.
One environment can have many Applications.
One application can have many Policis.
I created class of each entities i.e.
class Organization,
class Environment,
class Application,
class Policy
Now I want to apply policies to Application.
One policy should have one Policy class object. All instances of Policy are different. Every policy have unique name and ID.
Inheritance will not work, Consider following hierarchy -
Organization
Environment(Organization)
API(Environment)
Policy(API)
because every policy, required to procide all details of API, Environment, Organization.
Can we do aggregation here? Need help on this
All instances of Policy are different.
Every policy have unique name and ID
You can indicate that with the constraint :
Policy.allInstances() -> forAll(p1, p2 |
p1 <> p2 implies (p1.name <> p2.name and p1.ID <> p2.ID))
A class diagram from the information you give can be :
I do not use bidirectional relations supposing Policy does not know the associated Application(s) whose does not know associated Environment(s) whose does not know associated Organization(s).
I use multiplicities * equivalent to 0..* because nothing in your question says the minimum multiplicity is 1 each time. I do not indicate the multiplicity in the opposite direction of the relations because your question does not indicate something about them.
Inheritance will not work
A inherits B implies A is a B, among the classes your give none of them satisfy that, so there is no possible inheritance between them.
Can we do aggregation here
may be between Environment and Application because we can say an environment is composed by applications, but else where no.
I could not find this question already on SO, but I might have overlooked. My apologies if that is the case.
I'm trying to understand how to limit the cardinality of an object property using OWL.
I'm not sure this fully/correctly describes what I'm trying to accomplish, so here's an example:
Consider the hasWife and hasParent properties described in OWL 2 Web Ontology Language
Primer (Second Edition).
How do I state that any individual can only have 0 or 1 hasWife relationship, and must have exactly 2 hasParent relationships?
Extra points if you can tell me how to do this using WebProtégé.
I'm trying to figure out if Jena (or any other SPARQL Update server) will enforce ontological constraints. For example, I want to enforce that only entities which have type x are allowed to have property y and the value of the property must have type z. I think this is what OWL can provide, but I'm not sure. Also, specifically, will Jena ensure that if I try to write a SPARQL Update query which does not follow these rules, that update will fail to insert and an error will be returned?
For example, I want to enforce that only entities which have type x are allowed to have property y and the value of the property must have type z. I think this is what OWL can provide, but I'm not sure.
What you're asking for is not what OWL provides. In OWL, you can say that:
propertyY rdfs:domain typeX
propertyY rdfs:domain typeZ
but this does not mean (at least, in the way that you're expecting), that only things of type X can have values for propertyY, and that the values must be of type Z. What it means is that whenever you see an assertion that uses propertyY, like
a propertyY b
an OWL reasoner can infer that
a rdf:type typeX
b rdf:type typeZ
The only time those inferences will be any kind of "constraint violation" is if you have some other way of inferring that a cannot be of type X, or that b cannot be of type Z. Then an OWL reasoner would recognize the inconsistency.
I'm trying to figure out if Jena (or any other SPARQL Update server) will enforce ontological constraints. … Also, specifically, will Jena ensure that if I try to write a SPARQL Update query which does not follow these rules, that update will fail to insert and an error will be returned?
I don't know whether Jena supports something like this out of the box, but you probably could probably either:
Use an OntModel with a reasoner attached, and run your SPARQL updates against that graph. Then, you can query the graph and see whether any inconsistency is found. How this would be done would depend on how the reasoner signals inconsistencies. This might not all that hard, but remember that Jena is really RDF-based and for full OWL reasoning, you'll need another reasoner that integrates with Jena (e.g., Pellet, but there are others, too, I think).
Alternatively, you might use a store that has reasoning built in, and probably has this kind of functionality already. I think that Stardog has some of these features.
What you need to understand about OWL is property restriction:
A property restriction is a special kind of class description. It describes an anonymous class, namely a class of all individuals that satisfy the restriction. OWL distinguishes two kinds of property restrictions: value constraints and cardinality constraints.
A value constraint puts constraints on the range of the property when applied to this particular class description.
A cardinality constraint puts constraints on the number of values a property can take, in the context of this particular class description.
Based on the description of your problem, you need to use a value constraint. These value constraints exists: some (someValuesFrom), only (allValuesFrom), and exactly (hasValue).
For example:
Class: Woman subClassOf: hasGender only Female
Class: Mother subClassOf: hasChild some Child
Class: Employee subClassOf: hasEmployeeID exaclty 1 ID
So depending on the restrictions on the individuals that you have defined, these individuals can be classified by the reasoner under the right class, which will be their type. The systems generally won't prevent you from entering false information, but the concept will either be declared unsatifiable or inconsistent. In the case of entering an individual that is incompatible with the constants in the ontology, the ontology becomes inconsistent (everything goes wrong) then you can retract the last fact I suppose. I am not sure about Jena, but OWL-API lets you temporarily add a concept to the ontology manager, and then you can check the consistency of the ontology. Normally when this check goes wrong, you can remove the last unsaved change to the ontology manger (via the change listener), and if everything is correct, you can save the changes in the ontology manager.
Subsetted Properties are widely used in UML specification diagrams.
What are the semantics (meaning) of a Subsetted Property?
How does one use a UML Subsetted Property?
A real-world example would be great
Edit:
the following screenshot from UML specification 2.5(Beta)
Could you please let me know what subset means in this diagram?
Short answer
As there are two constraints that might produce problems and they are somewhat related (and they've led me to this question ;-) ) let me describe both of them, i.e. subsets and redefines
To sum up - redefines changes (provides more precise) logic of model for the same relationship but in specialized class while subsets shows relationship between different relationships of the same classes (they might be inherited but don't have to) and shows that objects that are in one relationship create a subset of objects that are in other relationship.
More elaborate answer
redefines
redefines changes in some way a logic of the relationship for a specialization of a class linked to a relationship. E.g. while animal can have any number of limbs (octopus 8 and centipede - who knows...), humans have always 4. So we have a relationship from Human to Limb with target name limb but a changed multiplicity (to 4).
Fig. 1 - Normal Limb - redefines
There might also be a further changes, like we might define a new class JointLimb which specialize Limb. As humans have only JointLimb our relationship will not only change the multiplicity but also allow only a specialized class on both ends of the relationship.
Fig. 2 - Joint Limb - redefines
subsets
On the other hand subsets shows that the objects that are in a one relationship (with subsets constraint) are all at the same time also in some other relationship (the one pointed in subsets constraint) i.e. set of objects in a relationship one is a subset of objects in a relationship two. In our case we will have new classes Hand and Leg specializing class Limb (or JointLimb in the latter example). As each Hand (Leg respectively) is a Limb (JointLimb) the relationship from Human to Hand (Leg) will have multiplicity 2, target name hand (leg) and will be constrained with subsets limb.
Fig. 3 - Normal limb - subsets
Fig. 4 - JointLimb - subsets
While in the previous example we were having a subsetting somewhat related to the inheritance it doesn't necessarily have to be the case. Let's consider class Car and class Wheel. A Car is equipped with Wheels (which is a relationship equippedWheel), some of them (e.g. 4 for passenger car) are mountedWheel while some (1 for passenger car) are spareWheel. Both mountedWheel and spareWheel subset equippedWheel.
Fig. 5 - Car - subsets
I'm sorry, I can't place pictures yet nor put more than 2 links so you have to follow this link to see the examples.
Hope that helps.
According to UML 2.4.1 specification, Subsetted Property references the properties of which this property is constrained to be a subset.
What do you mean by a real-world example ? UML specification is one of them I guess...
But you might find this kind of properties in all applicatioh where an Object is associatded to another and this association is redefined in the context of two of theirs subtypes.
For example, an Animal class can be associated to a Limb class. We can also define two classes Human and Leg extending respectively Animal and Limb. Finally we can associate Human and Leg which will be a redefinition of the preexisting association.
Hoping it helps,
BR
I understand the difference between aggregation and composition but I am struggling a bit with association. My current understanding is that an association exists between classes when ‘they use each other’, for example, one object is passed to the other during a method call. See also:
http://www.codeproject.com/Articles/330447/Understanding-Association-Aggregation-and-Composit
Both objects exist independently and, in contrast to aggregation, no object is a container class of the other. Does this mean that both objects MUST have a copy of the other(s) (e.g. 1:m relationship) or how else is the association ‘stored’. Any feedback would be very much appreciated.
From the UML Superstructure 2.4.1:
An association declares that there can be links between instances of the associated types. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end. (UML Superstructure, Page 37)
Nothing more, nothing less. and very vague. Because of this, it is also very hard to understand. What I defined (In a course I teach) is a hierarchy of links from dependency to composition where:
Dependency from A to B means that A uses B but indirectly (say by receiving instances of it and forwarding them to other objects).
Association from A to B means that A uses B directly, (for example by calling methods)
Aggregation from A to B means that B is part of A (semantically) but B can be shared and if A is deleted, B is not deleted. Note that this says nothing about how the "is part" is implemented.
Composition from A to B is like Aggregation, where B cannot be shared and if A is deleted, all of its aggregates (Bs) are deleted also.
Aggregation is an Association relationship where the Association can be considered the containing class 'Owning' the contained class, and the lifetime of that relationship is not defined.
Association is an 'Has-A' relationship.
Example:-
public class Person
{
private final Name name;
private Address currentAddress;
//...
}
In this case, the Person Has-A name and Has-A Address, so there is an Association between Person and Name, and Person and Address.
An association describes a relationship between instances of one or more classes. In the words of the UML Reference Manual, "Associations are the glue that holds together a system."
Aggregation is a form of association in which there is a "whole-part" relationship. You may say that if a class Airplane has a class Engine then this forms a "whole-part" relationship.
Aggregation
Let's set the terms. The Aggregation is a metaterm in the UML standard, and means BOTH composition and shared aggregation, simply named shared. Too often it is named incorrectly "aggregation". It is BAD, for composition is an aggregation, too. As I understand, you meant you understand "shared aggregation and composition".
From UML standard:
Precise semantics of shared aggregation varies by application area and
modeler.
I haven't found a word about that aggregation supposed multiplicity, for example.
Association.
A definition from UML 3.4.1 standard:
An association describes a set of tuples whose values refer to typed
instances. An instance of an association is called a link. A link is a
tuple with one value for each end of the association, where each value
is an instance of the type of the end.
Aggregated relationship is a subclass of Association.
Association is based on relationship. IT is the glue for models.
But your feelings didn't lie - as the shared aggregation is not strictly defined, there is also NO any strictly defined boundary between Association and Aggregated association. Authors of tools and modellers have to set it themselves.
Association
It represents a relationship between two or more objects where all objects have their own lifecycle and there is no owner. The name of an association specifies the nature of relationship between objects. This is represented by a solid line.
Let’s take an example of relationship between Teacher and Student. Multiple students can associate with a single teacher and a single student can associate with multiple teachers. But there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.
Aggregation
It is a specialized form of Association where all object have their own lifecycle but there is ownership. This represents “whole-part or a-part-of” relationship. This is represented by a hollow diamond followed by a line.
Let’s take an example of relationship between Department and Teacher. A Teacher may belongs to multiple departments. Hence Teacher is a part of multiple departments. But if we delete a Department, Teacher Object will not destroy.
It depends on the context.
Association: A man drives a car, focus on the caller and callee relationship.
Aggregation: A man has a car, focus on the owner and member relationship.
Composition: A man has a mouth, focus on the owner & member but the owner consists of members, it means that they shared the same life cycle.
Feels like I'm speaking Chinglish.
Association
Association is a relationship where all objects have their own life-cycle and there is no owner. Let’s take the example of Teacher and Student. Multiple students can associate with a single teacher and a single student can associate with multiple teachers but there is no ownership between the objects and both have their own life-cycle. Both can create and delete independently.
Aggregation
the objects in Aggregation have their own life-cycle but there is ownership. Child object can not belong to another parent object. Let’s take an example of Department and teacher. A single teacher can not belongs to multiple departments, but if we delete the department teacher object will not destroy. We can think about the “has-a” relationship.
Composition
It is a strong type of Aggregation. Child object does not have their life-cycle and if parent object deletes all child object will also be deleted. Let’s take again an example of the relationship between House and rooms. House can contain multiple rooms there is no independent life of room and any room can not belongs to two different houses if we delete the house room will automatically delete.
An association between object types classifies relationships between objects of those types. For instance, the association Committee-has-ClubMember-as-chair, which is visualized as a connection line in the class diagram shown below, may classify the relationships FinanceCommittee-has-PeterMiller-as-chair, RecruitmentCommittee-has-SusanSmith-as-chair and AdvisoryCommittee-has-SarahAnderson-as-chair, where the objects PeterMiller, SusanSmith and SarahAnderson are of type ClubMember, and the objects FinanceCommittee, RecruitmentCommittee and AdvisoryCommittee are of type Committee.
See also my alternative CodeProject article.