Make every value of one property less than every value of another property? - semantic-web

I just started learning OWL using Protégé 4.3, and now I am facing a difficult problem. I have defined a class A with some restriction superclasses that ensure that each A has a property value from P1 and P2, and each P1 and P2 have a value that is a double:
A ⊑ ∃hasProperty.(P1 ⊓
∃hasValue.xsd:double)
A ⊑ ∃hasProperty.(P2
⊓ ∃hasValue.xsd:double)
How can I assert that P1 values of an A are all less than all the P2 values?

You can't do this with OWL Axioms
This is an interesting problem, but it's one that you can't solve using pure OWL axioms, unfortunately. Generally, it's easy to say something about the values that individuals of class have, by using restriction superclasses, but it's hard or impossible to say something about the relationship between values of properties. E.g., you can't say that the family name property of a person must be the same as the value of the surname property.
It's important to clear up a bit of terminology, first, though, particularly the term restriction in:
I want to define a restriction,for all Individuals of A,value of p1 is
always less than value of p2
A restriction is a class. E.g., the restriction likes some Person is the class of individuals each of which likes some Person. We often use restrictions as superclasses of other classes to ensure that certain constraints hold. E.g., when we say that
Person subClassOf hasName some xsd:string
we're saying that every person has a value for the property hasName that is an xsd:string.
You probably can do this with SWRL
You could assert that if something is a member of A and has p1 and p2 values, then p1 must be less than p2. This would look like:
A(?a) ∧
hasProperty(?a,?p1) ∧ P1(?p1) ∧ hasValue(?p1,?v1) ∧
hasProperty(?a,?p2) ∧ P2(?p2) ∧ hasValue(?p2,?v2)
→
swrlb:lessThan(?v1,?v2)
This will ensure that every P1 value on an A is less than every P2 value on the A. If you ever assert some data that violates this, then there will be an inconsistency.

Related

Smalltalk: Is there something like "is in" or "is contained"?

I'm having trouble with Smalltalk. Is there some operator like "is in" or "is contained / included"?
I have classes Student and Exam (with attribute student) and collections StudentsList and ExamsList. In the ExamsList, I would like to show all instances of class Exam that meet the criteria that their student (object set as value of attribute student) is contained in collection StudentsList.
Something like the following code, but it does not work:
ExamsList list: (Exam allInstances select: [ :ex | (StudentsList includes: ex student) ]).
Could you think of some elegant solution?
Many thanks!
Even though your question lacks some information, there are a few comments that might help.
If your naming convention is consistent and ExamsList is a class, then StudentsList must be a class too. In that case your code doesn't work because classes do not understand the message #includes:, which is intended to be sent to subinstances of Collection.
Assuming my guess is applicable, I would point out that it is not a good idea to have a class for every collection of objects. So, instead of having the class ExamsList, you should add a class variable Exams to the class Exam, initialized to a Set and store there every instance of Exam that you want to preserve for future queries.
In the same way, you should add a class variable Students to the class Student and get rid of StudentsList.
With this design every new instance that matters should be saved in the corresponding collection held by the class (see 6 below for a hint on how to do this). This would eliminate the need for enumerating #allInstances.
In any case, you should understand that #allInstances is a system message, i.e., it is not intended for querying objects in the realm of your model as it belongs in much lower level of abstraction. Note that #allInstances will collect instances that for whatever reason (tests, examples, open debuggers or inspectors, etc.) may still be around without being part of your model.
If every Exam has a Student, you could store an Exam in the Exams collection whenever you assign it to the designated Student, something on the lines of
Exam >> forStudent: aStudent
Exams add: self.
student := aStudent
(student is an ivar of Exam, and self represents the instance with concrete questions)

Class Diagram Multiplicity and Dependency implementation

