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.
Related
Coming from an OOP background, Haskell's type system and the way data constructors and typeclasses interact is difficult to conceptualize. I can understand how each are used for simple examples, but some more complication examples of data structures that are very well-suited for an OOP style are proving non-trivial to translate into similarly elegant and understandable types.
In particular, I have a problem with organizing a hierarchy of data such as the following.
This is a deeply nested hierarchical inheritance structure, and the lack of support for subtyping makes it unclear how to turn this structure into a natural-feeling alternative in Haskell. It may be fine to replace something like Polygon with a sum data type, declaring it like
data Polygon
= Quad Point Point
| Triangle Point Point Point
| RegularNGon Int Radius
| ...
But this loses some of the structure, and can only really satisfactorily be done for one level of the hierarchy. Typeclasses can be used to implement a form of inheritance and substructure in that a Polygon typeclass could be a subclass of a Shape, and so maybe all Polygon instances have implementations for centroid :: Point and also vertices :: [Point], but this seems unsatisfactory. What would be a good way of capturing the structure of the picture in Haskell?
You can use sum types to represent the entire hierarchy, without losing structure. Something like this would do it:
data Shape = IsPoint Point
| IsLine Line
| IsPolygon Polygon
data Point = Point { x :: Int, y :: Int }
data Line = Line { a :: Point, b :: Point }
data Polygon = IsTriangle Triangle
| IsQuad Quad
| ...
And so on. The basic pattern is you translate each OO abstract class into a Haskell sum type, with each of its immediate OO subclasses (that may themselves be abstract) as variants in the sum type. The concrete classes are product/record types with the actual data members in them.1
The thing you lose compared to the OOP you're used to by modeling things this way isn't the ability to represent your hierarchy, but the ability to extend it without touching existing code. Sum types are "closed", where OO inheritance is "open". If you later decide that you want a Circle option for Shape, you have to add it to Shape and then add cases for it everywhere you pattern match on a Shape.
However, this kind of hierarchy probably requires fairly liberal downcasting in OO. For example, if you want a function that can tell if two shapes intersect that's probably an abstract method on Shape like Shape.intersects(Shape other), so each sub-type gets to write its own implementation. But when I'm writing Rectangle.intersects(Shape other) it's basically impossible generically, without knowing what other subclasses of Shape are out there. I'll have to be using isinstance checks to see what other actually is. But that actually means that I probably can't just add my new Circle subclass without revisiting existing code; an OO hierarchy where isinstance checks are needed is de-facto just as "closed" as the Haskell sum type hierarchy is. Basically pattern matching on one of the sum-types generated by applying this pattern is the equivalent of isinstancing and downcasting in the OO version. Only because the sum types are exhaustively known to the compiler (only possible because they're closed), if I do add a Circle case to Shape the compiler is able to tell me about all the places that I need to revisit to handle that case.2
If you have a hierarchy that doesn't need a lot of downcasting, it means that the various base classes have substantial and useful interfaces that they guarantee to be available, and you usually use things through that interface rather than switching on what it could possibly be, then you can probably use type classes. You still need all the "leaf" data types (the product types with the actual data fields), only instead of adding sum type wrappers to group them up you add type classes for the common interface. If you can use this style of translation, then you can add new cases more easily (just add the new Circle data type, and an instance to say how it implements the Shape type class; all the places that are polymorphic in any type in the Shape class will now handle Circles as well). But if you're doing that in OO you always have downcasts available as an escape hatch when it turns out you can't handle shapes generically; with this design in Haskell it's impossible.3
But my "real" answer to "how do I represent OO type hierarchies in Haskell" is unfortunately the trite one: I don't. I design differently in Haskell than I do in OO languages4, and in practice it's just not a huge problem. But to say how I'd design this case differently, I'd have to know more about what you're using them for. For example you could do something like represent a shape as a Point -> Bool function (that tells you whether any given point is inside the shape), and having things like circle :: Point -> Int -> (Point -> Bool) for generating such functions corresponding to normal shapes; that representation is awesome for forming composite intersection/union shapes without knowing anything about them (intersect shapeA shapeB = \point -> shapeA point && shapeB point), but terrible for calculating things like areas and circumferences.
1 If you have abstract classes with data members, or you have concrete classes that also have further subclasses you can manually push the data members down into the "leaves", factor out the inherited data members into a shared record and make all of the "leaves" contain one of those, split a layer so that you have a product type containing the inherited data members and a sum type (where that sum type then "splits" into the options for the subclasses), stuff like that.
2 If you use catch-all patterns then the warning might not be exhaustive, so it's not always bullet proof, but how bullet proof it is is up to how you code.
3 Unless you opt into runtime type information with a solution like Typeable, but that's not an invisible change; your callers have to opt into it as well.
4 Actually I probably wouldn't design a hierarchy like this even in OO languages. I find it doesn't turn out to be as useful as you'd think in real programs, hence the "favour composition over inheritance" advice.
You may be looking for a Haskell equivalent of dynamic dispatch, such that you could store a heterogeneous list of values supporting distinct implementations of a common Shape interface.
Haskell's existential types support this kind of usage. It's fairly rare for a Haskell program to actually need existential types -- as Ben's answer demonstrates, sum types can handle this kind of problem. However, existential types are appropriate for a large, open-ended collection of cases:
{-# LANGUAGE ExistentialQuantification #-}
...
class Shape a where
bounds :: a -> AABB
draw :: a -> IO ()
data AnyShape = forall a. Shape a => AnyShape a
This lets you declare instances in an open-ended style:
data Line = Line Point Point
instance Shape Line where ...
data Circle= Circle {center :: Point, radius :: Double}
instance Shape Circle where ...
...
Then, you can build your heterogeneous list:
shapes = [AnyShape(Line a b),
AnyShape(Circle a 3.0),
AnyShape(Circle b 1.8)]
and use it in a uniform way:
drawIn box xs = sequence_ [draw s | AnyShape s <- xs, bounds s `hits` box]
Note that you need to unwrap your AnyShape in order to use the class Shape interface functions. Also note that you must use the class functions to access your heterogeneous data -- there is no other way to "downcast" the unwrapped existential value s! Its type only makes sense within the local scope, so the compiler will not let it escape.
If you are trying to use existential types, yet find yourself needing to "downcast" them, sum types might be a better fit.
In my SDN 4 project I have a following Cypher query(a part of query):
(entity)<-[:COMMENTED_ON]-(comg:CommentGroup)
for example I can get id of entity with a following Cypher function id(entity)
How to get entity name or class name ?
Use the labels function
match (entity)<-[:COMMENTED_ON]-(comg:CommentGroup) return id(entity), labels(entity)
For each row returned, you'll get the Neo4j id and array of labels.
Assuming your NodeEntity class labels match at least one of these labels, you can then iterate and load the appropriate class instance yourself.
Generally speaking you shouldn't need to do this however.
If (entity) is polymorphic, SDN/OGM will hydrate the correct objects for you. It pretty much does under the hood what I described above, but it also handles matching on interfaces, subclasses, etc.
In my ontology I have individuals "pic Joan" which is an instance of concept "mountain" and "port Cerbère" which is an instance of concept "village". I have the relation "dominates" going from "pic Joan" to "port Cerbère" (in the sense that the mountain is perceived as being close and above the village, and hence "dominates it").
But in fact, I need to represent the information "pic Joan dominates port Cerbère at a distance of 1.5 miles NW".
So, logically, I would need to attach to the relation "dominates" the data properties "distance=1.5M", "direction=NW".
But, AFAIK, OWL does not provide properties for relations. I know that I can define range and domain for relations, but this is not about range and domain, the same relation will have different property values when taken between different instances.
How would you represent this information in OWL?
(Auxiliary question: is there some other ontology formalism where I can define properties for relations? And if yes, are there tools like Protégé to manage ontologies in that formalism?)
The most common pattern for this use case is to introduce a new class, say RelativePosition:
RelativePosition a Class.
relationType a DataProperty.
relationType domain RelativePosition.
// relationType values not specified here: might be "dominant","overlooking"...
// depending on your needs, this might need more structure.
firstFeature a ObjectProperty.
firstFeature domain RelativePosition.
secondFeature a ObjectProperty.
secondFeature domain RelativePosition.
// both properties can appear multiple times for one instance of RelativePosition
// to group sets of entities which share a relative position
More properties can be added to introduce distance, or other characteristics.
Edit: copied link from Joshua's comment below: for n-ary relations, see here
is there some other ontology formalism where I can define properties for relations?
Have you looked into Topic Maps?
In OWLAPI I have a problem with ontology imported through owl:imports statement. The problem is that instances of class and class annotations included in imported ontology are not retrieved and returned.
Lets say I have ontology Rooms and ontology Buildings.
In ontology Rooms I have then following statement which is supposed to load Buildings ontology into Rooms ontology.
<owl:Ontology rdf:about="http://example.com/rooms.xml">
<owl:imports rdf:resource="http://example.com/buildings.xml"/>
</owl:Ontology>
Then in OWLAPI I load ontology Rooms (which should automatically contain Buildings)
manager = OWLManager.createOWLOntologyManager()
roomsOntology = manager.loadOntologyFromOntologyDocument(IRI.create("http://example.com/rooms.xml"))
reasoner = Reasoner.new(roomsOntology)
factory = manager.getOWLDataFactory()
After that retrieving a class from Buildings ontology still works as expected:
buildingClass = factory.getOWLClass(IRI.create("http://example.com/buildings.xml#Building"))
When I want to get instances of class Building (definitions of these instances are included in imported Buildings ontology), then it returns nothing:
instances = buildingClass.getIndividuals(roomsOntology)
Variable 'instances' is empty now.
Same problem is with class annotations if a definition of such a class is included in Buildings ontology.
I'm able to make it work when:
I move instances definitions directly to Rooms ontology (this is not possible in production since I will have 2 separated ontologies anyway)
I use function of Reasoner class (reasoner.getInstances(buildingClass, true) returns instances from both ontologies)
I pass imported ontology to getIndividuals function instead of main (Rooms) ontology (buildingClass.getIndividuals(manager.getImports(roomsOntology)))
Workaround no. 1 is not possible to make for me (it was only for testing purposes). No. 2 and 3 do not work when I need to retrieve annotations, because there is not possible to pass multiple ontologies to OWLClass.getAnnotations function and also Reasoner has no function to get annotations.
Anyway I thought that everything should work without these workarounds since all ontologies, including imported ones, are loaded at the beginning with manager.loadOntologyFromOntologyDocument function.
The issue is that owlClass.getIndividuals(OWLOntology) does not include the imports closure. If you wish to include the imports closure, you need to use another method:
Set<OWLIndividual> getIndividuals(Set<OWLOntology> ontologies);
The set of ontologies can be any set; to use the imports closure, use
ontology.getImportsClosure()
Note that this will return, in all cases, only the individuals asserted to be long to the class. If inference is needed, you will need to use a reasoner, as you mentioned.
I have a lot to learn in the way of OO patterns and this is a problem I've come across over the years. I end up in situations where my classes' sole purpose is procedural, just basically wrapping a procedure up in a class. It doesn't seem like the right OO way to do things, and I wonder if someone is experienced with this problem enough to help me consider it in a different way. My specific example in the current application follows.
In my application I'm taking a set of points from engineering survey equipment and normalizing them to be used elsewhere in the program. By "normalize" I mean a set of transformations of the full data set until a destination orientation is reached.
Each transformation procedure will take the input of an array of points (i.e. of the form class point { float x; float y; float z; }) and return an array of the same length but with different values. For example, a transformation like point[] RotateXY(point[] inList, float angle). The other kind of procedure wold be of the analysis type, used to supplement the normalization process and decide what transformation to do next. This type of procedure takes in the same points as a parameter but returns a different kind of dataset.
My question is, what is a good pattern to use in this situation? The one I was about to code in was a Normalization class which inherits class types of RotationXY for instance. But RotationXY's sole purpose is to rotate the points, so it would basically be implementing a single function. This doesn't seem very nice, though, for the reasons I mentioned in the first paragraph.
Thanks in advance!
The most common/natural approach for finding candidate classes in your problem domain is to look for nouns and then scan for the verbs/actions associated with those nouns to find the behavior that each class should implement. While this is generally a good advise, it doesn't mean that your objects must only represent concrete elements. When processes (which are generally modeled as methods) start to grow and become complex, it is a good practice to model them as objects. So, if your transformation has a weight on its own, it is ok to model it as an object and do something like:
class RotateXY
{
public function apply(point p)
{
//Apply the transformation
}
}
t = new RotateXY();
newPoint = t->apply(oldPoint);
in case you have many transformations you can create a polymorphic hierarchy and even chain one transformation after another. If you want to dig a bit deeper you can also take a look at the Command design pattern, which closely relates to this.
Some final comments:
If it fits your case, it is a good idea to model the transformation at the point level and then apply it to a collection of points. In that way you can properly isolate the transformation concept and is also easier to write test cases. You can later even create a Composite of transformations if you need.
I generally don't like the Utils (or similar) classes with a bunch of static methods, since in most of the cases it means that your model is missing the abstraction that should carry that behavior.
HTH
Typically, when it comes to classes that contain only static methods, I name them Util, e.g. DbUtil for facading DB access, FileUtil for file I/O etc. So find some term that all your methods have in common and name it that Util. Maybe in your case GeometryUtil or something along those lines.
Since the particulars of the transformations you apply seem ad-hoc for the problem and possibly prone to change in the future you could code them in a configuration file.
The point's client would read from the file and know what to do. As for the rotation or any other transformation method, they could go well as part of the Point class.
I see nothing particularly wrong with classes/interfaces having just essentially one member.
In your case the member is an "Operation with some arguments of one type that returns same type" - common for some math/functional problems. You may find convenient to have interface/base class and helper methods that combine multiple transformation classes together into more complex transformation.
Alternative approach: if you language support it is just go functional style altogether (similar to LINQ in C#).
On functional style suggestion: I's start with following basic functions (probably just find them in standard libraries for the language)
collection = map(collection, perItemFunction) to transform all items in a collection (Select in C#)
item = reduce (collection, agregateFunction) to reduce all items into single entity (Aggregate in C#)
combine 2 functions on item funcOnItem = combine(funcFirst, funcSecond). Can be expressed as lambda in C# Func<T,T> combined = x => second(first(x)).
"bind"/curry - fix one of arguments of a function functionOfOneArg = curry(funcOfArgs, fixedFirstArg). Can be expressed in C# as lambda Func<T,T> curried = x => funcOfTwoArg(fixedFirstArg, x).
This list will let you do something like "turn all points in collection on a over X axis by 10 and shift Y by 15": map(points, combine(curry(rotateX, 10), curry(shiftY(15))).
The syntax will depend on language. I.e. in JavaScript you just pass functions (and map/reduce are part of language already), C# - lambda and Func classes (like on argument function - Func<T,R>) are an option. In some languages you have to explicitly use class/interface to represent a "function" object.
Alternative approach: If you actually dealing with points and transformation another traditional approach is to use Matrix to represent all linear operations (if your language supports custom operators you get very natural looking code).