Goozzee Help

Classes

Classes are a very powerful feature that I'm sure you'll get addicted to after some time using Goozzee. But beware that this is typically a non-ISO-compliant feature ! The ISO Topic Maps standard only defines topic types, without any inheritance mechanism. Goozzee goes a little further by implementing multiple inheritance, so that you can design complex hierarchies of classes/instances, and use classes as templates to create your future topics.

Classes define hierarchies of topics. Any topic can be promoted to a class, and any topic can be an instance of as many classes as needed, as long as you don't create loops in the hierarchy. For example, if topic A is a class, and topic B is one of its instances, you can't define A as an instance of B : this would create a circular link between A and B. If you ever try to create such a hierarchy, the program will prevent you from doing it, popping up a message box that says that circular associations are forbidden.

But I think I should precise what I mean by 'Class' and 'Instance'. Classes are topics defined under the 'Classes' topic. This 'Classes' topic is the entry point to a global hierarchy of classes and instances. I call Class a topic that belongs to that global classes hierarchy. And the topics derived from it are its Instances. But as soon as a topic becomes an instance of a class, it becomes part of the whole Classes hierarchy; that means that it can have instances too...

Classes and instances are particularly powerful when used together with properties and documents, since these properties and documents can be inherited from classes to instances. For example, let's say topic A is a class, and topic B is its instance. If we create a property called 'Foo' in A, and declare it as inheritable, this property will automatically appear in topic B too. And it will appear also in all instances of B... What's more, if we assign the value 'Bar' to property 'Foo', this value will also be inherited from class to instances. But beware that inherited values are locked. So if we go to topic B, we won't be able to modify the 'Bar' value from property 'Foo', unless we unlock it by right-clicking on it and choose the 'Force value' menu entry.

But in some cases, it can be annoying to have some property inherited to all the instances of a class. In such a situation, right-click on that annoying property, and choose the 'Make this property NOT inheritable' menu entry, so that the instances of that class won't get that property.

For documents, it works just the same : if you upload a document into class A, and declare it as inheritable, this document will appear in all the instances of class A. But in the instances, you won't be able to rename, unlink, or check-in/check-out this document : you can only view it or see its properties. If you need to rename or modify such an inherited document, you must first reach the class topic it is originated from (this topic is indicated in the class column of the documents list). Once on this topic, you'll be able to do whatever you want with the document.

Note that if a document is associated to multiple class topics, you can define it as inheritable in some classes, and not inheritable in others.

Using properties and classes this way, you can build a hierarchy of topics with predefined properties/values.

For example, let's say we want to create a hierarchy of classes describing people. Any kind of people.

The top class would be a topic simply named 'People', where we would define the 'First name' and 'Last name' properties. Then we would create an instance of that topic, named 'Contact'. It would inherit the 'First name' and 'Last name' properties, and we would add to it some 'address', 'Phone' and 'Email' properties. At last, we could create two instances of that 'Contact' topic, one called 'Business contact', the other named 'Relative'. The Business contact would get some 'Company', 'Job' properties, whereas the Relative topic would get some 'Birth date'. Once you've defined these classes, you can start creating your people topics, and make them instances of these classes, so that they will automatically get the appropriate properties, according to the class you assign them.

In the following graph representing this example, the Classes topic, the top of the classes hierarchy, is shown in red. The classes we created are in blue, with all their properties. And finally, the final instances, representing real people, are drawn in green. You see that a property that was defined in the People class (ex. : First Name) is inherited by all the classes and instances under it.

Now, let's augment the preceding graph with some inherited documents.
Let's say we add two documents, one associated to the People class, the other to the Business Contact class, and we declare these documents as inheritable. As you can see on the following graph, all the subclasses and instances of the People class will receive DocumentA.pdf, and all subclassses and instances of the Business Contact class will be associated with DocumentB.xls.

Using this mechanism, when we create a new instance of the Business Contact class (Bill Coworker, for example), it will automatically get the First Name, Last Name, Address, Phone, Email, Company and Job properties, as well as the DocumentA.pdf and DocumentB.xls files.

Note that multiple inheritance (a topic being an instance of multiple simultaneous classes) should work pretty well, but it's not very tested yet ..

Trick : There is a fast way to create classes : dropping a search result into the instances or classes buttons areas of a topic automatically turns this topic into a class. Same if you click on the New button of the instances or classes of a topic : adding an instance or a class to a topic turns it automatically into a class.

Note 1 : If you remove all the instances from a class topic, this topic will remain a class. If you want to remove it from the classes hierarchy, you must delete all the associations from its Classes buttons area.

Note 2 : Say topic B is an instance of class A. If you remove the class/instance association between A and B, topic B will loose all the properties it had inherited from A, except those for which you had entered a value specific to topic B.

Goozzee offers a very easy way to create classes and manage the whole hierarchy of classes and subclasses : the 'Ontology Editor'. You can open it from the Display menu.

The left side of this window shows a 'Classes' tab, where we're going to create our classes. On the right side, the 'Properties' tab will display the properties of the current selected class.
The other areas of this window will be explained in the chapter about ontologies.

Here is an example of the ontology editor, with the classes and properties we described in the previous paragraphs.

Right-clicking on the classes panel allows you to add classes / subclasses, or rename them. There is no limit on the number of classes, subclasses, or the number of subclasses levels you can create.
Each time you click on a class, the right-hand panels are updated to show the data relative to the selected class.

The properties panel works the very same way as the one in the main window :

Properties can be grouped into categories
Right-clicking allows you to add / remove categories and properties.

Note that all categories and properties created from this screen are automatically heritable from class to instances. And if you set a value in one of the properties, this value will be considered as this property's default value in all the subclasses and instances of this class.

What's more, this panel not only shows the properties defined for the selected class, but also the properties inherited from the parent classes. For example, in the screenshot above, we can see that the Business Contact class is selected. And among its properties, some are greyed-out. These are the properties inherited from the Contact parent class. Since these grey properties are inherited, they cannot be removed or rename in the Server class. They can only be modified in their originating class – i.e. the Contact class in this case.

Finally, note that, in Goozzee Network Edition, only the administrator user can modify things in the Ontology Editor. The other users have only read-access to this data.