I am a geographer and a new comer in the field of ontology trying to make sense out of these two. Therefore, I have created a simple ontology, as follows:
Thing
Feature
Lane
Segment(equivalent to Arc)
Geometry
Arc (equivalent to Segment)
Node
Dangling_Node
Intersection_node
you can find the .owl file here instantiated with a very simple spatial road dataset (fig1).
the ontology is consistent without and with instances, but when I run the reasoner, the Dangling_node instances (nodes that are connected to one link or arc) are not correctly assigned to the relevant subclass and only assigned to the Node superclass. The intersection_node (the node which is connected to more than one link) instances are correctly assigned.
I guess according to the open world assumption, the reasoner considers that the node might be 'is_extent_of' another Arc but just not mentioned here.
Do I need, or how could I have, a closure axiom for the instance?
Which part of my ontology implementation is wrong?
Edited:
Equivalent to:
Node and (is_extent_of max 1 Arc)
Subclass of (Anonymous Ancester):
(is_extent_of only Arc) and (is_extent_of min 1 Arc)
the General Class Axiom for the Dangling_node is as follows:
Node and (is_extent_of max 1 Arc) SubClassOf Dangling_node
the Dangling_node instances (nodes that are connected to one link or
arc) are not correctly assigned
You'd need to assert what's true, and then what's not true. For instance, since Node_005 is connected to just Arc_004, you'd need to say something like this:
(1) connectedTo(Node_005,Arc_004)
and
(2) {Node_005} ⊑ ∀connectedTo.{Arc_004}
(1) says that the node is actually connected to the arc. (2) says that everything that the node is connected to is an element of the class {Arc_004}, that is, that the only things it's connected to is that arc. Then, you'd an axiom that says that if something is connected to at most one arc, then it's a dangling node:
(3) (≤ connectedTo.1) ⊑ DanglingNode
(3) is a general class axiom. You can enter those in Protege, but the UI doesn't make it obvious. See this answer for more about how to create those.
Here's what this looks like in Protege (except that instead of the general class axiom (3), I just made Dangling equivalent to connectedTo exactly 1):
Class definition for Dangling
Axioms about the Node
Result of Reasoner (Node is Dangling)
Related
The above statement is taken from www.uml-diagrams.org section Assocation ends from the rather beginning.
Is there a real-world example for this?
What exactly means owned by association itself?
What is association class or how is it implement in code?
Here's my attempt. I also was unsure about the nature of an association in the past and until not so long ago where I sort of grasped it. For the full pain you have to go through pp. 197 of UML 2.5 (11.5 Associations)
What is an association?
When you have a number of classes (we may call them A, B, etc. here for brevity. They are designed to be somewhat self-consistent. So you have properties and operations which work with the latter. If our A is some mathematical class you may have a well working black box. Fine.
Now, when any class is in need of another (e.g. the B class needs objects of type A to have that math toolbox handy) you create some reference. In a programming language that will be some variable holding a reference to an instance of the needed class. That's the moment where you have an association.
In UML you can denote such an association as a property typed with the other class. Or (!) you draw a line for an association between both class boxes and place the role name towards the referenced class (telling the name of the variable the programmer shall use). This being quite simple got me some headaches since I saw notations with both property and role notation. I have not fosteres the UML spec as tho what this would mean, but I established a rule I was also teaching that this is not allowed. Tools like EA do not support roles in a correct way which forces you to manually maintain your diagrams. That is, if you have an association role from B to A and the diagram does not contain A then you should show the role as property (see my note about dot notation below). But once you place A on that diagram you should see the assocation line with the role name, but not the property (pretty confusing I admit).
Note: Dot notation
Since UML 2.5 (or was it 2.1?; but see p. 200 of UML 2.5) the OMG guys introduced the so called dot notation. That is, you have a little dot at the association line end along where the role name is. This dot indicates that the role name is actually the property of the referencing class. Pretty much what I was talking about above. And what I thought was the intention. So, I have no idea what a not-owned property would be in any case. May be a good question to be asked.
Associaton class
Assume you have class C which reflects some kind of relation between A and B (and eventually D, E, etc.). Doing that makes it an association class. It's doing that by exactly the same technique as above, just for multiple classes. (If a class has multiple relations to other classes it's not necessarily an association class, but only if it's main purpose is to set these into some relation. YMMV)
So here you have the case where an association owns the role since you have a real object. The association explained above exists only as a reference in the programming world, not a complex storage structure like an association class.
First of all, you should understand that, as opposed to the explanation of #qwerty_so, in data/information modeling, relations between two objects (called "links" in UML) are a first-class citizen. Logically/conceptually, they exist next to objects. In terms of OO implementation, they may exist either within one or both of the two participating objects in the form of object references, or outside of the two participating objects in the form of another object representing the "link".
Likewise, in data/information modeling, an Assocation, which classifies "links", is a first-class citizen that logically/conceptually exists next to the involved Classes. A binary Assocation is implementated either within one or both of the two (Java/C#/JS/etc.) classes involved in the form of a reference property (or possibly two mutually inverse reference properties), or outside of the two classes in the form of another class representing the Assocation.
In the case where a binary association has one ownership dot at one of its ends, it is unidirectional and implemented as a reference property in the corresponding class, while in the case where it has ownership dots at both of its ends, it is bidirectional and implemented as two mutually inverse reference properties, one in each of the involved classes.
What exactly means owned by association itself?
An Assocation End of a binary Assocation can be owned either by the Class on the opposite side or by the Assocation itself. In the former (more common) case, the Assocation End corresponds to a reference property of the (Java/C#/JS/etc.) class on the opposite side. In the former (less common) case, the Assocation End corresponds to a reference property of the (Java/C#/JS/etc.) class that represents the Assocation.
In principle, there could be an OOP language that supports Assocations as first-class citizens, having a keyword "assocation", in addition to "class".
What is association class or how is it implement in code?
The need for an Association Class arises when the "links" of an Association have to be characterized with the help of attributes, or when they have to be processed with the help of special operations. In such a case, an Association Class allows defining these attributes or operations. An Association Class is implemented in the form of a (Java/C#/JS/etc.) class that has corresponding reference properties for each of the Association's ends.
I'm needing some explanation for an assignement.
I'm modeling a ontology for restaurants. The classes relevant to this question are dishes and Restaurant.
The class dishes contain subclasses with the sort of dishes they serve. So for example class(dishes) has subclass(italian). To the subclass italian I've added instances like spaghetti.
The class restaurant contains mostly subclasses with necessary and sufficient restrictions to describe the type of restaurants based on the dishes they serve. But before a restaurant can get categorised I've got create instances with named restaurants. Take for example instance(pizzaFreddi) which is linked to the instance pizza through a property hasDish. Because the instance Pizza belongs to italian the restriction on one of the defined subclasses of restaurant (with ItalianDishes) infers this instance. This one works, I've used a some restriction. But what I want to do is also create a defined subclass that infers instances(namedRestaurants) that have for example more than one location. The instance PizzaFreddi for example is linked with a property isLocatedIn to the city Amsterdam and Den Haag. I've made a restriction that says: isLocatedIn min 2 City. But this does not seem to infer the instance PizzaFreddi. What's going wrong?
I've added screenshots for explanation.
http://i.stack.imgur.com/8sYNV.png
http://i.stack.imgur.com/z8rT6.png
You have Equivalent Restaurant and min 2 hasLocation, it should be enough to have SubClassOf min 2 hasLocation as you already have Restaurant as a superclass. Also, Equivalent has sometimes nonintuitive consequences - I cannot tell if in this case it is a problem without the ontology.
Also, check the inferred hierarchy and make sure you're using a reasoner. If you made changes after the reasoner was started, make sure to flush the reasoner so successive changes are seen.
I'm a new comer to Smalltalk, and learned it in Squeak. But I find many things confusing in Smalltalk. In Squeak, MetaClass and MetaClass class are each other's class mutually. If I want to create the object MetaClass I should send a message new to its class which is MetaClass class. But it must have already existed as an object in the first place to accept the message. So I must create the object MetaClass class first, which can only be done by sending a message new to the object MetaClass which has not been created yet. So it is a chicken-or-the-egg problem.
Of course I can create the objects in Squeak now, because the MetaClass and MetaClass class objects have already been created auto-magically when Squeak is opened. But I don't know how. Maybe they are created somehow rather by sending messages. But then it contradicts Smalltalk's spirits: everything happens by sending messages except a few points (variable declaration, assignments, returns and primitives).
Is there something wrong with the above reasoning? Thanks in advance.
Your question is twofold, lets answer them separately.
How do mutual dependent classes get created?
You are right, Metaclass and Metaclass class are a singularity in the parallel hierarchy of the Smalltalk classes and metaclasses. How are they created?
That depends on the Smalltalk you are using. For GNU Smalltalk I am unsure, but for the descendants of the original Smalltalk-80 (VisualWorks, VA aka VisualAge, SqueakPharo) the are created in a Bootstrap process that creates an initial image.
However, at least for Squeak, this bootstrap happened at least 15 years ago, if not more. Metaclass and its class may even be as old as 30 years.
Long story short, both classes are created outside the typical image processing and linked together manually.
But if the objects are years old, that leads to the question
What happens at Smalltalk’s startup?
Contrary to languages like Ruby or Python, which are object-oriented, too, Smalltalk does not need to create a basic object environment with things like Object on every startup. Why?
When Smalltalk saves and shuts down, it basically takes a snapshot of all its object and saves those live object to a file. When it starts up again, it just has to read the objects from the snapshot and “revive” them.
Hence, for Metaclass and Metaclass class, both objects are read from the snapshot and revived, and from this point on, they are fully functional; they don’t need to be manually created anymore.
The 'automagically created' process actually is called bootstrapping. This is how the chicken-and-egg problem gets solved. Once the system is bootstrapped, all the rest can be expressed in terms of the system itself. So, there is no contradiction with Smalltalk's philosophy that everything happens by sending messages because it only becomes a Smalltalk system once it's bootstrapped.
Metaclass class class = Metaclass is a classical academic example of strange loop. But if you inquire a bit, you could find many others in Smalltalk.
Object superclass is nil which is an instance of UndefinedObject which is a subclass of Object (longer chain via ProtoObject in Squeak Object superclass superclass class superclass = Object)
The methods of MethodDictionary are stored in an instance of MethodDictionary (MethodDictionary methodDictionary class = MethodDictionary).
The name of Symbol is an instance of Symbol (works with ByteSymbol in Squeak ByteSymbol name class = ByteSymbol).
The subclasses of ArrayedCollection are stored in an instance of Array which is a subclass of ArrayedCollection (Array superclass subclasses class = Array).
Smalltalk is a SystemDictionary which points to Smalltalk via the #Smalltalk key (This is less direct in Squeak, (Smalltalk globals at: #Smalltalk) = Smalltalk).
I let you continue the list by yourself.
Whatever the implementation, the ultimate question is whether or not you can devise a self-describing system like Smalltalk without these strange loops, and you may glimpse a not so positive answer if you follow the sublinks of http://en.wikipedia.org/wiki/Kurt_G%C3%B6del#The_Incompleteness_Theorem
Related to the the bootstrap problem encountered with such system, an efficient way is to clone oneself to change oneself, and this is particularly true in Smalltalk image when you want to change base classes that you are using for changing / describing classes.
Hence my previous and concise answer which was deleted by applying the letter of the rules (https://stackoverflow.com/help/deleted-answers) more than the spirit in my opinion:
And here is how it was resolved: http://en.wikipedia.org/wiki/Drawing_Hands
Last point, I would have preferred to read, Incredible Consistency of Smalltalk, but I'm definitely biased.
I'm developing kind of a social network with neo4j, and i wanted to make my Node object a bit more specific for my own needs. Does it considered a good practice to wrap a neo4j Node object or to inherit from it?
My problem with the wrapping approach arises when indexing the nodes objects with the built in Lucene engine. For example, what benefits will i earn if i'll wrap my Node object with a "Profile" class (with methods such as "addFriend", "setFirstName", etc..), but on the other hand, whenever i will run a query against my index i'll get back raw Node objects and not my wrapped objects? I can make some dirty solution for this case, by saving a reference for the wrapped object inside my node properties, but it looks very strange for me to do it.
What would you recommend to do in such case, in order to get a clean and well designed code?
Thanks.
I have found that wrapping a Node does not lead to very maintainable code/design. As you mentioned, one thing you need to take care of is not returning a Node but translating it to your domain object.
If your object has mostly getX methods, then you can just execute Cypher queries, compose your domain object(s) and return those. You don't even need to wrap the Node in this case- all you need is some property that you can use to look up the Node.
If you have setX methods, then you can update the Node via Cypher statements either via a save that updates all properties or on each setX (not great, as you'd be updating too often the setX method now implies persistence). Either of the two approaches does not require the Node to be wrapped.
I tried in earlier projects to wrap the Node but found that it leads to much more trouble and a generally smelly design. Now I work with pure domain POJOS's and keep Neo4j code in the persistence layer only, and this works much better for me. You haven't mentioned which language you're using- if Java, then I believe Spring Data can take care of a lot of boilerplate code.
Put your search code INTO the class they belongs to.
If you need to get, I don't know, something like getFriends from a Post class, you will create the method fromPosts into the Person class, and the getFriends method into Post.
From post, you will call the query from Person class, execute the query and return an Array / List of the nodes mapped into the Person class.
So your getFriends method into the Post class will be something like:
Person.fromPosts(self).results.map { |node| Person.new(node) }
Is simple to do that doing just a map of the result with a Person.new (or new Person, depend from which language are you using) and pass the node to the Person. This means that you must have a new method that populate object from a node.
Spring Data Neo4j is the definitive solution to your need, it maps annotated entity classes to Neo4j with advanced mapping functionality and provides access to nodes and relationships at different levels of abstraction.
In this beginners guide to Dependency Injection I noticed that the UML diagram distinguishes between "uses" and "depends upon".
Since both require some form of a reference in the class that "uses" or "depends upon", I wonder: What is really the difference between the two?
Check out the blockquotes about relationship types taken from IBM Rational Software Architect documentation.
"depends upon" means the following:
A dependency relationship indicates
that changes to one model element (the
supplier or independent model element)
can cause changes in another model
element (the client or dependent model
element). The supplier model element
is independent because a change in the
client does not affect it. The client
model element depends on the supplier
because a change to the supplier
affects the client.
"uses" means the following:
A usage relationship is a dependency
relationship in which one model
element requires the presence of
another model element (or set of model
elements) for its full implementation
or operation. The model element that
requires the presence of another model
element is the client, and the model
element whose presence is required is
the supplier. Although a usage
relationship indicates an ongoing
requirement, it also indicates that
the connection between the two model
elements is not always meaningful or
present.
As I read it "usage" is a less strict "dependency".
"Uses" is where one Class refers to another Class for some of it's operations.
"Depends on" is where a Class A uses another Class B within it's implementation (e.g. as a parameter to a method). In this case changing Class B may necessitate a change to class A.
Note I've said Class, but it applies equally to Interfaces.
Wikipedia has a good article on this: http://en.wikipedia.org/wiki/Dependency_%28UML%29
So for example you could have a Uses relationship between a Class Driver and an Interface IVehicle which exposes a method called Drive(). Changes to the implementation of Drive do not require any changes to Driver, so you say Driver uses IVehicle.
However Class Driver has a Dependency on Class Hand, since Driver has two properties: Hand LeftHand and Hand RightHand. If the implementation of these changed, one would need to consider if Driver needed updating accordingly.