Protege show General Class Axioms as tree - protege

for a project Im working on, I need to analyze an existing Protege ontology. (First time working with Protege.)
When Im on Entities-> Classes, I can see all classes and subclasses.
When I click on a specific subclass, there are many General Class Axioms defined.
I want a quick overview, and this is quite hard with the hierarchical list and clicking on each subclass seperately. Is it possible to show the ontology as a tree or something similar to get a quick overview?

Related

How to specify structure in which order matters in a class diagram

In my previous question I was trying to achieve the idea of ordering the classes. Although the example I presented wasn't appropriate.
So here is the situation I want to ascribe by UML class diagram:
In ODT document I have something called figure. The figure is comprised of two atomic elements: image and title(of the image). The standard allows me to put the title, either on top of the image or bellow the it. Although In my application the title will always be beneath the image like this:
So in my case I want to submit the (more specific) information that the title must be beneath the image (although the standard does not obligate so). Thus I came up to the idea of making order in my class diagram (this is first, then this, then this, etc...). Because in my case that matters.
Here is my despaired attempt:
Is there any approach to present that information through a UML Class Diagram?
In the UML meta-model, there are meta-elements called Class and Property. An instance of a Class meta-element (e.g., called Figure) may own instances of a Property meta-element. Each instance of a Property meta-element has a type (e.g., Image and Figure). Both of the instances of the Property meta-element in your model are unnamed, which, unfortunately, makes it difficult to refer to them. Nonetheless, all of the instances of the Property meta-element that an instance of the Class meta-element owns are ordered. When you create a property in a UML tool, you generally add it to the end of an ordered list.
In your diagram there are two unnamed properties that are already ordered (implicitly, based on which you created first in the tool). This order can be seen and changed in a UML compliant tool. Here is an example UML model:
I strongly recommend you name all your properties, as I have done in my example model. For example, I named them title and image, starting with a lower-case letter. Among other benefits, that way you can see which is which more easily when you reorder them.
Here is a specification window in a professional tool called MagicDraw, where you can drag properties into the order you like:
You could change the order to say that the image comes before the title.
P.S., in an analysis model, if this ordering is a rule that's important in the problem domain, I would actually show an explicit association between Image and Title having association ends called something like comes before and comes after.

How to attach OCL to UML-Profiles

I want to define some constraints for my profile. For example I need a constraint for a stereotype of the metaclass "connector". I want to define that these element must have one source like the oclkindof(source) and one target like the oclkindof(target). I found some texts by using the Google search engine like http://modeling-languages.com/wp-content/uploads/2012/03/OCLChapter.pdf or http://www.omg.org/spec/OCL/2.0/ and other slides and papers but not the right description of OCL for me.
Best regards
How to attach OCL constraints to metamodels (e.g. via stereotypes) used to vary from tool to tool.
For your project, using the Eclipse Papyrus project should suffice, which should support what you need.
In Papyrus, you can also try out OCL queries in the console on the current UML model before you store them in the profile.

How does GATE use ontologies for NLP?

What is the role of ontologies in natural language processing when using GATE?
As I understand it, at a high level, an ontology allows for the modelling of a domain consisting of classes, their instances, properties of these instances and relationships between classes in the domain.
However is there an advantage to creating a custom ontology when working with GATE?
Or can processing be as effective using the only the built in processing resources provided by ANNIE?
You can check this tutorial on ontologies in GATE.
As stated in the pdf:
Link annotations to concepts in a knowledge base.
The annotated text is a “Mention” of a concept in the KB
We can use the knowledge associated with Mentions in our IE pipeline: e.g. Persons have JobTitles, Cities have zip codes
We can use the knowledge associated with Mentions for “Semantic Search”
We can use semantically annotated documents to add new facts to our knowledge base
In the process of annotation, ontology data (instances, classes, relations, etc.) can be used by JAPE for smarter matching, i.e. matching a mention with class "engineer", knowing that "engineer" is a subclass of a "person". Also there are ontology-aware gazetteers which can create annotations based on instances and put the right class and uri for the created annotations.
The last two questions are too generic but I'll try...
After following the tutorial, you'll know exactly how to use ontologies for annotation, hence you'll know if you need to create a custom ontology for your task.
ANNIE is an example of a pipeline and a good place to start studying GATE and writing your own application.

When to use an attribute (property) instead of an association/aggregation/composition when drawing a UML

Okay so I'm a bit confused as to when I should add an attribute to a class vs drawing an association to a class when trying to show a relationship in a UML diagram.
For example let's say I have a DFA class that contains 10 state objects each having a different set of paths to various states in the DFA. Should I draw the composition line from the DFA to the State class or just type all 10 states in the attribute section of the DFA class.
Basically I'm trying to figure out if when a Class A contains (or is composed of) one or more Class Bs, should I draw a line (aggregation, composition,association dependency etc) between them or just put one as an attribute to another.
This article attempts to answer the question but I get confused as soon as he starts talking about the diagrams he drew.
The article you pointed gives one guideline:
In the years I’ve been working with different modelling teams I’ve found that the rule that works best is to use Associations for Classes and Attributes for DataTypes.
A data type is a special kind of classifier, similar to a class. It differs from a class in that instances of a data type are identified only by their value.
I kind of agree with the author, adding another point: your class diagram should be understandable. If you have a diagram with many lines crisscrossing each other the diagram is useless. When this happens you must try to find relations that can be modeled using attributes without loosing too much visual information, and replace them with attributes.
Another thing that you can do with relations and not with attributes is to display bi-directional relations (you can do this with one attribute in each class of the relation, but you loose the semantics of the relation).

CoreData: Mogenerator vs. Categories

I have recently inherited a CoreData project from an outside developer. Where I expected to find all my auto-generated NSManagedObject sub-classes, I instead have (what some googling reveals to be) classes generated by Mogenerator, a tool that I have no experience with.
I understand that the purpose of using this tool is to make it so that you can add custom code into the classes corresponding to the CoreData entities without worrying about it being lost when the model changes and the classes are regenerated... but I can do this anyways by using categories.
I currently do not see a real advantage to using Mogenerator over categories.
What are the advantages/disadvantages of using Mogenerator vs. categories? Does Mogenerator serve any additional purposes?
An advantage of using classes vs categories, is that you can extend functionality by subclassing and overriding.
For instance, if your model has subentities, it is possible for them to inherit functionality from a common master class. Subclasses could define specific behavior by overriding the desired methods. On the other hand, it is possible to override methods defined in categories, but it is not recommended. This means logic implemented as categories would have to be repeated in every subclass.
A lot of code in managed objects is boilerplate, so it's really nice to have mogenerator do it automatically.
From their 'site' http://rentzsch.github.com/mogenerator/ :
mogenerator generates Objective-C code for your Core Data custom
classes
Unlike Xcode, mogenerator manages two classes per entity: one for
machines, one for humans
The machine class can always be overwritten to match the data model,
with humans’ work effortlessly preserved
So basically it got nothing to do with categories. Mogenerator (Model Object Generator) generates code which you've seen the results from in the project you've gotten handed over.

Resources