Difference between revisions of "PrF UG slots inverse slots"

This topic gives an overview of how to analyze a project and design inverse slots in Protege-Frames. An inverse slot relationship is a reciprocal relationship between two slots. Whenever one slot is filled in at one instance, its inverse slot is automatically filled in at another instance, according to the relationship you specified.

This topic describes the most common relationship - an inverse slot relationship between two instances, including the following steps: identifying an inverse relationship, analyzing the Protege-Frames components of the relationship, implementing the relationship in Protege-Frames.

You create inverse slots using the Inverse Slot widget in the Slot Editor. For more information on how to use the user interface, see Creating an Inverse Slot Relationship. Note that if you create an inverse slot relationship after one or more instances have been created, existing instances will not display the inverse slot information.

Example

For example, suppose you want to keep track at the section level of which editor(s) edit which section(s). There is already a slot named sections at the class Editor; it takes instances in the class Section as values:

sections slot

You could create an inverse slot named editor at the class Section which takes instances in the class Editor as values:

editor (inverse) slot

Now, when you edit the instance Mr. Science to assign the value Science to the slot sections, the inverse relationship is tracked by Protege-Frames. At the instance Science, Mr. Science automatically appears as a value for the slot editor.

Identifying the Relationship

First, you must determine if an inverse slot will appropriately represent the structure of your knowledge base. An inverse slot represents a reciprocal relationship that always occurs. For example, if Mr. Science edits the Science section, the Science section is edited by Mr. Science. Protege-Frames supports several different types of inverse relationships:

1. The relationship must be reciprocal.

2. The relationship can be a one-to-one correspondence, or one or both of the slots can have multiple values. For example, Chief Honcho edits a number of sections.

3. The relationship can be between instances in different classes or instances in the same class. For example, likes and is_liked_by would be a relationship where the slot and its inverse slot are both attached to Person.

4. A slot can be its own inverse. shares_ an_ office_ with would be a candidate for an inverse relationship where the inverse slot was identical with the original slot. This is a stronger tie than simply having instances in the same class.

Analyzing the Relationship for Protege-Frames

Once you have identified the relationship in your ontology, you need to analyze it in terms of your Protege-Frames project. For an inverse slot relationship between Instance slots, determine the following:

• What Protege-Frames class(es) do you want for the first set of instances? We will call this first list of classes Class_List_A.

  • Make sure to choose a class or classes that are appropriate for the project.

  • It is most important to choose a class list that is not too small; that is, you need to select a list of classes such that every possible instance is in one of those classes.

  • At the same time, for simplicity, you want the class list to be focused on the instances and not be too broad.

  • This list may consist of a single class. For example, in the newspaper project, one of the reporters, Larry Tennis-Nut, is an eager beaver and sometimes edits the Sports section. It would make sense to expand the list of classes to Editor and Reporter. However, no salesmen or columnists are allowed to edit a section. Therefore, while it would be possible to simply use the class Employee, it is cleaner not to.

• If the second set of instances is different from the first, perform the same analysis for the second set of instances. Call this second list of classes Class_List_B.

  • As before. this list may be a single class.

  • This list may be identical to Class_List_A.

Steps Required for Implementing the Relationship

In this example, we will restrict ourselves to instances in the class Section.

The following steps are necessary to create an inverse slot relationship in a Protege-Frames project:

1. Create a slot of type Instance whose allowed classes are Class_List_A. We'll call this the original_slot.

2. Create another slot of type Instance whose allowed classes are Class_List_B. We'll call this the inverse_slot. If the information is important in your ontology, it is likely that one or both of these slots already exist in the project.

3. Attach your Protege-Frames slots to the appropriate classes.

   • First, add original_slot to every class in Class_List_B. Recall that the target values of original_slot are in Class_List_A. Assigning the slot to Class_List_B is what creates the cross-connection between the classes.

   • Similarly, assign inverse_slot to every class in Class_List_A.

4. Create the inverse relationship between inverse_slot and original_slot. (You can actually do this as soon as both slots are created.)

If you already have a slot original_slot of type Instance in your project and it already has the desired allowed classes and domain, you can create a new slot specifically as the inverse of original_slot. In this case, the inverse_slot has the following properties; you can edit them after creation if necessary:

• inverse_slot is automatically attached to all classes in the list of allowed classes for original_slot.

• its allowed classes automatically includes the list of all the classes where original_slot is attached.

For information on how to use the Protege-Frames interface to make an inverse slot, see Creating an Inverse Slot Relationship.