I am currently learning to create uml diagram, especially class diagram and have some multiple difficulties understanding some concept in the process, here is the question
Does multiplicity always 2 sided? like when i have this classes, PP class is the buyer Class, and Cart is the class to save the buyer order info, i assign 1 - 1 multiplicity because 1 buyer would always have 1 cart vice versa, in Cart it is clearly defined (in my code) that i have a variable with type PP, but inside class PP there is no cart variable at all, so does the multiplicity wrong? should i just assign 1 sided multiplicity in PP and have none in Cart? or does having the variable inside class is not important? i am quite confused on understanding this
About dependency relationship, if i have this PP class which have variable shippingAddress inside the class and using data type ShippingAddress as parameter in some of the function, should i used dependency relationship or association
Thanks a lot
qwerty_so already provided a concise and accurate answer. Nevertheless, I'd like to add some more thoughts to complete the picture.
1
In an association there are always at least 2 sides, and there is a multiplicity on each side: The first diagram says that a PP always has 1 Cart and the Cart always 1 PP. If you meant "sometimes" instead of always, change it to 0..1
There can be more than 2 sides in an n-ary association: Then you'll have n multiplicities.
WHen in a diagram there is no multiplicity indicated on one side, it doesn't mean that there is no multiplicity, but that we don't know what the multipliity is (or that it's not important for what we want to show in the diagram).
Now your question about multiplicity and how to implement it raises another topic:
it is clearly defined (in my code) that i have a variable with type PP, but inside class PP there is no cart variable at all, so does the multiplicity wrong?
It's the question of navigability: If in the implementation of Cart you have a PP variable, this means that you can easily navigate from the a given Cart to the associated PP. If you don't have a Cart variable in the PP implementation, it is difficult to find the corresponding Cart, so it's not navigable. Navigability is shown with an open arrow.
Multiplicity and navigability are two orthogonal concepts.
2
If you have both a dependency and an association, you'd usually show the association. There is no need to also show the dependency, since it is implied by the association. However it's not wrong if you want to show both (but with a dashed line and open arrow) (for example, if you want to add some explanatory comments for each).
Now if in the PP implementation you have a ShippingAddress, it's not only a question of navigability, but it's also a question of ownership of the association end. So you can use the dot notation on the side of the ShippingAddress.
If you don't have an association, but use another class as parameter or return type of an operation, then you may want to show s simpe «use» dependency.
Multiplicity is defined where needed. If it's not given then it's undefined and could be anything from zero to infinity. It depends whether you define that. One reason is simplicity, if you want to just show "it's associated". For a complete model (if that is needed) you have to specify multiplicities at all edges.
Dependency is just a weak relation. If you use some class only in parameters or as pass-through you use a dependency relation. Your 2nd picture would be wrong as you should draw the dependency (dashed line with open arrow) downwards since PP uses/depends on ShippingAddress and not the other way around.

How to deal with class instances in Jena?

In an ontology, suppose we have a class named "function" it has two instances "func1" and "func2" and suppose that the class has a data property "d".
My first problem is: how can I create individuals corresponding to either "func1" or "func2" ?
My second problem is : In the inference, with Jena rules, I want to check if individuals created for "func1" have "d" greater than some value and if individuals created for "func2" have "d" greater than another value.
I already know how to work with classes, properties and individuals but when I got to the part having instances I got stuck.
It appears that Jena Library has no support for instances, which means that you can't use getInstance() and create individuals for that instance.
Instead of having instances func1 and func2, you can make them as subclasses for the class function. This way, you can use getOntClass() and createIndividual() or getIndividual() as usual.

Regions of adjacent line portions with the same dataproperties in Protégé 5

I try to process line-based data using protege 5 and picture similar "regions" of a curve.
So I have a curve, which is deconstructed into portions of equal lengths in my ontology (class Portion, instances p_1, ... ,p_n). The portions are defined by their start- and endpoints (point_1, ... ,point_n+1), furthermore, the radius of the curve is stored in the ontology as data property of the instances (p_1, ... ,p_n). I managed to reason the adjacency relations between the different portions
hasStartPoint(p_2,point_2) o isEndpointOf(point_2,p_1) => isNextOf(p_2, p_1)
hasEndPoint(p_1,point_2) o isStartpointOf(point_2,p_2) => hasNext(p_1, p_2)
I also managed to create defined classes, storing portions with the same radius.
So here is my question: I want to reason the sets of portions (regions), which are adjecent and share the same curve radius. Then, i instances of a class Set should be created, for i different radius and non-adjecent sets, individuals (region1, ... ,regioni).
Here is the exemplary data I want to process: data I want to process
In other words: if a radius appears twice on the given line, and the portions of this radius are not adjacent, they should not be part of the same region. Further, regions should be created automatically when adding portions of different radius. The only idea I have, is to somehow traverse the set of portions with a loop over the isNext triplet, which requires some coding I guess, but I can't find anything alike here...
I hope, my problem is clear and I am happy to read if anybody has an idea on it.
Thank you in advance
Julian
From the owl-api tag, I infer you're looking to write code that uses the OWL API to reach your objective (You didn't mention which reasoner you're using in Protege - you'll need to use the same reasoner in your code to get things like hasNext relations inferred).
In OWL API, I'd do something like the following:
Infer the hasNext triples, if they are not already stored in the ontology file
For each of the defined classes that separate instances with the same radius
Retrieve all individuals of that class
Retrieve all property assertions with hasNext
Aggregate these instances into regions - e.g., seed one region for each property assertion, then merge two regions if their instances all belong to the same defined class and an endpoint in one region is a startpoint in the other. Repeat until only one region is left for a defined class (I believe, from your problem description, that regions cannot span outside of instances with the same radius) or until no further merges can happen.
In terms of OWLAPI implementation, once you have the ontology loaded in an OWLOntology object, you'd create an OWLReasoner with the OWLReasonerFactory implementation available for the reasoner of your choice (examples of this exist in the OWLAPI wiki), then there are a number of methods that can come in handy:
(Referencing OWLAPI 4 here because that's what Protege uses)
Get all individuals of a class: OWLOntology::getClassAssertionAxioms(OWLClassExpression) gives all axioms stating an individual belongs to a class, useful to retrieve instances of your defined classes. Through OWLReasoner, you can use OWLReasoner::getInstances(OWLClass)
Get all object property assertions for an individual: OWLOntology::getObjectPropertyAssertionAxioms(OWLIndividual). Useful to get hasNext values. Through the reasoner, this would be OWLReasoner::getObjectPropertyValues(OWLNamedIndividual, OWLObjectPropertyExpression)
I believe the rest of the algorithm can be implemented without OWLAPI specific code.

The rule for preconditions/postconditions of derivatives

In his paper about LSP, uncle Bob mentioned :
Now the rule for the preconditions and postconditions for derivatives, as stated by Meyer, is:
...when redefining a routine [in a derivative], you may only replace its
precondition by a weaker one, and its postcondition by a stronger one.
How could I tell if the preconditions/postconditions of a subtype instance object's method are respectively weaker/stronger than those of the supertype's method?
To formulate it without rigorous definitions:
If your parent class requires something, the child must provide the same functionality - at least.
If your routine promises to handle all inputs that are greater than zero, your derived routine must also accept all those, or more inputs.
That means that the precondition can only be weaker.
Similarly, the postcondition must be stronger. That means that you are not allowed to return a negative number in your derived routine, if the original routine promised that it will always return a positive number.
If you were to require more than what the parent requires (i.e. if you had a stronger prerequisite), then you could not be sure that you could always call that routine. Let's say that B and C are subclasses of A. Sometimes, you might have an Object of type A, which could be also actually a B or a C. If C had stronger prerequisites than A, you could run into issues when calling the routine on that Object.
I'm sorry if I didn't use the usual terminology, I can't really recall that so I just tried to stick with what makes sense to me. (It's been two years since I last attended a lecture by Bertrand Meyer)