Tutorial
From BOWiki
Contents |
[edit] Introduction
The Bowiki is an interface between an extended Wiki Markup (Wiki Text), a few tables that store this semantical data and a reasoner. Every time a Wiki page is saved, a number of functions review the wiki markup to determine whether semantical data has been added or changed, and if so, these functions trigger methods to reflect changes in both the reasoner and the database.
So what does this checking mean? To begin, during the installation we provide the ability to import an Ontology. This ontology or Knowledgebase (KB) contains some basic concepts and relations:
- Every page that belongs to the Bowiki can be classified as a Type of the KB.
- Relations between pages, which we consider instances of entities in the KB, or to Types can be defined.
- Definitions of n-ary relations can be expressed.
We distinguish between a relation (relation instance) that is used and its definition (relation). We will discuss this distinction later in this tutorial.
The ability to use relations and to classify individuals gives us the power to also use Semantic tools to organize the knowledge. One tool enables us to verify whether the semantical knowledge added is valid with respect to the Knowledge present in the wiki. This is one focus of the tutorial. But in addition it allows us to query the KB with a powerful query language, which is described in the Tutorial#Retrieving Knowledge section.
Let's start with the first and maybe most intuitive OType handling:
[edit] Adding Knowledge
[edit] OTypes
To properly classify a page according to its Type or concept in the KB, the Wiki uses a Tag. It is the string OType (during the installation you may choose a different placeholder for OType) set forth in brackets:
|
|
- [[OType:SomeType]]
This tag makes the page that we are currently editing an Instance of this Type as soon as we hit the 'save page' button. How is this done? The Markup is checked when it hits the [[OType:*]] tag. It first determines if there is an appropriate instantiation for this page to Types. It also checks whether the instantiation requested creates an inconsistency in the KB. If the instantiation creates an inconsistency, the KB will remain in its old version, the database will stay as it was and the user will be forced to correct the instantiation. If the instantiation is consistent, then the new knowledge will be added to the reasoner, the database will be updated with the new instantiation and the page will be saved.
There is a little helper for the OTypes. It's a little Select Box at the Top of the Page. This lists all OTypes and also adds an OType in the Edit Field under the cursor.
[edit] Relation Usage (Relation Instances)
We define the relations among the Bowiki pages in the same way as the Semantic Media Wiki Extension Semantic Media Wiki Extension. We have enhanced the relations among the Bowiki pages to handle n-ary relations. A special Markup as in the OType will be used. The markup is as follows:
|
|
- [[Relation Name::Role1=Namespace:Page Name;Role2=Namespace:Page Name]]
First, the relation instance is identified by its name. This connects a relation instance to its appropriate relation definition. Second, the relation instance is filled by roles. A Role is identified by its name, and is filled by a Wiki Page or an OType. According to the RDF-Standard, the imported Relations are the Triple (<subject>,<relation>,<object>). Therefore, any relation that is used from the imported KB is a binary relation (according to the arity).
If a binary relation instance is used on a page, and no subject is specified, the page itself defaults to the role-filler, Subject. For this tutorial, it would be something like Subject=Tutorial. The reasoner requires some additional information. We need to have a complete URI; a relative URI that was specified during the Installation will be added to this individual Subject. (http://descriptive.uri.net#Tutorial) A binary relation that is used and was imported during the installation must be filled with one role. This is the Object of the Relation. A role name must not be used in this case; since it is set explicit, it must be the Object.
The self defined n-ary relations that are used throughout the Bowiki are somewhat different from the imported binary relations. They can also be binary, but are limited by the means of expressiveness (there will be more on this topic in the following chapter: Tutorial#Defining Relations). N-ary Relations also have Role-fillers, but the roles may have any name and are not restricted to the Subject and Object Roles.
The following relation instance would relate the Tutorial as part of the BoWiki:
- [[part of::BoWiki]]
The subject is set by the bowiki to the page where the relation instance exists (this Tutorial) The object is assumed to be the BoWiki since it is passed without rolename.
- [[part of::BoWiki;FooBar]]
This example results in an error, since the bowiki will think that BoWiki and FooBar are fillers for the Object role. It will throw an error message about it.
It is time to learn more about defining relations in order to better understand n-ary-Relations.
[edit] Defining Relations
All Relations defined in the Ontology that was imported when the BOWiki is installed will be available for subsequent use in the BOWiki. In addition, the BoWiki allows users to define n-ary Relations. It's a combination of: Creating a Wiki Page and using a special relation instance with a syntax similar to that described above.
|
|
First, create a page in the Relation Namespace. See Read the manual to learn more about how this is done. The Namespace help page is also pretty important. After creating the page, edit it.
You are now able to define the relation arguments of the relation. An argument is specified by an appropriate name, called a role name, and an OType, to which this role classifies its role fillers. The Roles are specified through the has_argument relation instance:
This markup will create a role identified by the name Object, and any role fillers are instantiated to the OType Biological_Process.
That's all there is; there is nothing magical about defining a Relation. Currently the BOWiki does not support the establishment of properties for Relations (i.e. transitivity reflexivity). But this feature planned is planned for inclusion in a future release future release. A rough way to establish properties for current relations is to create a OWL-Export of your knowledge, change the Relation properties in an Editor of your choice, and then import the result back into the wiki in a new installation. Then save your old wiki pages.
An Overview of existing Relations can be found in a Special Page for Relations, which is a good place to get an idea of how this works.
[edit] Exercises
- Go to the Sandbox page and change it's type to a Type of the Ontology. (for OTypes look at the Special:OTypes Page).
- Create a new Relation page (if not exists) has_left_outer_boundary with the Roles Object and Subject. Try what happens if you have typos on the Types of the Ontology. Rememeber: Once you hit the save button and the Types are correcly set, there is no way to retract change or add semantical data that is set by the has_argument relation.
- Go to the Sandbox page and create a relation instance introduced in the task before. Choose as object Another Sandbox. Play around with passing roles to the relation that are unknown for this relation (i.e. Obext, Foobar, Bugbear) .
- Create a 'Another Sandbox' page and change it's type to a Type of the Ontology. Try Types that are inconsistent with the one specified in the relation definition for the Subject Role. In addition use a type that differs to the one choosen for the Sandbox
- Again create a relation instance there. Choose as object Again Another Sandbox.
[edit] Retrieving Knowledge
PLEASE NOTICE: There is a problem with the Inline Queries. The examples mentioned here are not currently working! Read more about this problem at our project page
The BoWiki not only supports the definition and instantiation of Individuals or the usage of Relations as described above. It also provides an interface for directly communicating with the Reasoner. For this purpose we designed a Query Language (See to find a snapshot of it on our project page).
The use of this Query Language (QL) is non-trivial. To become familiar with it, we provide an Interface called the Simple Semantic Search. Experienced users will love the power of Inline Queries, which provides new accessibility features and an overview of the data that is stored in the KB.
Basically, the BOWiki is great way to store semantical data. But it's nearly useless if you can't get information out of it. Consider questions like: 'Which proteins are involved in realizing the process of Apoptosis?'. In a non-semantical environment, there is no way to ask this question and receive a precise answer. But in the BoWiki, we can formulate queries that do.
In principle, this question can be formalized to: 'What Individuals of Type Biological_entity are involved in the Relation:realizes as a Subject, where the Object is the Individual Apopthosis with the OType Biological_process?'. In our Query Language this would be posed as:
- (and (realizes (Subject *)(Object Apoptosis)) OType:Biological_process).
Confused? That's why we introduced the simple semantic search. It constructs simple queries, so that we don't have to think to much about the QL.
[edit] Simple Semantic Search
The Simple Semantic Search is actually nothing more than an easy way to use part of the QL provided by the BoWiki. It translates selections from the user into the appropriate query (in the QL) and produces both the generated query and the results for that query. If you want to include the query results, you do so by copying and pasting them into an inline query. The Semantic Search appears in the BOWiki with 3 Input Fields and two Buttons. One button adds a row, the other executes a query. We will demonstrate how to use these buttons in the following examples.
If you want to retrieve all pages in which the relation has_left_outer_boundary occurs, type 'h' in the relation box and wait a second. The input box communicates with the server and searches for all relations that start with 'h'. After selecting has_left_outer_boundary (or whatever you have chosen), hit the 'Search Relations' button. The first thing that will appear is the Generated Query. It shows the QL for the query that was performed. After that, if you completed the Exercises then the Sandbox should be listed.
Well, let's perform a more sensitive search. What if we want, in addition to the relation, to restrict our search to focus on relations that have 'Another Sandbox' as an Object-role in the Relation?
As the object, choose 'Another Sandbox' (again you may use the autocomplete function that searches for everything starting with "a" and select Another Sandbox); role specifies the role name (the relation remains the same). Select "Object" and hit the search button.
The Sandbox should appear again.
[edit] Inline Queries
Inline queries are a tool for embedding queries directly within your wiki page. Since we query the Reasoner, we are also able to obtain answers achieved by transitivity. Let's consider this situation:
A has a child B and B has a child C and so on. If the relation has_child has the property of being transitive, then asking for all ancestors would retrieve all children from generation one through all children in generation n. Definition of has_child:
|
|
Consider the following relation instances:
Therefore, the set of ancestors of 'A' would be: {B, C, D, E}.
To query for all these ancestors in bowiki syntax:
- <ask format='search'> (has_child (Subject (oneof A) )(Object * ))</ask>
What is happening here? ... Let's look closely at the details. It's not that difficult.
First we type in the relation we are searching for, (has_child .... ) . Then we want to define which Individual acts as the Subject we query for: (Subject (oneof (A)).
Since we take an Individual as a role filler for our search, we must use the oneof Operator. The oneof Operator requires a set of Individuals to be provided (we could also search for the ancestors of more than one Individual). Here it is only one, A. We must define the individual between brackets. The BOWiki then knows that we are looking for an individual internal to the BOWiki.
The second argument that is marked as (Object *) indicates that this query searches for all individuals that act as Object-role fillers in this relation.
