quick question ive got a couple of sibling classes which include sub classes now what i want to do is connect a sub classes to two diffrent sibling classes, is this possible? also i want it to show in the owlviz.
example
sibling class:
rules
goals
sub class:
collect
so i want sub class collect to feature or be connected in both of the sibling classes. as the software does let me type the same name in each sibling class.
thanks
I don't quite understand the question. You can just assert the fact that collect is a subclass of both rules and goals straight from the Protege User Interface.
Make sure all of your classes are present in your isA hierarchy
Select the class collect
In Protege 4, click on the little "+" icon next to the "Superclasses" section in the Class Description Window
Assert "rules" as a superclass
Repeat and assert "goals" as a superclass.
Now "collect is a subclass of both "rules" and "goals".
AS an aside, it is not normally considered good practice to have multiple asserted inheritance in ontologies. For large ontologies, this can become a maintenance nightmare. If all you need is a small practical solution to a problem, then ok.
The visualisation of your ontology can also be done Protege - you need Graphviz installed first and point Protege to the location of the graphviz executable on your system.
Hope this helps!
Related
Can anyone tell me the steps that are required to populate an Ontology?
I have created a domain-specific Ontology (TBox = Terminological knowledge) which consists of defined classes and relations.
On the other hand, I have an IFC file (The Industry Foundation Classes) which has the instances.
I have converted the IFC file to IFC OWL and have understood that I need to map the classes into the newly created ontology.
However, I don't understand how I can get the instances of the associated classes and relations into my created ontology.
You have created two ontology files, one with the tbox and one with the abox. Usually, in this scenario the abox would use an owl:imports annotation to refer to the tbox, and would not, itself, need class declarations - it would use the IRIs for the classes already declared in the tbox. In protégé, creating an imports is straightforward.
A common issue is incorrect IRIs: if you've created your abox without initially importing the tbox, it's possible the classes you used do not match the tbox classes (e.g., the abox classes use the abox IRI as their base IRI instead of the tbox).
is there any way individual (instance) connect to class with object property? For example, individual in this case is module name: Web Programming. Object property : isClassified. Class: Network.
I've tried to define Web Programming as class, and it works because the domain and range are both classes. Same goes if I define both Web Programming & Network as individuals, it works. If the domain is a class and the range is individual, it still works. But what if the domain is individual and the range is class? Is there any way I can connect it with object property: isClassifiedIn?
Protégé is an OWL 2 DL editor (since version 4). In OWL 2 DL, an individual cannot be a class, and an object property must relate individuals to individuals only. So what you want cannot be expressed in the way you formulate it. However, you could do two things:
use an annotation property instead of an object property. This may not be ideal because an OWL DL reasoner must ignore annotation properties in the reasoning process. They are just that: annotations, similar to comments in a programming code.
relate the individual to another individual that has the same name as the class. Let me give details about this.
In OWL 2 DL, although it is not possible for individuals to be classes, it is possible for individual names to be class names at the same time. For instance, one can say (in Turtle syntax):
ex:Module a owl:Class .
ex:Network a owl:Class, owl:Thing .
ex:isClassified a owl:ObjectProperty .
ex:webProgramming a ex:Module;
ex:isClassified ex:Network .
Note that ex:webProgramming here is not related to a class. It is related to an individual of type owl:Thing. This individual has nothing to do, a priori, with the class named ex:Network, although it has the same name. This is called "punning" in the OWL 2 specification.
There is a third way: change your knowledge model such that you do not encounter this problem. I do not know your ontology, but it could be hinting at an antipattern that you should avoid.
You have to use "value".
Write your own expression using the class expression editor.
Select the class Than write:
"property" value "individual"
In MVC is there a performance gain/loss in how you place your model definitions?
Say for an employee model, you have a name space of AppName.Employee and three classes, NewEmployee, ViewEmployee & EditEmployee each linking to a different view in a T-Sql database.
Is there any difference in performance in having them all in one name space or separating them out into their own name space and class file?
I know this is an example with just three classes but on a larger scale would it matter? or would the only implication be when you compile it as apposed to run time?
There won't be any change in the performance if you put all of your classes in one namespace. Actually even it would be better to put all your classes that represent actions of the same "real" object in one namespace to be more readable and managable in the future. You would slow your performance if you put all the logic in one class and then call everything from it, which would be dumb and would make your code spaghetti.
In the VIPER design pattern, should the Interactor return all the information that might be used by multiple presenter actions or should I have a separate struct for each one?
In my case, I have a map that displays places. To display those places I need to retrieve a list of PlaceItem's from a PlacesInteractor which could have only a coordinate and a color (used to change the pin's head color) that would be transformed into a annotations by the presenter.
Now lets say that when the user selects one of the annotations in the map, a callout bubble should be displayed with more details like the place's name and a circle with the color.
Now I should create a RetrievePlaceCalloutInteractor that would return only the information for one place instead of a list of information for multiple places (Right? Or should I have only one Interactor for both scenarios?).
Should this RetrievePlaceCalloutInteractor return a PlaceCalloutItem with only the name and the color (no coordinate) of the place or should I have a single PlaceItem with coordinate, color and name, that would be returned by the RetrievePlaceCalloutInteractor and by the PlaceInteractor, and would be used by the presenter to construct either a CalloutStruct or a list of MKAnnotations?
Thank you.
VIPER is a pattern, not a very formal pattern, not a religion or a complete app architecture. For me VIPER helped to think more about a cleaner architecture but on the way I had to make decisions that were better for my specific scenario without caring to much about VIPER but about clean architecture. So, from my experience and my point of view the answer to your question is 'depends'.
In my case most of the 'Items' (I call them DO from Display Object or Data Object) have almost a one to one relationship with the 'Entities' (I call them MO from Model Object). Most of the interactors manipulate one type of Entity and they have one MO-DO mapper. I usually use the same DO for different use cases if the interactor handle more than one use case.
BUT
I also have some modules using different DOs for different uses cases, although they relate to the same entity, and also I have some DOs with combine the information of several Entities, let's say for example I needed the user name to add it to 'edited by' of a blog post I use the same DO to combine Post and User Entities.
I think VIPER 'wants' one interactor per module, that kind of forces you to have multiple use cases (related) in it, but it is up to you if you want to use different Items (my DOs) or only one.
Being a purist of clean architecture you should have different interactors, different requests and different responses for each use case.
So, as I started, it depends, the important thing is to 'draw' the boundaries properly and it doesn't matter if it's one or ten Items you use for that.
I'm creating an ontology that is based on wordnet. I want to know what level of information I should add to my own ontology? Like, for example, if the lexica has a "instance of" and "hypernym" relation, do I need to import all this in my ontology? or it's ok to just refer to the lexica in my ontology and use namespace of wordnet as a reference?
Note that I've a list of terms that I want to somehow link to wordnet so these terms make sense.