-
Notifications
You must be signed in to change notification settings - Fork 44
Frequently Asked Questions
This page intends to provide useful information for anyone who wants to contribute to the OntoUML/UFO Catalog by recreating and sending an ontology, especially the ones from the List of UFO and OntoUML Ontology Models.
If you already have the ontology to be migrated in an editable format different from vpp, please check the Importing models from other editors and formats to Visual Paradigm page.
This document complements the information provided on the page How to contribute to the OntoUML/UFO Catalog. If you have not read the information there presented, please first do it before continuing.
Here you are going to find answers for the following questions:
- How do I interpret the direction of relations when documenting an ontology?
- How do I interpret the ontological natures of non-sortals classes (i.e., «category», «phaseMixin», «roleMixin», «historicalRoleMixin», and «mixin») when documenting an ontology?
- How do I document stereotypes that are not part of the current OntoUML profile?
- How should I layout a diagram?
- How to interpret the {frozen} constraint on attributes and relation ends?
- How to interpret the {essential} and {inseparable} constraints on compositions and aggregations?
- How to interpret Generalization Sets?
- When documenting an ontology, how to represent imported classes? (e.g., classes with names like "UFO::Endurant")
If the relation has a mandatory direction given by its stereotype and the related classes, this direction should be used. In case the direction is still unclear (e.g., no mandatory direction, custom, or missing stereotype), the model but be interpreted and a direction must be chosen. Relation labels and reading directions can be highly informative in this case.
Remember, however, to always keep the original’s reading direction of the relations, as the reading direction and the relations are not necessarily the same.
How do I interpret the ontological natures of non-sortals classes (i.e., «category», «phaseMixin», «roleMixin», «historicalRoleMixin», and «mixin») when documenting an ontology?
In 2018, changes were introduced to OntoUML allowing for non-sortal classes to have moments as instances. Therefore, if the model being documented was last updated before that, the instances of non-sortal classes should be assumed to be substantials (i.e., functional-complexes, collectives, or quantities), unless stated otherwise. You should also check the references of your source files, as they probably have incorporated these changes to OntoUML if they cite this paper or any other more recent.
Some stereotypes have been spelled in different ways throughout diverse publications, especially for concepts that were yet to be developed. For consistency, document every stereotype like the one presented in the original source files except for the ones listed in the table below.
If you believe that some other stereotype mapping should be included in this table, feel free to open an issue reporting your suggestion.
| Original Stereotype | Translation into Current Profile |
|---|---|
| «powertype» | «type» |
| «highordertype» | «type» |
| «hou» | «type» |
| «universal» | «type» |
| «2ndOT» | «type» |
| «relatorKind» | «relator» |
| «modeKind» | «mode» |
| «quantityKind» | «quantity» |
| «collectiveKind» | «collective» |
| «qualityKind» | «quality» |
Keep the diagrams as similar to the original ones as possible. The way that people build diagrams also carries a lot of information that can be processed as well. Also, avoid applying automatic layouts as much as possible.
Some tools rename the {readOnly} constraint to {frozen}, in which case {readOnly} must be used. Other tools also instruction the {addOnly} constraint, but this one does not have a translation into OntoUML at this moment. Document {addOnly} in the same way as in the original model.
For {essential}, set the part association end as {readOnly}.
For {inseparable}, set the whole association end as {readOnly}.
Do not infer that generalizations from the same class are part of a generalization set just from their diagrammatical representation. In a diagram, a generalization set can be identified when the generalizations that are part of it are clearly indicated with a name or with the generalization set's properties (e.g., isDisjoint, isCovering).
According to the UML Specification, when generalization relationship lines are named, that name designates a Generalization Set to which the Generalization belongs. If there are no labels on the Generalization arrows, it cannot be determined from the diagram whether there are any Generalization Sets in the model.
When documenting an ontology, how to represent imported classes? (e.g., classes with names like "UFO::Endurant")
In UML, classes from packages different than the one being viewed are represented with their package's name before the class's name followed by a double colon ("::"). I.e., the nomenclature of "UFO::Endurant" indicates that it is the class "Endurant", defined in the package "UFO" and imported into the current package being exhibited.
For documenting an ontology with imported classes, you must not write the package name and double colon in the class's name field. You must represent it by creating the class into a different package. This can be done following this procedure:
- In the Visual Paradigm "Model Explorer", right click the higher level item (which has the name of the model) and select "Model Element > Package".
- A new package will be created and a pop-up named "Package Specification" will be opened to give the name to the package. As an example, for the class "UFO::Endurant", please set the name "UFO" and press OK.
- At the same visualization ("Model Explorer"), right click the created package (e.g., "UFO") and create a new class on it (e.g., "Endurant"). To do so, select "Model Element > Class" and enter the class's name into the new pop-up ("Class Specification").
- Finally, still using the "Model Explorer", drag and drop the created class from its package to the desired diagram in which it will be represented. This will import the class into the diagram.
- For visually represent imported classes, right click an empty spot in the diagram being viewed and select "Presentation Options > Class Display Options > When Different From View".