Table of Contents
As we have seen in the previous sections, creating a topic map with the base ontology is relatively easy, but it is very unconstrained. It is not possible to express that a 'born-in' association must have a 'person' role and a 'place' role that should be played by topics of type 'Person' and 'Place' respecitvely. It is also a relatively long-winded operation to create an association between two topics, requiring the creation of an instance of ASSOCIATION and two new instances of MEMBER. TMTab makes use of Protégé's subclassing features to enable an ontology designer to specify constraints on both topics and associations and also provides some internal conventions which enable more convenient creation of topic names, occurrences and of associations between topics.
By subclassing topic, we can create a class which constrains the characteristics of the topic objects which are generated from the instances of the derived class. These constraints include:
|A fixed set of types
|A controlled set of occurrences
|A controlled set of names
|A controlled set of roles played in associations.
When subclassing from TOPIC, it is important to be aware that you are not implicitly creating a 'typing topic', you are simply defining a set of constraints which may be applied to a class of topics. You still need to create the topic or topics which define the subclass your are providing constraints for.
To specify a default type of al topics of this class, simply provide a template value for the Types slot at the class level.
"C" to create a new subclass.
"+" over the list labelled
"Template Values". In the dialog that is displayed, select "Person" (Note that you can select an instance of any class which is subclassed
The procedure outlined above ensures that any instance of the Person class created in the second step will, when exported as a topic map, result in a topic which is an instance of the topic generated from the Person TOPIC instance created in the first step.
As an exercise, create a Place subclass of TOPIC and a Place topic. Constrain the Place subclass to have the Place topic as its type. Once you have done this, create and instance of the Person class for yourself and an instance of the Place class for the place where you were born.
You can create an constrained occurence slot for your derived topic class simply by adding a new slot which accepts as its value a single instance of the OCCURRENCE class or any class derived from OCCURRENCE. A controlled occurrence can be used for a number of reasons:
|To mandate that a particular piece of information always be entered for a given class of topic.
|To mandate that a particular piece of information is given a specific occurrence type.
|To make it more convenient for a person creating instances of a given topic class to specify occurrences of that topic.
In this example we will add a "homepage" occurrence slot to the Person class
Having completed the above steps, you should now be able to go to the Person instance you created in the previous exercise and see that the form has a new, empty slot called "Homepage occ". Click on the C button on this slot to create and add a new value. Type your homepage URL (if you don't have one, make something up!) into the "Resource Locator" slot.
You will notice that the "Homepage" occurrence class actually still allows us to enter either a Resource Locator or a Resource. Ideally, we would want to prevent users from entering a value into the Resource slot. This can be easily done by modifying the form for the Homepage class to remove the Resource slot from the form, but this is beyond the scope of this tutorial. See the Protégé documentation for more details on how you can customise forms.
You can create an constrained occurence slot for your derived topic class simply by adding a new slot which accepts as its value a single instance of the NAME class or any class derived from NAME. Using constrained slots for names enables you to mandate a particular scope be applied to a given name, as well as providing separately labelled slots for different names in the UI.
Lets add a slot which is used to record the person's system user name.
You should now be able to return to the instance of Person and add a value for the new "User Name occ" slot.
To make data entry more convenient, it is possible to specify slots on a TOPIC subclass which are provided for the purposes of recording the topic(s) which are associated with the current topic. Any slot which accepts an instance of TOPIC or one of its subclasses is treated as defining the other topic(s) in the association. Each such slot may be combined with up to three other slots to provide additional information. These additional information slots use the same name as the slot defining the other topics, but with an additional suffix. So, if your slot is named "EmployedBy", then:
|The slot "EmployedBy_assoc" may be used to specify the TOPIC which defines the class of associations to which this association belongs.
|The slot "EmployedBy_thisrole" may be used to specify the TOPIC which defines the role played by the this topic in the association.
|The slot "EmployedBy_otherrole" may be used to specify the TOPIC which defines the role played in the association by the TOPIC(s) provided in the "EmployedBy" slot.
In this example, we will create a slot in which the ontology editor need only select an organisation from a list of all organisations in the ontology in order to establish a works-for relationship between the Person instance on the Organisation instance.
You should now create an instance of the Organisation class to represent your employer. Then go to the Person instance you created for yourself and add that new instance to the "Employed By" slot. Once again, notice that although all of the other slots you just created are displayed on the form by default, they could equally well be hidden as the user cannot modify the values of those slots. See the Protégé documentation for how to customise the appearance of the form.