k-infinity 4.0
1 Fundamentals

When using k-infinity, databases work the way people think: simple, agile and flexible. That is why in k-infinity many things are different than relational databases: we do not work with tables and keys, but with objects and the relationships between them. Modelling of the data is visual and oriented towards examples so that we can also share it with users from the specialist departments.

With k-infinity we do not set-up pure data storage but intelligent data networks which already contain a lot of business logic and with which the behaviour of our application may, to a large extent, be defined. To this end we use inheritance, mechanisms for conclusions and for the definition of views, along with a multitude of search processes which k-infinity has to offer.

Our central tool is the knowledge builder, one of the core components of k-infinity. Using the knowledge builder we can:

  • define the scheme but also establish examples and, above all, visualise
  • define imports and mappings from a data source
  • phrase requests, traverse networked data, process strings and calculate proximities
  • define rights, triggers and views

All these functions are the subject of this documentation. One continuous example is a semantic network surrounding music, bands, songs, etc.

1.1 Basic components

The basic components of modelling within k-infinity are:

  •     specific objects
  •     relationships
  •     attributes
  •     types of objects
  •     types of relationships
  •     types of attributes

Examples for specific objects are John Lennon, the Beatles, Liverpool, the concert in Litherland Town Hall, the football world cup in Mexico in 1970, the leaning tower of Pisa, etc.:

We can link these specific objects together through relationships: "John Lennon is a member of the Beatles", "The Beatles perform a concert in Litherland Town Hall".

Additionally, we have introduced four types here: specific objects always have a type, e.g. the type of persons, type of the cities, the events or the bands – types which you may freely define in your data model.

The main window of k-infinity: on the left-hand side the types of objects, on the right-hand side the respective, specific objects – here we can also see that the types of the k-infinity networks are within a hierarchy. You will find out more about the type of hierarchy in the next paragraph.

Even the relationships have different types: between John Lennon and the Beatles there is the relationship "is member of"; between the Beatles and their concert the relationship could be called "performed at" – if we want to generalise more, "participates in" is perhaps a more practical type of relationship.

The same applies for attributes: in the case of a person these may be the name or the date of birth. Specific persons (objects of the type 'person') may then have name, date of birth, place of birth, address, colour of eyes, etc. Events may have a location and a time span. Attributes and relations are always defined with the object itself.

1.2 Type of hierarchy – inheritance

We can finely or less finely divide types of objects: we can put the football world cup in 1970 into the same basket as all the other events (the book fair in 2015, the Woodstock festival, etc.), then we only have one type called "event" or we differentiate between sport events, fairs, exhibitions, music events, etc. Of course, we can divide all these types of events even finer: sport events may, for example, be differentiated by the types of sports (a football match, a basket ball match, a bike race, a boxing match).

In this manner we obtain a hierarchy of supertypes and subtypes:

The hierarchy is transitive: when we ask k-infinity about all events, not only all specific objects are shown which are of type event, but also all sports events and all bike races, boxing matches and football matches. Hence, since the type "boxing match" is not only a subtype of "sport event", k-infinity will reject a direct supertype / subtype relationship between event and boxing match – with a note that this connection is already known.

The hierarchical structure does not necessarily have to have the structure of a tree – a type of object may also have several upper types. However, an object may only have one type of object.

If we then wish to join the aspects of a concert and major event we cannot do this in the specific concert with Paul McCartney because we need the type of object "stadium concert" in order to do this:

Type hierarchy with multiple inheritance

The affiliation of specific objects with a type of object is also expressed as a relation in k-infinity and may as such be queried:

When do we differentiate between types at all? Types do not only differ in icon and colour – their properties are also defined in the types and when queried, the types can also easily be filtered. The inheritance plays a major role in all these questions: properties are inherited, icons and colours are inherited and when, in a query, we say that we wish to see events, all objects of the subtypes are also shown in the results.

Inheritance makes it possible to define types of relations (and types of attributes) further up in the hierarchy of the object type and hence use them for different types of objects (e.g. for bands and other organisations.

1.3 Creating and editing objects

Creating specific objects

Specific objects (in the knowledge builder they are called "instances") may be created everywhere within the knowledge builder where types of objects can be seen. Based on the types of objects, objects can be newly created via the context menus.

An object can be created by means of the button "new" and using the named entered

In the main window below the header there is the list of specific objects already available. In order that objects cannot inadvertently be created twice, the name of the object can be keyed into the search button in the header. The search does not, by default, differentiate between upper and lower case and the search term may be cut off left and right (supplement by placeholders "*" and "?"):

Editing objects

After entering and confirming the name of the object, further details for the object created may be keyed into the editor. The object may be assigned attributes, relations and extensions by using the respective buttons.

When editing an object we can, in addition to linking it to another object, also generate the target of the link if the object does not already exist.

For example, members of a music band are documented completely. Via the relation, we want to link the member Ringo Starr with the object "The Beatles". If it is not yet clear whether the object Ringo Starr is already documented in k-infinity you can use the search button to ascertain this,

or via the icon button, select 'Choose relation target' from a searchable list with all feasible targets of relation.

Deleting the relation has a member may be accomplished in two different ways:

  1. Delete in the context menu using the button further actions  and the option 'delete'.
  2. With the cursor over the button further actions  and holding down the Ctrl key.

The target object of the relation itself will not be deleted as a result of this however. If an object has to be deleted this is done via the button  in the main window or via the context menu directly on this object.

Objects may also be created using the graph editor. This process is described in the following paragraphs.

1.4 Graph editor
1.4.1 Introduction to graph editor

By using the graph editor, knowledge networks with their objects and links can be depicted graphically. The graph editor may be opened on a selected object using the graph button:

The graph always shows a section of the network. Objects from the graph may be displayed and hidden and you can navigate through the graph.

In the graph editor not only a section of the network may be displayed: objects and relations may be edited as well.

On the left-hand side of a node there is a drag point for interaction with the object. By double-clicking on the drag point all user relations of the object will be displayed or hidden.

Linking objects via a relation is carried out in the graph editor as follows:

  1. Position the cursor over the drag point to the left of the object with the left mouse button.
  2. Drag the cursor in a held down position to another object (drag & drop). If several relations are available for selection, a list will appear with all feasible relations. If there is only one feasible relation between the two objects, this will be selected and no list will be shown.

In order to display objects in the graph editor there are different options:

  • Objects may be dragged from the hit list in the main window to the graph editor window using drag & drop.
  • If the name of the object is known it can be selected via the context menu using the function "show individual".

If an object is to be hidden from the graph editor, it may be removed from there by clicking it and dragging it from the graph editor holding down the Ctrl key. In doing so, there will be no changes in the data: the object will exist unchanged within the semantic network but it will not be displayed anymore in the current graph editor section.

New objects may also be created in the graph editor. To do this we drag & drop the type of object from the legend on the left-hand side of the graph editor to the drawing area:

If there are no types of objects to be seen in the legend you can search for them using a right mouse click in the legend area. Following this, the name of the object will be given.

The editor will re-appear in which the possible relations, attributes and enhancements for the object can be edited.

1.4.2 Operations on objects within the graph editor

Within the graph editor more operations may be carried out via the context menu by using a right mouse click on the object. Partly, this context menu offers the same functions as the form editor but it also contains more graph editor specific components.

This context menu provides the following functions:

  • Hide node: here you can hide either the nodes themselves or the lower nodes from the graph editor.
  • Navigation - Extensions: this displays the extensions of the object
  • Navigation - Inferred relations: this displays the inferred relations of the object
  • Navigation - Fix: this fixes the position of a node within the graph editor so that it will not be moved when the layout has been re-constructed. Fixing can be reversed by choosing the option 'free'.
  • Navigation - Shortest path: this calculates from a selected object or type of object the shortest path to previously selected nodes. If a path with less than 6 steps is found for these targets, all intermediate stops (not shown so far) will be displayed. If this is not a success a dialogue will appear reporting the failure.
  • Navigation - Hide related nodes: this hides all nodes, that are related to the selected object
  • Display: here you can select the display size of the node icons.
  • Display - New label: here you may change the name of the term within the graph editor. The name of the object remains unchanged.


Selection of several nodes

Nodes may be marked in the graph editor – either by a mouse click (Shift key for repeated selection) or by making a box around the nodes to be marked with the mouse. Using the options "select all" and "select nothing", all or no nodes will be marked in the graph editor. Marked nodes are characterised by a red circle.

The following actions are available for several marked nodes:

  • Open graph editor: opens a new graph editor with the selected nodes
  • Delete: deletes the selected nodes not only in the graph editor but in the database
  • Hide node: removes the selected nodes from the current graph editor
  • Navigation - Fix: fixes the position of the nodes (see above)
  • Shortest path: calculates the shortest path to previously selected nodes (see above)
  • Merge: merges all selected objects to one object

The graph editor has both a menu bar and context menus which can be invoked from a node or a relation using the right mouse button. Actions from the menu bar are related to the entire graph editor or to marked nodes, actions from a context menu are related to a selected node or a relation.

The context menu for relations in the graph editor may be invoked by using a right mouse click on the relation:


1.4.3 View

The menu "View" provides many more functions for the graphic illustration of objects and types of objects:

Default settings: Opens the menu with the default settings for the graph editor. This menu is also available in: global setting window -> register card "personal" -> graph. There you can set whether attributes, relations and enhancements should appear in a small mouse-over-window above the object and how many nodes at a maximum will be visible in one step:

  • Show bubble help with details: if the mouse pointer stops on one node the details of the first ten attributes and relations will be displayed in a yellow window if bubble help was previously activated. (check "show bubble help with details" in the global setting window register card "personal" graph)
  • Max nodes: if a node/object has a lot of adjacent objects it often doesn't make sense to show them all by clicking on the drag point.

Change Background: The background color can be changed or a picture can be set as background.

Auto hide nodes: automatically hides surplus nodes as soon as the number of desired nodes is exceeded and shown. The number can be set in the input field "max. nodes" in the toolbar:

Auto layout nodes: automatically implements the layout function for newly displayed nodes.

Fix all labels: using this option the names of all relations are always visible, not only when rolled over with the mouse. Alternatively, the description may be fixed directly in the context menu of a relation.

Show internal names: displays the internal name of types of in brackets

recover hidden edges: all edges hidden by means of the context menu are shown again

The window of the graph editor and the main window of the knowledge builder provide even more menu items which may offer support when modelling the knowledge network.

On the left-hand side of the graph editor window there is the legend of the types of objects.

This legend shows the types of objects for the specific objects on the right-hand side.

By dragging & dropping an entry from the legend into the drawing area you can create a new specific object of the corresponding type.

Via the context menu for the legend entries all specific objects can be hidden from the image. Here you can also "hold" legend entries and add new types of objects to the legend (regardless of whether specific objects of this kind are represented in the image).

If the drag point has been clicked to show the adjacent objects a selection list will appear instead of the objects.

Detailed View: by default the option "Detailed View" is selected once the knowledge builder is started. You can navigate to other nodes by a double click on the drag point to the left of the object:

  • the top drag point displays the type of a specific object or the supertype of a type 
  • the lower drag point leads to the subtypes of a type
  • the drag point on the left shows relations to other objects

When the check is removed from the option "Detailed View" instead a box with a plus sign is shown:

With this plus sign you can only show those adjacent objects linked with the displayed object via relations. In the case of several links the dialogue with the selection list will likewise appear.

1.4.4 Bookmarks and history

The menu graph contains more functions for the graph editor:

Bookmarks: parts of the knowledge network or "sub-networks" can be saved as bookmarks. The objects are saved in the same position as they are placed in the graph editor.

When a bookmark is created it may be given a name. All nodes contained in the bookmark are listed in the description of the bookmark.

Bookmarks, however, are not data backups: objects and relations which were deleted after a bookmark was saved are also no longer available when the bookmark is shown.

History: using the buttons "reverse navigation" and "restore navigation" elements of a (section of) a knowledge network may be hidden again in the order of sequence in which they were shown (and vice versa). Furthermore, these buttons reverse the auto layout. The buttons can be found in the header of the graph editor window or in the menu "graph".

Layout: the layout function  enables you to position nodes automatically when many nodes are not allowed to be positioned manually. When more nodes are displayed they will also be automatically positioned in the graph via the layout function.

Copy into the clipboard: this function creates a screenshot of the current contents of the graph editor. This image may then be inserted into a drawing or picture processing programme, for example.

Print: opens the dialogue window for printing or for generating a pdf file from the displayed graph.

Cooperative work: this function enables other users to work on the graph mutually and simultaneously. All changes and selections of a user on the graph (layout, showing/hiding nodes, etc.) will then be shown to all other users synchronously.

2 Schematic definition/model
2.1 Defining types

The principle of the type hierarchy was already presented in Chapter 1.2. If new types are to be created this is always done as a subtype of a type which already exists. Creating subtypes can be carried out either via the context menu Create -> Subtype

or in the main window using the tab "Subtypes" above the search field and the tab "new":


Changing the type hierarchy

In order to change the type hierarchy we have the tree of object types in the main window and the graph editor.

In the hierarchy tree of the object editor we will find the option "Removing supertype x from y" in the context menu.

Using this option we can remove the currently selected object type from its position in the hierarchy of the object types and with drag & drop we can move an object type to another branch of the hierarchy. If we hold down the Ctrl key when using the drag & drop function the object type will not be moved but additionally assigned to another object type. What still applies is: the hierarchy of the object type allows multiple assignments and inheritance.


Configuring object types with properties

In the simplest case we define relations and attributes with an object type such as "band" or "person" and thus make them available for the specific objects of this type. (For example the year and location the band was established, date of birth and gender of people, location and date of events.)

If the object type for which the properties are defined has more subtypes the principle of inheritance will take effect: properties are now also available for the specific objects of the subtypes. Example: as a subtype of an organisation, a band inherits the possibility of having people as members. As a subtype of "person or band" the band inherits the possibility of taking part in events:

The editor for the object type "band" with directly defined and inherited relations there.

With a specific object the inherited properties are available without further ado and the difference goes without notice.


Defining relations

When dealing with relations, the following basic principle governs at k-infinity: a relation cannot only be unidirectional. If we know of a relation for the specific person "John Lennon" to be "is a member of the band The Beatles" it then implies for the Beatles the contents "it has a member called John Lennon". These two directions cannot be separated. Therefore, k-infinity demands from us the types of source and target of the relations when creating new relation types – in our example that would be person and band as well as differing names: "is member of" and "has member".

Hence the relation is defined and can now be moved between objects using drag & drop.


Defining attributes

When defining new attribute types, k-infinity needs, above all, the technical data type as well as the name. The following technical data types are available:

Type of data

What do the values look like?

Example (music network)


abstract attribute, without an attribute rating



freely definable selection list  

design of a music instrument (hollowbody, fretless, etc.)


»yes« or »no«

music band still active?

Data file

random external data file which will be imported into the knowledge network as a »blob«

WAV file of a music title  


date dd.mm.yyyy (in the German language setting)

publication date of a recording medium

Date and time

date and time dd.mm.yyyy hh:mm:ss

start of an event, e.g. concert

Colour value

colour selection from a colour palette


Flexible time

month, month + day, year, time, time stamp

approximate date when a member joined a band

Floating point number

numerical value with a random number of decimal places  

price of an entrance ticket to an event


numerical value without decimal places

runtime of a music title in seconds

Geographical position

geographical coordinates in WGS84 format

location of an event


without attribute rating, serves as a medium for meta attributes to be grouped


Internet link

link on a URL

website of a band


date interval: interval of numbers, character string, time or date

period of time between the production of an album and its publication


per attribute entity and password a clearly hashed value (Chaum-van Heijst-Pfitzmann) which is only used to validate the password  


Reference to  [...]

reference to parts of the network configuration: search, diagram of a data source, scripts and files – is used for example in the REST configuration


Character string

random sequence of alphanumeric characters

review text to a recording medium


time hh:mm:ss

duration of an event

The intention of using these data types is not to define everything as character strings. Technical data types in a defined format later offer special feasibilities of inquiring and comparing. For example, numerical values may be compared to larger or smaller values within the structured queries and a proximity search can be defined for geographic coordinates, etc.  

2.2 Details of the relation types and attribute types

Relation types and attribute types (in brief property types) are always properties of specific objects.

Creating a new relation type

Via the button "add relation" in the object editor the editor starts to create a new relation type.

Editor for creating a new relation type (see also Chapter 2.1 Defining types)

Name of new relation: names for relation types may be chosen freely within k-infinity but should be selected under the premise of a comprehensible data model. The following convention may be of help for this: the name of the relation is phrased in such a manner that the structure [name of the source object] [relation name] [name of the target object] results in a comprehensible sentence:

[John Lennon] [is a member of] [The Beatles]

Furthermore it is helpful when the opposite direction (inverse relation) takes on the word selection of the main direction: "has a member / is a member of".

Domain: here we define by which object types the relation has to be created: one object type forms the source of the relation and another object type the target. The tareget object type, in turn, forms the definition area of the inverse relation. To simplify matters, when creating you may only enter one object type at this stage. Afterwards, further object types may be defined in the editor for the relation type (see below).


Creating new attribute types

Via the button "define new attribute" in the object editor the editor starts to create a new attribute type:

Two-tier dialogue for creating a new attribute type

In the left-hand window the format of the attribute type is defined (date, floating point number, character string, etc.) After selecting and confirming the attribute type it can be further specified with the name of the attribute in the subsequent dialogue.

Supertype: here it is defined at what level in the hierarchy the attribute type should be placed.

May have multiple occurences: attributes may occur once or more than once, depending on the attribute type: a person only has one date of birth but may, for example, have several academic titles at the same time (e.g. doctor, professor and honorary consul).


Editing the details  

The dialogues for creating new attribute types and relation types are reduced views of the editors for attribute types and relation types. To edit details of attributes and relations, editors with an enhanced scope of functions have to be started.

You can reach these two editors via a listing of the attributes and relations in the tab "Schema" in the object editor:

 Alternatively, you can access them via the hierarchy tree in the left-hand side of the main window. The editors are started by a right mouse click on the relation or attribute in the context menu to be edited then clicking on "edit".

Below we can see the details of the definition of properties using the editor for the relation type as an example (the definition of attribute type is on of the subsets):

Defined for: here we can retroactively change with which object type the relation can be created. Relations may be defined between several objects and thus have several sources and targets.

Hence we can, for example, allow both persons and authors of songs in bands to be in the model or assigned to another location – even when they do not have a mutual super type. Using the button "Add" we can add more object types. Using the button "Remove" we can deprive the selected object type and all its objects from the possibility of taking on this relation.

"Change..." enables the replacement of an object type. Relations which already exist will then be deleted from the system. If there are any relations to be deleted a confirmation dialogue will appear prior to the implementation of the change.

Target: here you can retroactively change to which object types the relation can be drawn. In order to change the target of the object type you have to change to the inverse relation type: the button for changing has the name of the inverse relation type. After clicking on the button the inverse relation will appear in the editor and can be edited in the same manner as the previous relation.

Abstract: when we wish to define a relation which only serves for grouping but which is not characterised by specific properties, we define it as "abstract".

Example: if the relation "writes the song" is defined as abstract this means that when we create songs and their relation to artists or bands we can only give specific details (who wrote the text, who wrote the music). The unspecific relation "writes the song" cannot be created in the specific data, instead it can only be queried.

May have multiple occurences: it is a feature of relations whether they may occur more than once. Example: the relation "has a place of birth" may only occur once for each person, while, for example, the relation "is a member of" may occur several times for each person. Thus, logical contents may be modelled precisely. As an example of this, persons who are musicians can only have one place of birth (also at the same time) but be a member of several bands. Whether the relation may occur more than once will be stated independently for both directions of the relation: a person can only be born in one place but this place could be the place of birth for several people. 

This option can only be switched off if the relation does not occur more than once in the actual database. If it does occur more than once the system cannot automatically decide which relation is to be removed.

Mix-In / unidirectional relation: see Chapter 2.4.1 Enhancements.

Main direction: each relation has an opposite direction. In the core both directions are of the same value but there are two places where it is helpful to define a main direction:

  • In the graph editor: here the relations are always depicted in the main direction with respect to the direction of the arrow and description – regardless of the direction they were created in.
  • With unidirectional relations (without an inverse relation)

2.3 Model changes

In k-infinity you can make changes to the runtime of the model:

  • implement new types
  • make random changes to the type hierarchy (without creating tables and giving any thought to primary and secondary keys).

The system ensures consistency. When creating objects and properties the opposite direction of a relation is always included. Attribute values are checked as to whether they match the defined technical data type (for example, in a date field we cannot enter any random character string).

Consistency is also important when deleting: dependent elements always have to be deleted with them so that no remaining data of deleted elements stays in the network.

  • Thus, when an object is deleted all its properties will be deleted along with it. If, for example, we delete the object "John Lennon" we also delete his date of birth and his biography text which we can have as a free text attribute for each person, etc. Likewise, his relation "is member of" to the Beatles and "is together with" to Yoko Ono. The objects "The Beatles" and "Yoko Ono" will not be deleted; they only lose their link to John Lennon.
  • When deleting a relation the opposite direction is automatically deleted with it.

Since k-infinity always ensures that the objects and properties are in accordance with the model, deleting an object type or, where necessary, an operation has far-reaching consequences: when an object type is deleted, all its specific objects are also deleted – analogue to the relation and attribute types.

In this process, k-infinity always provides information on the consequences of an operation. If an object has to be deleted, k-infinity lists all properties which will thus be removed in the confirmation dialogue of the delete operation:

k-infinity controls where, by the change, objects, relations or attributes become lost. The user is made aware of the consequences of the deletion.

Not only the deletion, but also conversion or change of the hierarchy type may have its consequences. For example, when objects have properties which no longer comply with the model after a change in type or change in the inheritance.

Let us assume that we delete the relation "is supertype of" between "event" and "concert" and thus remove the object type "concert" and all its subtypes from the inheritance hierarchy of event to add them to "work", for example. In this case, k-infinity draws our attention to the fact that the "has participants" relations of the specific concerts would be omitted. This relation is defined in "event" and would thus no longer apply to the concerts.

There are possibilities for preventing the omission of relations as a result of model changes. If an object type has to move within the type hierarchy, for example, the model of the affected relation has to be adapted prior to this.

For example, if "concert" is to be located under "work" within the hierarchy and no longer under "event". To this end, the relation "has participants" will be assigned to a second source: that can be either the object type concert itself or the new item "work". The relation will hence not be lost.

k-infinity pays particular attention to the type hierarchy. If we delete a type from the middle of the hierarchy or remove a super/sub relation type, k-infinity then closes the gap which has ensued and puts back the types which have lost their supertypes into the type hierarchy to the extent that they keep its properties as far as possible.


Special functions

Changing type: objects already in the knowledge network may be moved to objects of another type. For example, if the object type "event" differentiates to "sports event" and "concert". If there are already objects of the type sports event or concert in the knowledge network, they may be selected from the list in the main window and quite simply moved to a new, more suitable object type using drag & drop.

Alternatively, we can find more information in the context menu under the item "edit".

Select type: using this operation we can assign a property to an object.


Reselect relation target: in relations this does not only apply to the source, but also the relation target.

Convert subtypes to specific objects (and vice versa): the border between object types and specific objects is, in many cases, obvious but not always. Instead of setting up only one object type called "musical direction" as in the case of our sample project, we could have set up an entire type hierarchy of musical directions (we decided against this in this network because the musical directions classify so many different things such as bands, albums and songs and therefore they do not provide any good types). It may happen, however, that we change our minds in the middle of the modelling. For this reason, there is the possibility of changing subtypes into specific objects and specific objects into subtypes. Any relations which may already exist will be lost in the process if they do not match the new model.

Converting the relation: source and target of the relation will remain the same, only the relation type will be converted.

Converting the attribute: source/object will remain the same but it will be assigned to another attribute type:

When converting the individual relations we are usually quicker when we delete these and replace them with another one. However, it may happen that meta properties are attached to the properties which we do not want to lose. On the other hand, the converting operations are also available for all properties of a type or a selection thereof. A prerequisite is, of course, that the new relation or attribute type is also defined for the source and target objects.

If changes are made to the model, consideration should always be given to the fact that restoring a previous condition may only be carried out by installing a backup. Analogue to the related databases there is no "reverse" function.

2.4 Presentation of diagrams in the graph editor

Until now we have mainly been dealing with linking of specific objects within the graph editor. Presenting such specific examples, discussing them with others and, where necessary, editing them is also the main function of the graph editor. We can, however, also present the model of the semantic network directly using the graph editor, e.g. the type of hierarchy of a network.

Types of objects will then be displayed as nodes with a coloured background and types of relations as a dotted line:

Relation types in the graph editor

If until now we have been referring to relations in the graph editor, this concerned relation objects between specific objects of the knowledge network. Moreover, the general types of relations (hence the diagrams of the relations) may also be presented in the graph editor. A relation is depicted in the graph editor as two semi-circles which represent the two directions (main direction and inverse direction). Therefore, between these two nodes there is the relation "inverse type of relation":

The presentation of a type of relation and the hierarchy within the graph editor may be shown analogue to the object editor with all supertypes and subtypes:

Attribute types may also be depicted in the graph editor – they are shown as triangular nodes.

Analogue to the type of object hierarchy the hierarchy of the relations and attributes within the graph editor may be changed by deleting and dragging the supertype relation.

2.5 Meta model and advanced modelling options
2.5.1 Enhancements

As a further means of modelling, k-infinity offers the possibility of enhancing objects.

For example, if a person performs the role of a guitarist in a band but plays another kind of instrument in another band. In addition, the person exercises the role of the composer.

The fact that one person can play different roles in a knowledge network may be regulated via a special form of a object type. This may not contain any objects, but enhance objects from another object type (e.g. in this case "person"). For this purpose, the object type "role" is implemented into the knowledge network, for example and the different roles created for persons as subtypes: guitarist, composer, singer, bassist, etc. In order that these "role object types" may enhance objects this function will be defined in the editor for the object type by checking the box "type can extend objects":

Enhancements are displayed in the graph editor as a blue dotted line:

As a result of this enhancement we have achieved several things simultaneously:

  • We have formed sub objects for the persons (we can also imagine these as sections or – with persons – as roles). These sub objects may be viewed and queried individually. They are not independent, when the person is deleted the enhancement "guitarist" along with the relations to the bands or titles are gone.
  • We have expressed a multi-digit content. We cannot express anything on separate relations between persons, instruments, title/band – in this case the assignment would no longer succeed.

For this purpose the relation "plays in the band" for the enhancement "guitarist" has to be defined. This effect that persons inherit an additional model via the enhancement may be helpful regardless of multi-digital contents.

From a technical point of view, the enhancement is an independent object which is linked to the core individual by means of the system relation "has enhancement" or inverse "enhanced individual". Its type (system relation "has a type") forms the enhancement type.

When defining a new enhancement, two object types play a role: in our example we want to give persons an enhancement and we have to provide this information to your type "person". The enhancement itself again has an object type (usually even quite a lot of object types); in our case "guitarist". With the type "guitarist" (and with all others with which we want to enhance the persons) his specific objects will be dependent.

When querying enhancements in the structure search we have to traverse individual relations. From the specific person via the relation "has extension" via the enhancement object "Guitarist". From there you can reach the band via the relation "plays in band".


The essence of this example with the role "guitarist" is that the relation "plays in a band" is linked to the enhancement but not with the person. Hence, a consistent assignment is possible with several instruments and several bands.

If the option mix-in is selected the relation, on the other hand, is created with the core object (person) itself. The reason for this is that enhancements are sometimes not used to express more complex contents but to assign an object polyhierarchically to different types. This object inherits in this manner relations and attributes of several types.

When we setup an extensive type hierarchy of events, for example, with the subdivision into large and small events, outdoor and indoor events, sports and cultural events, we can either characterise all combinations (large outdoor concert, small indoor football tournament, etc.) or create the different types of events as possible enhancements of the objects of the type "event". Then we can assign an event via its enhancements as a football tournament and, at the same time, as an outdoor event as well as a large event. Via the enhancement "football tournament" the relation "participating team" may then be inherited, via the enhancement "outdoor event", for example, still the property "floodlight available". When we have placed these properties in mix-in they may be queried like direct properties in the events.

If a mix-in enhancement is deleted it acts like a "normal" enhancement: there has to be at least one enhancement available which entails the mix-in property. When the last of these enhancements is deleted the relation or the attribute in the core object is also deleted.

2.5.2 Shortcut relations

A special form of the relation is the shortcut relation. Hidden behind this is the possibility to shorten several relations already available and defined and which are present in the semantic graph database in a connected row by means of a suitable relation. In this manner the system can, to a certain extent, draw a direct conclusion from A to B from an object A in the semantic graph database which is connected to an object B via several nodes.

For example, a band publishes a recording media in a certain style of music, ergo this style of music can likewise be assigned to this band:

In the form editor the inferred relation path is defined via the relations "is author of" and "has style".

In the queries the shortcut relation can be used like any other relation as well.

In the current version of k-infinity it is recommended that several nodes and edges be queried via search modules as a result of the improved overview in the structured queries.

2.5.3 Meta properties

In Chapter 2.1 properties of a lesser complexity in object types for objects were defined.  For example, users can add or edit contents to the music knowledge network which we are treating here as an example via a web application. It should, however, be noted which information was changed from whom and when. To do this, attributes and relations and, in turn, for attributes and relations are required in all combinations.

Attributes to attributes: for example, discussions and reviews are listed in the music knowledge network as text attributes for music albums. If it is to be noted when discussions and reviews were added or when they were last changed we can define a date attribute which is assigned to the discussion and review attributes:

Attributes to relations: This date attribute may also be located at a relation between albums and personal sentiments such as "moods" if the users are given the possibility of tagging:

Relations may be used on attributes and on relations. For example, those users should be documented who have created or changed an attribute (e.g. review of an album) or a relation between an album and a mood at certain times:

These examples together with the editing information form a clearly demarcated meta level. Properties of properties are, however, usable for complex "primary information":

If, for example, the assignment of bands or titles to the genres be weighted, a rating as "weight" may be given to the relation as an attribute.

An attribute of a relation may also be the sum of a transfer or the duration of participation or membership.

Relations to relations may also be expressed as "multi-digit contents". For example, the fact that a band performs at a festival (that is a relation) and in doing so takes a guest musician with them. He doesn't always play with the band and hence doesn't have a direct relation to it. Likewise, he cannot be generally assigned to the festival but is assigned to the performance relation.

Modelling of meta properties may, of course, also be realised by implementing additional objects. In the last example the fact that the band performed at a festival enabled an object of the type "performance" to be modelled. A significant difference is that in the meta model the primary information can simply be separated from the meta level: the graph editor does not show the meta information until it is requested and in queries, also in the definition of views the meta information can simply be left out. The second difference lies in the delete behaviour: objects are viable independently. Properties, even meta properties, are not on the other hand; when primary objects and their properties are deleted the meta properties are deleted with them.

Incidentally: properties can not only be defined for specific objects but also for the types themselves. A typical example of this is an extensive written definition with a object type, e.g. "what do we understand by a company?" That is why we are always asked whether we want to create them for concrete objects or subtypes when creating new properties.

2.5.4 Multilingualism

The attributes "character string", "data file attribute" and" selection" may be created multilingually. In the case of the character string attribute and data files, several character strings may then be entered for an attribute:

With data file attributes several images (e.g. with labels in other languages) may be uploaded analogically. In the case of selection attributes all selection options are deposited in the attribute definition; here it doesn't matter in which language the selection for the specific object is made.

All other attributes are depicted in the same manner in all languages, e.g. Boolean attributes, integers or URLs.

If the image deviates in other languages attributes adapt their image automatically, depending on the language: for example, dates according to European spelling day|month|year are shown in US format month|day|year.

In k-infinity separate attributes are not simply deposited for values in other languages, instead they remain as a separate layer for an attribute with language variations. You don't have to bother about the management of different languages when developing an application, but only the desired language for the respective query:

In k-infinity preferred alternative languages can be defined: if there is no attribute value, e.g. a descriptive text in the queried language the missing text can be shown in other languages if they are available. The order of sequence of the alternative languages may also be defined.

Multilingual settings are, for example, used in search.

3 Search / queries

Querying of the semantic network has various subtasks for which we can configure different search modules: often we would like to process the user's entry in a search box (character strings). Usually we would like to pursue the links for the queries within the semantic network.

  • Structured queries
  • Simple/direct queries (simple search, full text search, trigram search, regular expressions, parameterised hit quality)
  • Search pipeline


3.1 Structured queries

Using structured queries you can search for objects which fulfilled certain conditions. A simple example for a structured query is as follows: all persons who master a certain instrument should be filtered.

At first there is the type condition: objects of the type person are searched for. The second condition: the persons have to master an instrument. Third condition: this instrument has to be the violin.

In the structured query the relation "plays an instrument", the type of the target of the relation and the value of the target "violin" form three different lines and thus also three search modes. The third condition that the instrument has to be a violin may also optionally be omitted. In the hit list you would then find all persons who play any random instrument.

Often conditions (in this case the instrument) should not be determined previously but be approved completely. Depending on the situation, an instrument may be given as a parameter in the application:

The conditions may thereby be randomly complex and the network traversed as far as possible:

Slightly more complex example: persons or bands who deal with a certain issue in their songs (to be more exact in at least one). In this case you do not search for the name but the ID of the issue as the parameter – typical for searches, for example, which are queried via a REST service from the application [Figure – "ID" instead of "name"]

The type hierarchies are automatically included in the structured queries: The type condition  "work" in the search box above includes its subtypes albums and songs. Even the relation hierarchy is included: if there is a differentiation below "is author of" (e.g. "writes text" or "writes music") the two sub-relations will be included in the search. The same applies for the attribute type hierarchy.



If a new structured query is created, the topmost of all types is entered at first per default. In order to limit the query even more you can simply overwrite the name or select "Choose type" by clicking on the icon.

The button allows you to add more conditions to the structured query. Deleting conditions takes place at the beginning of each line where the type condition is listed (relation, attribute, target, etc.). When you click on the button the following menu will appear which may vary slightly depending on the context.

From all possible conditions, focus has, until now, been on the very first item in the menu. A complete explanation of all conditions and options of the structured queries can be found in the next chapters.

3.1.1 Use of structured queries

Ein Hauptzweck der Strukturabfragen ist, in Anwendungen zu einem bestimmten Kontext Informationen zu liefern. Die Strukturabfrage aus dem letzten Abschnitt kann z.B. dem Endnutzer in einem Musikportal zu einem Thema wie Liebe, Drogen, Gewalt usw. eine Liste aller Künstler oder Bands generieren, die das Thema in ihren Liedern behandeln.

Dazu wird die Strukturabfrage in der Regel über ihren Registrierungsschlüssel in einen REST-Service eingebaut. Das Thema, für das sich der Nutzer gerade interessiert, geben wir der Abfrage mit seiner ID als Parameter mit.

Beispielszenario: Ein Nutzer sucht durch Eingabe eines Suchstrings nach einem Thema. Es liegt also keine ID vor, sondern nur einen String anhand dessen das Thema identifiziert werden soll. Dabei soll aber im Suchergebnis gleich angezeigt werden, welche Bands Songs zu dem Thema geschrieben haben. Zu diesem Zweck kann eine Strukturabfrage als eine Komponente in eine Such-Pipeline eingebaut werden - hinter die Abfrage, die den Suchstring verarbeitet.

Strukturabfragen sind unter anderem deshalb ein zentrales Werkzeug innerhalb von k-infinity, weil auch die Bedingungen für Rechte und Trigger mit Strukturabfragen formuliert werden: Angenommen es wird in einem Musikportal nur Künstlern und Bands erlaubt, Kommentare zu hinterlassen. Im Rechtesystem lässt sich entsprechend formulieren, dass nur Künstler und Bands, die zu einem bestimmten Thema mindestens einen Song geschrieben haben, zu diesem Thema Kommentare hinterlassen dürfen. Strukturabfragen können auch in Exporten benutzt werden, um zu bestimmen, welche Objekte exportiert werden soll.

Alle diese Verwendungen haben eines gemeinsam: wir sind nur an qualitativen, keinen gewichteten Aussagen interessiert. Das ist die Domäne der Strukturabfragen gegenüber den Such-Pipelines.

Nicht zuletzt sind Strukturabfragen auch Hilfsmittel für uns Knowledge-Engineers. Mit ihnen können wir uns einen Überblick über das Netz verschaffen und Reports sowie To-do-Listen zusammenstellen. Beispielfragen, die mithilfe von Strukturabfargen beantwortet werden können, sind:

  • Zu welchen Themen gibt es wie viele Künstler/Bands?
  • Müssen bestimmte Themen ausgebaut werden weil sich zu viele Relationen ansammelt haben, oder sollten umgekehrt spärlich besetzte Themen zusammenlegt oder geschlossen werden?

Für diese Verwendung ist es sinnvoll, die Strukturabfragen in Ordnern organisieren zu können.

One main purpose of the structured queries lies in the applications for a certain context to provide information. The structured query in the last paragraph may generate, for the user, a list of all artists or bands in a music portal who deal with the topics of love, drugs, violence, etc. in their songs.

For this purpose, a REST service is usually implemented via their registration key. The topic in which the user is interested just now is the one we enter into the query with his ID as a parameter.

The following is an example of this scenario:  a user searches for a topic by entering a search string according to a topic. There is therefore no ID, but only a string on the basis of which the topic should be identified. Thereby, the search results should show which bands wrote songs on this topic. For this purpose, a structured query can be installed in a search pipeline as a component – behind the query which processes the search string.

Therefore, structured queries are, among other things, a central tool within k-infinity because the conditions for rights and trigger are also phrased using the structured queries: assuming only artists and bands are allowed to leave comments within a music portal. With the rights management it may be stated that only artists and bands who have written at least one song on a certain topic are allowed to leave their comments on this topic. Structured queries may also be used in exports in order to determine which objects are to be exported.

All these applications have one thing in common: we are only interested in qualitative, not weighted statements. That is the domain of the structured queries in comparison to the search pipelines.

Last but not least, structured queries are also tools for us knowledge engineers. With them we can obtain an overview of the network and compile reports as well as to-do lists:

  • To what topics there are how many artists/bands?
  • Do certain topics have to be removed because they have collected too many relations or should, on the other hand, sparse topics be compiled or closed?

For this application it makes sense to be able to organise structured queries into folders.



The structured queries are implemented on the results tab with the button search.

The search results can then be further processed (e.g. copied into a new folder) but they are not kept there permanently.

The path which the structured query has taken may only be viewed in the graph editor to backtrack it. To this end, one or more hits are selected and displayed using the button graph.

A structured query may be copied in order to create different versions, for example. Likewise there is the possibility of saving them in XML format, regardless of the network. The structured query may therefore be imported into another network. However, this is limited to versions of the same network, e.g. to backup copies, because the structured query references types of objects, relations and attributes via their internal IDs.

3.1.2 Setup of structured queries

Very indirect conditions can be expressed within structured queries: you may randomly traverse between the elements throughout the structure of the knowledge network. Artists and bands may be found who wrote songs on certain topics but which we cannot name specifically using their titles. Several conditions

Condition chains may either be randomly deep or several parallel conditions may be expressed: additional conditions are added to any random condition element as a further branch:

Several conditions: English bands with songs on a certain subject Alternative conditions

In the example mentioned above only artists or bands can be found who created songs on a defined subject and who come from England. If, instead, we want to find all artists and bands which fulfil one of the two conditions they will be expressed as 'alternative'. By clicking the symbol of the condition in the form of the relation "is the author of" you can select an alternative from the menu:

Alternative conditions – the band either has to be English or have songs on a certain subject

If there are further conditions outside the alternative bracket there are objects in the hit list which fulfil one of the alternatives and all other conditions. Transitive / repeating queries

Let's assume the bands are assigned to either cities or countries within the network. Of these, in turn, it is known which cities are in which countries. In order to document these contents in the search it was possible to very simply expand the condition string: we were able, for example, to search for bands which are assigned to a city which, on the other hand is in England. However, in this manner those bands will not be found which are directly assigned to England. In order to avoid this we can state in the relation "is located in" that it is optional and therefore does not have to be available.


Simultaneously, we can also include hierarchies which are several levels deep using the function "Repetitions". For example, is known from the band ZZ Top that they come from the city of Houston which is in Texas. In order to also retain the band as a result when bands from the USA are queried we can state in the relation "is located in" that this relation has to be followed up until repetitions are reached: Negative conditions

Conditions can likewise be purposefully negated. For example, if punk bands are searched for, which do not come from England. To this end, the negative condition is setup as a so-called "Utility query".

The utility query delivers bands from England – from the main search a reference can be established and thereby noted that the search results are not at all allowed to comply with the criteria of the search help – in this manner we remove the results of the search help from those of the main search and only obtain bands which do not come from England.

Interaction takes place as follows: the utility query is compiled in the type condition and can, after conclusion of the main search above, be linked with the menu item "reference". At this stage you can then select which type the reference should be (in this case negative). Equivalent conditions

The reference allows references to be made to other conditions of the same query within a structured query:

Here the last condition references the first one, i.e. the band who writes the cover version also has to be the author of the original. Without a reference the search would read as follows: bands which have written songs which cover other songs which were written by any (random) bands. Incidentally, the result is, for example, the band "Radiohead" (they covered their own song "Like Spinning Plates"). Further options in setting up the structured queries

Search macros: other structured queries but also other searches can be integrated into structured queries as macros. In doing so, there is the possibility of outsourcing repeating, partial queries into your own macros and thus adapting the behaviour at a central location when changing the model. A macro can be integrated into each condition line.                        

An example from our music network: from bands to all their achievements, no matter whether they are albums, songs which are directly assigned to the band or songs on the albums of the bands. We need these partial queries more frequently, for example in a structured query which returns the bands to a certain mood. We start this query with a type condition - we are looking for bands - and integrate the pre-defined module as a condition for these bands:

The objects which return those which are integrated into the structured query as macros have, of course, to match the condition with which they are linked from the point of view of their type. With the aid of the identifier function, the query (from the "invoking" query) can still be continued with additional conditions. In our case the albums and songs from where the macro query originates are defined by the invoking query: namely albums and songs with the mood "aggressive". Integrating the search macro into the structured query is carried out through the menu "Query structure". Under structured query macro (registered) there is a selection list with all the registered macros.

Simple search: using the search mode "simple search" the results of a simple search or a search pipeline may serve as input for a structured query. Each respective simple search can be selected by means of the selection symbol. The input box contains the search entry for the simple search. Further conditions can enable a simple search to be filtered further, for example.

Cardinality condition: a search for attributes or relations without its own conditions may be carried out with a cardinality operator (characterised by a hash tag #). You may use the cardinality greater than or equal to, less than or equal to and equal. The normal equal operator of the relation or attribute condition corresponds to greater than or equal to 1.

We have thus covered everything we can find within the menu "Query structure":

3.1.3 The conditions in detail

The type condition

The beginning of the structured query determines which objects should appear as the results. To do this you click on the type icon for the first condition and select "Choose type" in the menu, the input mask then starts in which the name of the object can be entered.

Alternatively, you can simply overwrite the text behind the type icon with the name of the object.

In the second step the relation condition is added. For example, a search is made for the place of origin of a band and "has location" is set as a relation condition. The target type of the relation is added automatically which, however, can also be changed (if, for example, the "has location" relation for countries, cities and regions applies but we only wish to have the cities).

There are further functions available for a type condition. In the item for this there is the item "Schema" in the general condition menu which we can reach via the button : several types of conditions are defined consecutively what is interpreted by "or" in the query. For example, we search for works or events on a particular style of music as follows:

We can just search for types of objects instead of specific objects or both at the same time by checking the boxes "Subtypes" and "Instances" in the menu "Schema".

This is what the condition looks like when a search is made for both specific works as well as subtypes of the work (albums and songs).

Without inheritance: normally, the inheritance starts automatically with all types of conditions of the structured query. If a search is made for events in which bands play a certain style of music, all subtypes of events are then incorporated into the search and then we are provided with indoor concerts, club concerts, festivals, etc. In the vast majority of cases this is exactly what is desired. For exceptions there is the possibility of switching off the inheritance and restrict the search to direct objects of the type event, i.e. by excluding the subtypes of objects.


Operators for the comparison of attribute values

Attributes may also play a role as conditions for structured queries. For example, if it does not suffice to only identify objects which show an exact predefined value or the value entered as a parameter. For instance, bands which were founded after 2005 or songs which are more or less 3 minutes long or songs which contain the word "planet" in their title. These require comparison operators. The type of comparison operators which k-infinity offers us depends on the technical data type of the attribute:

Comparison operators for dates and quantities

The comparison operator Exactly equal constitutes a special case: the index filter is switched off and a search can be made after the special character * which is normally used as a wildcard.

The comparison operator Between requires spelling of the parameter value with a hyphen, e.g. "10.1.2005 - 20.1.2005".

The comparison operator Distance requires spelling of the parameter value with a tilde, e.g. "15.1.2005 ~ 5" – i.e. on 15.1.2005 plus/minus 5 days.

Comparison operators for character strings

Comparative value results from the script: attribute value conditions may be removed from partial searches and replaced by a script and attribute condition. The results of the script are then used as a comparative value for the attribute value condition, e.g. if the comparison operators do not suffice for a specific query.


Identifying objects

The structured query provides several options for identifying objects within the knowledge network. To simplify matters, the previous examples often defined the objects. This type of manual determination may, in practice, be of help in testing structured queries or determining a (replaceable) default for a parameter entry.

At this point we have already become familiar with the combination with the name attribute which can, of course, be any random attribute. In the menu item "Identify" we will find some more options for defining starting points for the structured query:

Access right parameter: the results of the query may be made dependent on the application context. This particularly applies in connection with the configuration of rights and triggers when, generally speaking, only "user" is usable.

Script: the objects to be entered at this point are defined by the results of the script.

Semantic element with ID: you may also determine an object via its internal ID. This condition is normally only used in connection with parameters and the use of the REST interface.

In folder: using the search mode "in folder" the contents of a collection of semantic objects can be entered into a structured query as input. The selection symbol will enable you to select a folder within the work folder hierarchy. The objects of a collection are filtered with respect to all other conditions (including conditions for terms).

3.2 Simple search / full-text search

Processing the search queries of users may be carried out with or without interaction (e.g. with type-ahead suggestions). The starting point is, in any case, the character string entered. In configuring the simple search we can now define with which objects and in which attributes we search according to the user input and how far we differ from the character string entered. Here is an example:

How do we have to design and organise the search in order to receive the below feedback on objects from the entry "white"? In all cases we will have had to configure the query to show that we only want to have persons and bands as the results. How is it, however, if there are any deviations from the user input?

  • When is the (completely unknown) Chinese experimental band called "WHITE" a hit? If we state that upper case and lower case doesn't matter
  • When will we receive "Whitesnake" as a hit? If we understand the entry to be a substring and attach a wildcard
  • When "Barry Eugene Carter"? If we not only search through the object names but include other attributes as well – his stage name is namely "Barry White".

These options can be found again in the search configuration as follows:

Configuration of the simple search with (1) details as to which types of objects are to be browsed through, (2) in which attributes the search has to be made, (3) upper case and lower case and (4) placeholders.

3.2.1 Simple search – settings in detail


The entry is often incomplete or we want to retrieve the entry in longer attribute boxes. To do this, we can use placeholders in the simple search. The following settings for placeholders can be found in simple search:


  • Placeholder behind (prefix) finds the [White Lies] for the entry "white"
  • Placeholder in front (suffix) finds [Jack White]
  • Placeholder behind and in front (substring) finds [The White Stripes]
  • Caution! Placeholder in front is slow.


The option "Always wildcards" works as if we had actually attached an asterisk in front and/or behind. Behind automatic wildcards there is an escalation strategy: in the case of automatic placeholders, a search is made first with the exact user entry. If this does not deliver any results a search will be made with a placeholders, depending on which placeholders have been set. With the option prefix or substring there is once again a chronological order: in this case you look for the prefix first (by attaching a wildcard) and, if you still can't find anything, you make a search for a substring (by means of a prefix and attaching a wildcard).

If you are allowed to attach placeholders in your search you can state in the box minimal number of characters how many characters the search entry must show to actually add the placeholders. By entering 0 this condition is deactivated. This is particularly important if we set up a type ahead search.

With the weighting factor for wildcards you can adapt the hit quality to the extent that the use of placeholders will result in a lower quality. In this manner we can, if we want to give the hits a ranking, express the uncertainty contained in the placeholders with a lower ranking.

If the option "No wildcards" is selected the search entry will not be changed. The individual placeholder settings will then not be available.

The user can, of course, him/herself use placeholders in the search entry and these can be included in the search.

Apply query syntax: when the box for the option "Apply query syntax" has been checked a simplified form of the analysis of the search input is used in which, for example, the words "and" and "or" and "not" no longer have a steering effect. Nevertheless, in order to be able to define how the hits for the tokens should be compiled, the default operator can be switched to "#and" or "#or". What applies to all linking operators is the fact that they do not refer to values of individual attributes, but to the result objects (depending on whether "hits only for attributes" has been set). A hit for online AND system thus delivers semantic objects which have a matching attribute for both online and the system (which is not necessarily the same).

Filtering: simple searches, full-text searches and also some of the specialised searches may be filtered according to the types of objects. In the example described in the last paragraph we made sure that the search results only included persons and bands. Attributes which do not match a possible filtering are depicted in red bold print within the search configuration dialogue. In our case this could be an attribute "review", for example, which is only defined for albums.

Translated attributes: in the case of translated attributes we can neither select a translation, nor have the language dynamically defined. Search for multilingual attributes, then in the active language or in all languages, depending on whether the option "in all languages" is checked.

Query output: a maximum query output may be defined by entering the maximum number in the "results" box. This checkbox will then limit the query output and the mechanism can be activated or deactivated. By entering the number in the output the checkbox will automatically be activated. Caution: if the number is exceeded no output will be shown!

Server-based search: generally speaking, each search can also be carried out as a server-based search. The prerequisite for this is that an associated job client is running. This option can be used when it can foreseen that very many users will make search queries. By outsourcing certain searches to external servers, the k-Infinity server will be disburdened.

3.2.2 Multiple-word search input



In our examples for queries the users have, until now, only entered one search term. However, what would happen if the user entered "Abba Reunion News", for example, and thus would like to find a news article which is categorised by the keywords "Abba" and "reunion"? We have to disassemble this entry because none of our objects would match the entire string or at least not the article being searched for:




Our examples so far do not, however, fall short only due to multi word search inputs. We also often have search situations in which it does not make sense to regard the names or other character strings from the network, with which we compare the input, as blocks , e.g. because we would like to retrieve input in a longer text. In this case the wildcards will eventually no longer be an adequate means: if we also want to disassemble the input on the page of the object and the text attributes which have been searched through it would be better to use the full-text search.



3.2.3 Full-text search and indexing

If we want to view or search through longer texts word by word, e.g. description attributes we recommended the use of full-text index. What does something like that look like?

The full-text index records all terms/words which occur within a portfolio of texts so that k-infinity can quickly and easily look up where a particular word can be found in which texts (and in which part of the text).

"Texts", however, are not usually separate documents within k-infinity, but the character string attributes which have to be searched through. Their full-text indexing is a prerequisite for the fact that these attributes are offered in the search configuration.

Even full-text indexing concerns the deviations between the exact sequence of characters within the text and the text which is entered in the index and which can hence be retrieved accordingly. An example of this: a message from the German music scene:

In this example we find a small part of the filter and word demarcation operations which are typically used for setting up a full-text index:

Word demarcation / tokenizing: often in punctuation such as exclamation marks are placed directly on the last word of the sentence without a space in between. In the full-text index, however, we want to include the entry {tour}, not {tour!} – hardly anyone will search for the latter. For this purpose, when setting up the full-text index we have to be able to specify that certain characters do not belong to the word. The decision is not always so easy: In a character string such as "Cuddle-Classic" which occurs in a text we have to decide whether we want to include it as an entry in the full-text index or as {cuddle} and {classic}. In the first instance our message will then only be found if an exact search is made for "Cuddle-Classic" or, for example, "*uddle-c*", in the second instance for all "classic" searches.

What we will probably keep together in spite of the occurrence of punctuation, i.e. exclude from tokenizing, are abbreviations: when AC/DC come to Germany o.i.t. (only in transit) it is probably better to have the abbreviation in the index instead of the individual letters.

Filter: by using filter operations we can both modify words when they are included in the full-text index and also completely suppress their inclusion. Known: stop words, at this point we can maintain a list. Moreover, we probably do not want individual words (Bela B.) to be in the index like this – the likelihood of confusion is too great. Using other filters we can restore words to their basic forms or define replacement lists for individual characters (e.g. in order to eliminate accents). Other filters, in turn, clear the text of XML tags.

We can set all this in the admin tool under "index configuration". We can then assign these configurations (in the knowledge builder or in the admin tool) to the character string attributes. The index configuration is organised in such a manner that filtering can take place before the word demarcation and after the word demarcation.

The full-text search does not affect the wildcard automatism of the other queries but the user may, of course, provide his input with wildcards.

3.3 Search pipeline

Search pipelines enable individual components to be combined to complex queries. Single components perform operations in the process, e.g.:

  • traversing the network and thus determining the weighting
  • performing structured queries and simple queries
  • compiling hit lists

Every query step produces a query output (usually a number of objects). This query output may, in turn, be used as input for the following components in the pipeline.


Let us assume that songs and artists from our musical network are characterised with tags named 'moods'. Based on a certain 'mood' we now want to find which bands best represent this mood.

Step 1 of our search pipeline goes from a starting mood (in this case "aggressive") via the relation is mood of to the songs which are assigned to the mood 'aggressive':


In the second step we go from the number of songs detected in the 'mood' searched for to the corresponding bands via the relation has author:

Now we would like to pursue a second path: from the starting point 'mood' "aggressive" to the musical directions which are characterised by aggressiveness.

Based on this number of relevant musical directions we have to go to bands which are assigned to this mood. We go down this alternative path in one step using a structured query:

From the last two steps we give the indicator "musical direction" a somewhat lower weighting and compile the outputs at the end:

The steps are processed in sequence: the input and output define which step will continue to work with which hit list. For instance, in this manner we would be able to begin again with 'mood' on our alternative path.


The principle of weightings

It was the goal to give the bands we obtained as outputs a ranking which shows how great their semantic "proximity" is to the mood aggressive. In particular, we influence ranking in this search at two positions: right at the end we weight bands higher in the summary which are found both via their musical direction and their songs. In this case this applies to Linkin Park and the Sex Pistols. The higher ranking of Linkin Park results from the fact that again and again different songs lead to Linkin Park with the mood aggressive. Since more aggressive songs from Linkin Park are in the database, Linkin Park should be 'rewarded' with a higher ranking.

3.3.1 Compilation of search pipelines

The individual components of a search pipeline are depicted in the main window in the box components in the order of sequence in which they are implemented.

Using the button add we can insert a new component at the end of the existing components.

Grouping with blocks serves only to provide an overview, e.g. for the compilation of several components in a functional area of the search pipeline.

The order of sequence of the steps can be changed using the button upwards and downwards or with drag & drop.

Using the button remove the component selected will be removed, to include all possible sub components. The configuration for the component selected is displayed on the right-hand side of the main window.


Configuration of a component

A selected component may be configured on the right-hand side of the main window using the tab "configuration": most components need input. This usually comes from a previous step. In this way, the first components in our example pass on the output under the variable "songs" to the next component, this then goes from there to the bands and, in turn, gives the output to the next steps as "bandsThroughSongs":

Using the input and output variable we can also, in later steps, re-set to the initial output which we saw in the last paragraph.

We define the input parameters as global settings for the search. Under the name which we assign here we can then access these inputs in our search pipeline during each step. In our example the input parameter for identifying typical bands is the mood.

Some components enable a deviation from the standard processing sequence:

Individual processing: elements of a quantity, e.g. hits from a search may be processed individually. This is practical if you want to assemble an individual environment of adjacent objects for search hits. In individual processing each element of the configured variable in the single hit is saved and implemented in the sub components.

Condition for set parameters: this component only carries out further sub components if predefined parameters have been set, whereby the value is insignificant. New sub components may be added by using the 'add' tab.

KPath condition: By using a KPath condition we can determine that the sub components may only then be implemented if a condition expressed in KPath is fulfilled. If the condition is not fulfilled the input will be adopted. KPath is described in the manual for KScript.

Output: we can stop the search at any stage and return the input. This component is also useful for testing the search pipeline.

The block components which we have also used in our example group a lot of individual steps. In order to maintain an overview in extensive configurations we can also change the name of the component using the tab "description" and add a comment as well. Neither the block components nor the description have any functional effects. Both of them only serve the 'legibility' of the search pipeline.


Test environment

Using the test environment in the menu we can analyse the functioning of the search. The upper section contains the search input and the lower section the output. The input may be a search text or an element from the knowledge network, depending on which required and optional input parameters we have globally defined in the search pipeline. If we wish to enter an element from the knowledge network as a starting point we select the corresponding parameter line and add an attribute value or a (knowledge network) element, depending on the type.

On the tab Trace search a report of the search will be displayed. This primarily consists of the configuration of the output variables and the duration of the implementation of each component. The log begins with the pre-configured variables (search string) as well as active users.


Calculation possibilities

In the case of some components it is possible to summarise several quality values into one single quality value – e.g. in "summarise hits" but also when traversing the relations (see example above). For this purpose the following methods of calculation are available:

  • addition / multiplication
  • arithmetic average / median
  • minimum / maximum
  • ranking

The option "ranking" is then always suitable when we want to assemble an overall picture from individual references, e.g. if we want to calculate many paths, at least partially independent paths – at the end still with differing lengths – to an "overall proximity". Using the ranking calculation we ensure that all positive references (all independent paths) keep increasing their similarity without exceeding 100%.

In the search pipeline quality values are always specified as floating point numbers. The value 1 thereby corresponds to a quality of 100%.

3.3.2 The individual components

Weighted relation/attribute

Based on semantic objects we can, in this step, traverse the graph and assemble relation targets or attributes. For this purpose we have to specify the relation or attribute type.

Caution: outputs are only for the assembled targets and no longer for the output quantity. If these have to be displayed we have to later summarise the input and output hits.

In traversing a relation the weighting of the hits can be influenced. Let us assume that we want to semantically expand the "output mood" of our search with "sub moods", but this indirection is to suppress into a ranking: links to bands which extend via the sub moods should not count as strong as links via an output mood. To this end we can, for example, allocate a general value of 0.5 to the relation route and calculate or multiply it with the input weight. Then the sub moods added to this step will only count half as much as the direct ones.

Instead of specifying a general weight for the route of a relation we can also read the value from the meta property for the basic type of floating point number of the relation selected. if this attribute is not available or none was configured the standard value will be used. The value should range between 0 and 1. The generation of hits may be configured in detail: for relations a new hit can also optionally be created for the relation source (instead of for the relation target).

If a relation has been selected as a property and hits for relation targets are created we can also optionally pursue the relation transitively. The value of the quality decreases with each step until it falls below the threshold value. If an object has more relations than specified for a maximum fan-out these relations will not be pursued. The higher the attenuation factor, the more the value of the quality decreases.


Structured query

Using structured query components we can either search for semantic objects / move from an existing quantity to other objects (as with the weighted relation) or filter an amount.

When we search for objects we enter our number of outputs from one of the previous steps into the search via the name of the parameter. (In general: within the expert search, variables of the search pipeline such as a search string can be referenced via parameters). In this case the input remains empty.

In contrast, for filtering we specify an amount of objects. All objects which match the search condition are included in the output. Objects which do not match the search condition may, as an option, be saved in another variable (rest).

We can either define the structured query into the components ad hoc or use an existing structured query.

Caution: when an existing search has been selected a copy is created and any changes we make to the structured query for the purpose of the search pipeline result in changes for all other applications as well.



Using the component "search", you can initiate simple searches, full-text searches and other search pipelines. Simple searches and full-text searches are provided with a character string, e.g. with the search string: this is a parameter which is available in all search pipelines to process the user input. The amount of hits for the search invoked is conveyed to the output of this component.

By linking search pipelines to other search pipelines we can combine frequently occurring sub-steps. Several parameters and entire hit lists can be conveyed to other search pipelines. Using linked search pipelines we can also exchange several parameters, i.e. in the linked search we can access the output from each sub-step of the surrounding search and vice versa. When we go to "selected parameters" we can re-name them if we want to use a hit list from the linked search but have already used the name. Alternatively, we can simply adopt some of the parameters from the linked search in order to avoid such conflicts.


Merge hits

This component enables us to merge several hits lists from different, previous steps. The following methods are available for merging:

Union: all hits which occur in at least one of the amounts are displayed as output.

Intersection: only hits which occur in all quantities are displayed as output.

In the case of union amounts and overlap it may happen that a semantic object occurs in several hit lists and then has to be calculated as an overall hit with new hit quality. For this purpose we again have the aforementioned methods of calculation available.

Difference: one of the hit lists has to be defined as the output quantity. The other quantities are subtracted from this.

Symmetric difference: The output quantity comprises objects which are only contained in an exact partial quantity (= everything except for the average of two quantities).

Three different types of overall hits can be created. The selection is then particularly relevant when the partial hits contain additional information.

  • Create uniform hits, remember original hits as causes: new hits are created which contain the original hits as the cause.
  • Extend original hits: the original hit is copied and contains a new quality rating. If there are several hits for the same semantic object a random hit will be selected.
  • Create uniform hits: a new hit is created and the properties of the original hit are lost.


Merge partial hits

In individual processing it is often necessary to create an overall amount of partial hits. This enables the component "merging partial hits". This merges all hits of one or several partial hit quantities. The difference between merging hits is that the merge does not take place until the end and not for each single quantity of partial hits. This is particularly relevant for the calculation of the quality because merging hits, e.g. in median would provide false ratings.



A search pipeline may contain a script (Javascript or Kscript). This can access the variables of the search pipeline. Moreover, a script can convey several parameters to the search pipeline. The output of the script is used as the output of the component.

The Javascript API and KScript are described in separate manuals.


Set quality from attribute value

We can adopt the quality rating from an attribute of the semantic object for hits. If the object does not have this exact attribute the standard rating is used. The rating should range from 0 and 1.


Compute quality from weighted qualities

In order to adapt the quality of a search hit it may be helpful to calculate an overall rating from individual sub-qualities, whereby the qualities have to be available as numerical values. The new overall quality is calculated from these values.


Compute overall quality of hits

You can calculate the overall quality of a hit list from the quality ratings of each hit list.


Filter quality

We can limit hit lists to hits whose quality rating lies within the predefined limits (minimum and maximum). Normally, we like to filter out hits which are below a certain quality threshold.


Limit number of hits

If the overall number of hits within a hit list is to be limited we can add the component "limit number of hits". Using the option "do not split hits of the same quality" we prevent an arbitrary selection from being made from hits of the same quality in order to maintain the overall number. We then receive more hits than predefined.

In some very special cases we can also randomly select the hits, e.g. when we have a large amount of hits of the same quality and want to generate a preview.


Scale quality

The quality ratings of a hit list can be scaled. A new hit list with scaled quality ratings is calculated and the calculation follows in two steps:

  1. The quality ratings of the hits are restricted. The threshold values can either be defined or calculated. The calculation will determine the minimum and maximum ratings of the hits. If the limits are prescribed and a hit has a quality rating beyond the threshold value, the rating will be limited to the threshold value. If you wish to remove these kinds of hits you have to upstream the component "restrict quality". Example: depicting percentual ratings on school grades. 30% is the average; over 90% is a high score. The ratings can be scaled within a linear 30% to 90%.
  2. Following this, the quality ratings are scaled linearly. Hits with the minimum/maximum input rating receive the minimum/maximum scaled rating.


Compute hits quality

With the aid of a KPath printout a new hit with calculated quality will be created for a hit. The KPath printout is calculated on the basis of the input.

3.4 Searches in the Knowledge-Builder

With the exception of the structured queries which are created in the folders and also implemented there, all searches in the header of the knowledge builder are made available for internal usage.

For this purpose we have to drag & drop a pre-configured search only into the search box of the header of the knowledge builder. If this contains several searches to be selected from you can select the desired search from the pull-down menu by clicking on the magnifier icon. The search input box always contains the search mode which was last carried out.

We can remove the search using the global settings where we can also change the sequence of the various searches in the menu.

3.5 Special cases
3.5.1 Full-text search Lucene



The full-text search may also alternatively be carried out via the external indexer Lucene. The search configuration is then analogue to the standard full-text search, i.e. attributes may, in turn, be configured in the search which are also connected to the Lucene index; the search process is also analogue. In order to configure the Lucene indexer connection we hereby refer you to the corresponding chapter in the admin manual.


3.5.2 Search with regular expressions

 Regular expressions are a powerful means of searching through databases for complex search expressions, depending on the task concerned.

Search with regular expressions


The [CF]all

the call, the fall




cars, caravans, Carmen, etc.


doom, loom, etc. (but not room)


As search inputs, k-infinity supports the standard also known from the standard known from Perl which, for example, is described in the Wikipedia article for regular expression.


3.5.3 Search in folders

The search in folders is carried out in names of folders and their contents:

  • folders whose name matches the search input
  • fodlers which contain objects which match the search input
  • expert searches which contains elements which match the search input
  • scripts in which the search input appears
  • rights and trigger definitions which contain elements which match the search input

Using the search input #obsolete, you can target your search for deleted objects (e.g. searching in rights and triggers). When configuring the search the number of folders to be searched through can be limited. Furthermore, the option "search for object names in folders" may be deactivated. This is helpful if you do not want to search for semantic objects in folders because in the case of extensive fodlers (e.g. saved search results) the search for object names may take a very long time.

4 Folders and registration

Along with the objects and their properties we also create diverse other elements in a typical project: for example, we define queries and imports/exports or write scripts for special functions. We can organise everything which we create and configure in folders.

The folders are shared with all others who are working on the project. If we do not wish to do this we can deposit things in a private folder, e.g. for test purposes. This is only visible for the respective user.

A special form of the folder is the collection of semantic objects in which we can save objects manually by drag & drop for processing at a later date. To do this, we can simply push them into the folder using drag & drop and additionally there are operations for keeping output lists in folders. The collection of semantic objects merely keeps references on the objects: at that point in time when we delete one of these objects it will also be deleted in the collection.



Queries, scripts, etc. may be mutually invoked (a query may be setup in another query or in a script; conversely a script may be invoked from a search pipeline). For this purpose, there are registration keys with which can equip queries, import/export illustrations, scripts and even collections of semantic objects and structured folders to enable them to provide other configurations with functionality. The registration key has to be clear. Everything which a registration key contains will automatically be adopted in the folder "registered objects" or in a sub folder of this type.


Shift, copy, delete

Let us assume we have a folder named "playlist functions" in our project. This would perhaps contain an export, some scripts and a structured query "similar songs" which we want to use in a REST services. At that point in time when we give the structured query a registration key it will be adopted in the folder "registered objects" (paragraph "technology"). I.e. the structured query "similar songs" will appear in the folder "registered objects" under "query". It will also stay there when we remove it from our project sub-folder "playlist functions". If we remove the registration key the query will automatically disappear from the registry.

The basic principle when deleting or removing: queries, imports and scripts may be contained in one or several folders simultaneously and must be in at least one folder. Not until we remove our query from the last folder will it actually be deleted. Only then does k-infinity also request a confirmation of the deletion action. The same applies to the removal of the registration key.

If we wish to delete the query in one step, regardless of in how many folders it is located, we can only do this from the registry.

Folder settings

In the folder settings we can define quantitative limits for search outputs, folders and object lists (lists of the specific objects in the main window of the knowledge builder by selecting an object type on the left-hand side). Automatic query up to the number of objects specifies up to what number of objects the contents of the folders are shown without any further interaction by the user. If the limit set there is exceeded, the list will first remain empty and in the status bar the message "query not implemented" will appear. Carrying out a search without any input in the input bar shows all objects. At least until the second limit is reached: maximum number of query outputs, maximum number of outputs in lists of objects – in this instance high values – after these values no more output in fact, queries have to restrict, e.g. in lists of objects in which we also have the beginning of the name in the input box.

5 Import + Export

Mit den Abbildungen von Datenquellen können wir Daten aus strukturierten Quellen in k-infinity importieren und Objekte und ihre Eigenschaften in strukturierter Form exportieren. Die Quellen können Excel/CSV-Tabellen, Datenbanken oder XML-Strukturen sein.

Die Funktionen für den Import und Export decken sich größtenteils und sind daher alle in einem Editor verfügbar. Um auf die Funktionen für den Import und Export zugreifen zu können, muss zunächst ein Ordner (z.B. der Arbeitsordner) ausgewählt werden. Dort kann über die Schaltfläche "Neue Abbildung einer Datenquelle" eine Datenquelle ausgewählt werden, aus der importiert, bzw. in die exportiert werden soll.

Alternativ findet man die Schaltfläche auch im Reiter "TECHNIK" unter "Registrierte Objekte" -> "Abbildungen von Datenquellen".

5.1 Mappings of Data Sources

Folgende Schnittstellen und Dateiformate stehen für den Import und Export zur Verfügung:

  • CSV/Excel-Datei
  • XML-Datei
  • MySQL-Schnittstelle
  • ODBC-Schnittstelle
  • Oracle-Schnittstelle
  • PostgreSQL-Schnittstelle
  • Für den Austausch von Benutzer-IDs ist eine Standard-LDAP-Schnittstelle implementiert.

Im Folgenden wird anhand einer CSV-Datei beschrieben, wie man einen tabellenorientierten Import/Export anlegt. Da bis auf den XML-Import/Export alle Importe/Exporte tabellenorientiert sind und sich die einzelnen Datenquellen ansonsten nur in ihrer Konfiguration unterscheiden, kann das Beispiel der Abbildung der CSV-Datei auch auf die Abbildungen der anderen Datenbanken und Dateiformate übertragen werden.

5.1.1 ... with a CSV file as an example

CSV-Dateien sind das Standard-Austauschformat von Tabellenkalkulationstools wie Excel. CSV-Dateien bestehen aus einzelnen Klartext-Zeilen, bei denen die Spalten durch ein fest vorgegebenes Zeichen wie z.B. ein Semikolon getrennt sind. Functional principle

Nehmen wir als erstes Beispiel eine Tabelle mit Songs: Beim Import dieser Tabelle möchten wir für jede Zeile ein neues konkretes Objekt vom Typ Song anlegen. Aus den Inhalten der Spalten B bis G werden Attribute des Songs bzw. Relationen zu anderen Objekten:

Ausgehend vom Song, bauen wir die Struktur von Attributen, Relationen und Zielobjekten auf, die durch den Import angelegt werden soll (linke Seite). So wird für die Zeile 18 beispielsweise ein Objekt vom Typ Song mit folgenden Attributen und Beziehungen angelegt:


Wir können uns aber auch dafür entscheiden, die Angaben aus der Tabelle anders zu verteilen also z.B. Erscheinungsjahr und Interpret dem Album zuordnen und das Genre wiederum dem Interpreten. Eine Zeile bildet immer noch einen Kontext, muss deswegen aber nicht zu genau einem Objekt gehören:


Überall, wo wir in unserem Beispiel neue konkrete Objekte als Relationsziele aufbauen, müssen wir immer mindestens ein Attribut zu diesem Objekt angeben, hier jeweils das Namensattribut, mit dem wir das entsprechende Objekt identifizieren können. Datenquelle - Auswahl und Optionen

Nachdem wir, die Schaltfläche "Neue Abbildung einer Datenquelle" ausgewählt haben, öffnet sich ein Dialog, mit dem wir die Art der Datenquelle und den Namen der Abbildung angeben müssen. Haben wir die Datenquelle bereits in der semantischen Graph-Datenbank registriert, können wir diese im unteren Auswahlmenü finden.

Mit der Bestätigung auf "OK" öffnet sich der Editor für den Import und Export. Unter "Import-Datei" können wir den Pfad unserer zu importierenden Datei angeben. Alternativ können wir die Datei auch über den Button rechts daneben auswählen. Sobald die Datei ausgewählt wurde, werden die Spaltenüberschriften und ihre Positionen in der Tabelle ausgelesen und im Feld rechts unten angezeigt. Die Schaltfläche "Aus Datenquelle lesen" kann bei eventuellen Änderungen der Datenquelle die Spalten erneut auslesen. Die Spalte "Abbildungen" zeigt uns später jeweils auf welches Attribut die jeweilige Spalte der Tabelle abgebildet wird.

Die Struktur unserer Beispiel-Tabelle entspricht komplett den Standard-Einstellungen, sodass wir unter dem Menüpunkt Optionen nichts weiter berücksichtigen müssen. CSV-Dateien können jedoch sehr unterschiedliche Strukturen aufweisen, die mit folgenden Einstellungsmöglichkeiten berücksichtigt werden müssen:

Encoding: Hier wird die Zeichenkodierung der Import-Datei festgelegt. Zur Auswahl stehen ascii, ISO-8859-1, ISO-8859-15, UCS-2, UTF-16, UTF-8 und windows-1252. Ist nichts ausgewählt, wird die Standard-Einstellung übernommen, die der des laufenden Betriebssystems entspricht.

Zeilentrenner: In den meisten Fällen reicht die Einstellung "automatisch erkennen", die auch standardmäßig ausgewählt ist. Sollte man jedoch feststellen, dass Zeilenumbrüche nicht richtig erkannt werden, sollte man die entsprechende korrekte Einstellung manuell auswählen. Zur Auswahl stehen CR (carriage return, engl. für Wagenrücklauf), LF (line feed, engl. für Zeilenvorschub), CR-LF und Keine. Der Standard, der den Zeilenumbruch in einer Textdatei kodiert, ist bei Unix, Linux, Android, Mac OS X, AmigaOS, BSD und weiteren LF, bei Windows, DOS, OS/2, CP/M und TOS (Atari) CR-LF und bei Mac OS bis Version 9, Apple II und C64 CR.

1. Zeile ist Überschrift: Es kann vorkommen, dass die erste Zeile keine Überschrift enthält, was mit dem Entfernen des standardmäßig gesetzten Häkchens bei "1. Zeile ist Überschrift" dem System mitgeteilt werden muss.

Werte in Zellen sind in Anführungszeichen eingeschlossen wählt man aus, damit die Anführungszeichen nicht mit importiert werden, wenn man das nicht möchte.

Spalten identifizieren: Ob die Spalten über ihre Überschrift, die Position oder die Zeichenposition identifiziert werden, muss angegeben werden, da ansonsten die Tabelle nicht korrekt erfasst werden kann.

Trennzeichen: Falls ein anderes Trennzeichen als das standardmäßige Semikolon verwendet wird, muss dies ebenfalls angegeben werden, sofern die Spalte nicht über die Zeichenposition identifiziert wird.

Darüber hinaus gelten folgende Regeln: Falls ein Wert der Tabelle das Trennzeichen oder einen Zeilenumbruch enthält, muss der Wert in doppelte Anführungszeichen gestellt werden. Falls der Wert ein Anführungszeichen enthält, muss dieses verdoppelt (»""«) werden. Definition von Zielstruktur und Abbildungen Object mapping

Nun fangen wir an die Zielstruktur, die in der semantischen Graph-Datenbank entstehen soll, aufzubauen. In unserem Beispiel beginnen wir mit einer Objektabbildung der Songs. Um ein neues Objekt abzubilden müssen wir den Button "Neue Objektabbildung" bestätigen.

Als nächstes muss der Typ des zu importierenden Objektes angegeben werden. Ist der Haken bei "Mit Objekten aller Untertypen" gesetzt, werden beim Import auch Objekte aus allen Untertypen von "Song" berücksichtigt. Attribute mapping / Identifing objects

Nun wollen wir die in der Tabelle enthaltenen Informationen mit der Objektabbildung der Songs verknüpfen. Es sind sowohl Attribute zu den einzelnen Songs, als auch Relationen vertreten. Um zunächst den Titelnamen eines Songs in der Abbildung anzulegen, fügen wir der Objektabbildung von Song ein Attribut hinzu. Ein Klick auf die Schaltfläche "Neue Attributabbildung" öffnet einen Dialog, mit dem die entsprechende Spalte aus der zu importierenden Tabelle ausgewählt werden muss.

Da dieses Attribut, das erste ist, das wir zu der Objektabbildung von Songs angelegt haben, wird es daraufhin automatisch auf den Namen des Objekts abgebildet, da der Name in der Regel das meistgenutzte Attribut ist.

Das erste zu einem Objekt angelegte Attribut wird zudem automatisch zur Identifizierung des Objektes verwendet. 

Ein Objekt muss über mindestens ein Attribut identifiziert werden - sei es über seinen Namen oder seine ID oder eine Kombination aus mehreren Attributen (wie bei Personen aus Vor- und Nachname und dem Geburtsdatum)-, damit es in der semantischen Graph-Datenbank eindeutig wiedergefunden werden kann, sollte es bereits vorhanden sein. So wird das ungewollte Anlegen von Dubletten beim Import vermieden.

Im Reiter "Identifizieren" kann das Attribut, das das Objekt identifiziert noch nachträglich geändert oder mehrere Attribute hinzugefügt werden. Zudem kann hier eingestellt werden, ob die Groß- und Kleinschreibung beim Abgleich der Werte beachtet werden soll und ob nach exakt gleichen Werten gesucht werden soll (ohne Indexfilter/Wildcards). Letzteres ist dann relevant, wenn im Index Filter oder Wildcards definiert sind, die z.B. festlegen, dass ein Bindestrich im Index entfallen soll. Der Begriff würde mit Bindestrich nicht gefunden werden, wenn nur über den Index gesucht wird, also müsste in diesem Fall hier der Haken gesetzt werden, sodass nach dem exakt gleichen Wert gesucht wird.

Jetzt können wir dem Objektmapping weitere Attribute hinzufügen, die nicht zur Identifizierung beitragen müssen, z.B. die Dauer eines Songs - dies geschieht wieder über die Schaltfläche "Neue Attributabbildung". (Achtung: Die Objektabbildung "Objekte von Song" muss zunächst wieder ausgewählt werden.) Jetzt wählen wir die Spalte "Dauer" aus der zu importierenden Tabelle aus. Dieses Mal müssen wir das Attribut, auf das die Spalte "Dauer" abgebildet werden soll, manuell auswählen. In dem Feld rechts unten befindet sich die Lister aller im Schema festgelegten möglichen Attribute, die uns für Objekte des Typs "Song" zur Auswahl stehen, darunter auch das Attribut "Dauer". Relation mapping

Als nächstes wollen wir das Album abbilden, auf dem der Song sich befindet. Da Alben eigene konkrete Objekte in der semantischen Graph-Datenbank sind, benötigen wir hierfür die Relation, die den Song und das Album verbindet. Um eine Relation abzubilden wählen wir zunächst das Objekt aus, für das die Relation definiert wird und klicken dann auf die Schaltfläche "Neue Relationsabbildung".

Daraufhin erhalten wir - wie bei den Attributen - eine Liste aller möglichen Relationen, auch die benötigte Relation "ist enthalten in" ist selbstverständlich dabei.

Nun müssen wir im nächsten Schritt festlegen, wo aus der Tabelle die Zielobjekte herkommen. Für das Ziel wird eine neue Objektabbildung gebraucht, die über die Schaltfläche "Neu" angelegt wird. Ist der Typ des Zielobjektes eindeutig im Schema definiert, wird dieser automatisch übernommen, ansonsten erscheint eine Liste der möglichen Objekttypen.

Bei der neuen Objektabbildung müssen wir anschließend wieder das Attribut auswählen, das das Zielobjekt identifiziert usw. So wird die Zielstruktur des Imports aufgebaut. Type mapping

Auch Typen können importiert und exportiert werden. Nehmen wir beispielhaft an, wir wollten die Genres der Songs als Typen importieren.

Um einen neuen Typen abzubilden, wählen wir den Button "Neue Typabbildung".

Daraufhin müssen wir den Obertyp der neu anzulegenden Typen angeben, in unserem Beispiel wäre der Obertyp "Song":

Anschließend müssen wir angeben, aus welcher Spalte der importierten Tabelle der Name unserer neuen Typen entnommen werden soll:

Schließlich müssen wir unter dem Reiter "Import" noch angeben, dass unsere neuen Typen nicht abstrakt sein sollen:

Wenn wir nun die entsprechenden Songs ihren neuen Typen zuordnen wollen, müssen wir die Systemrelation "hat Objekt" verwenden. In älteren Versionen von k-infinity heißt diese Relation "hat Individuum". Als Ziel wählen wir alle Objekte von Song (inkl. der Untertypen) aus, die sich über das Attribut Name entsprechend der Spalte Songtitel definieren.

Importieren wir nun diese Abbildung erhalten wir das gewünschte Ergebnis. Die Songs, die bereits in der semantischen Graph-Datenbank vorhanden sind, werden durch die Import-Einstellung "Aktualisieren oder neu anlegen wenn noch nicht vorhanden" berücksichtigt und unter ihren neuen entsprechenden Typ geschoben, sodass kein Objekt doppelt angelegt wird (siehe Kapitel Einstellungen des Import-Verhaltens). Zur Erinnerung: Ein konkretes Objekt kann nicht mehreren Typen gleichzeitig angehören.

Es gibt noch einen Spezialfall. Angenommen, wir haben eine Tabelle, in der in einer Spalte verschiedene Typen vorkommen, dann können wir auch dies in unseren Importeinstellungen abbilden.

Dazu wählen wir die Abbildung der Objekte aus, denen wir die Untertypen zuordnen wollen (in diesem Fall "Objekte von Ort") und wählen dann unter dem Reiter "Optionen" den entsprechenden Obertyp aus.

Wichtig ist auch hier wieder nicht zu vergessen, unter dem Reiter "Import" festzulegen, dass der Typ nicht abstrakt sein soll, damit konkrete Objekte angelegt werden können.

Vorsicht: Angenommen, Liverpool existiert bereits im Wissensnetz, ist jedoch dem Typ "Ort" zugeordnet, da dieser bis zu diesem Zeitpunkt noch keine Untertypen wie "Stadt" und "Land" besessen hat. In diesem Fall wird Liverpool nicht unter dem Typ Stadt neu angelegt. Begründung: die Objekte des Typs Ort werden lediglich über das Namensattribut identifiziert, nicht jedoch über den Untertyp. Mapping of extensions

Auch Erweiterungen können importiert und exportiert werden. Angenommen, wir haben eine Tabelle, die die Rolle eines Bandmitglieds in einer Band zeigt:

Ron Wood ist Gitarrist bei den Faces und den Rolling Stones aber Bassist bei der Jeff Beck Group. Um dies abzubilden müssen wir das Objekt auswählen, zu dem im Schema eine Erweiterung definiert wurde und dann den Button "Neue Erweiterungsabbildung" betätigen.

Die Abbildung einer Erweiterung fragt - wie eine Objektabbildung - einen zugehörigen Typen ab. Im Schema des Musik-Netzes ist der Typ "Rolle" ein abstrakter Typ. Deswegen muss in der Abbildung definiert werden, dass die Rolle auf Untertypen des Typs "Rolle" abgebildet weden sollen (siehe Kapitel Die Typabbildung).

Die Relation kann - wie auch bei Objekten und Typen - an der Erweiterung (bzw. an den Untertypen einer Erweiterung) abgebildet werden. Die Skriptabbildung

Die Skriptabbildung kann ausschließlich beim Export verwendet werden. Das Skript kann entweder in JavaScript oder KScript geschrieben sein.

Die Skriptabbildung findet beispielsweise dann Verwendung, wenn wir drei Attribute aus der semantischen Graph-Datenbank zu einer ID zusammensetzen wollen. Allerdings kann es sein, dass der Export dann langsamer ist. (Bei einem Import könnte man dies einfacher über eine virtuelle Eigenschaft abbilden. Die Verwendung von virtuellen Eigenschaften wird im Kapitel Tabellenspalten erklärt.)

Der folgende Fall ist ein weiteres Beispiel für die Verwendung eines Skripts bei einem Export. Es zeigt wie mehrere Eigenschaften mit einem Trennzeichen in eine Zelle geschrieben werden können. In diesem Fall wollen wir eine Tabelle erzeugen, die in der ersten Spalte die Songnamen und in der zweiten Spalte alle Stimmungen der Songs mit Komma getrennt aufführt:

Um die zweite Spalte zu erzeugen benötigen wir folgendes Skript:

function exportValueOf(element)

	var stimmung = "";
	var relTargets = $k.Registry.query("stimmungenZuSongs").findElements({songName: element.attributeValue("objektName")});
	if(relTargets && relTargets.length > 0){
		for(var i = 0; i < (relTargets.length-1); i++){
			stimmung += relTargets[i].attributeValue("objektName") + ", ";
		stimmung += relTargets[relTargets.length-1].attributeValue("objektName"); 
	return stimmung;	

Das Skript beinhaltet folgende Strukturabfrage (Registrierungsschlüssel: "stimmungenZuSongs"):

Über den Ausdruck "findElements" können wir auf einen Parameter (hier "songName") innerhalb der Abfrage zugreifen. "objektName" ist der interne Name des Namensattributs in diesem semantischen Modell.

Innerhalb der if-Anweisung sagen wir, dass wenn ein Element mehrere Relationsziele hat, diese durch ein Komma getrennt dargestellt werden sollen. Nach dem letzten Relationsziel, das die Schleife durchläuft, soll keine Komma mehr stehen. Auch wenn ein Element nur ein Relationsziel hat, wird dies demnach ohne Komma dargestellt.

Das Ergebnis ist eine Liste der Songs mit allen ihren Stimmungen, die durch Komma getrennt in der zweiten Spalte der Tabelle stehen: Abbildung von mehreren Werten fĂĽr einen Objekttyp bei einem Objekt

Wenn für einen Objekttyp bei einem Objekt mehrere Werte angegeben sind (in unserem Beispiel etwa mehrere Moods für jeden Song), dann gibt es drei Möglichkeiten, wie die Tabelle aussehen kann. Für zwei der drei Möglichkeiten muss der Import angepasst werden, was im Folgenden beschrieben ist.

Möglichkeit 1 - Trennzeichengetrennte Werte: Die einzelnen Werte befinden sich in einer Zelle und sind durch ein Trennzeichen (z.B. ein Komma) getrennt.

In diesem Fall gehen wir auf die Abbildung der Datenquelle, wo sich die allgemeinen Einstellungen befinden und dort auf den Reiter "Optionen". Hier finden wir im unteren Bereich die Einstellungsmöglichkeit, Trennzeichen innerhalb einer Zelle anzugeben. Nun müssen wir nur noch die entsprechende Spalte der zu importierenden Tabelle heraussuchen ("Mood") und in die Spalte "Trennzeichen" das verwendete Trennzeichen (",") eingeben.


Möglichkeit 2 - Mehrere Spalten: Die einzelnen Werte befinden sich jeweils in einer eigenen Spalte, wobei nicht jedes Feld ausgefüllt sein muss. Es werden so viele Spalten benötigt, wie maximal Moods pro Song vorhanden sind.

In diesem Fall muss die entsprechende Relation so oft angelegt werden, wie Spalten vorhanden sind. In diesem Beispiel müssen demnach die erste Relation auf "Mood1", die zweite Relation auf "Mood2" und die dritte Relation auf "Mood3" abgebildet werden.


Möglichkeit 3 - Mehrere Zeilen: Die einzelnen Werte befinden sich jeweils in einer eigene Zeile. Achtung: Hierbei ist es zwingend nötig, dass die Attribute, die für die Identifizierung des Objektes benötigt werden (in diesem Fall der Titelname), in jeder Zeile auftreten, ansonsten würden die Zeilen als jeweils eigenes Objekt ohne Name gedeutet werden und ein korrekter Import wäre nicht möglich.

In diesem Fall sind keine besonderen Import-Einstellungen nötig, da das System über das identifizierende Attribut das Objekt erkennt und die Relationen korrekt zieht. Einstellungen des Import-Verhaltens

Beim Import-Vorgang wird immer geprüft, ob ein Attribut bereits vorhanden ist. Das Identifizieren“ schließt von Attributen auf die konkreten Objekte. Wenn wir nun im Folgenden von bereits vorhandenen Attributen sprechen, dann sind das Attribute, die im Wert genau mit dem Wert aus der Spalte, auf die sie abgebildet sind, übereinstimmen. Wenn wir von bereits vorhandenen Objekten sprechen, dann sind das konkrete Objekte, die durch ein bereits vorhandenes Attribut identifiziert werden.

Beispiel: Wenn in unserem Netz bereits ein Song mit dem Namen Eleanor Rigby existiert, dann ist das Namensattribut (abgebildet auf die Spalte Titelname unserer Importtabelle) ein existierendes Attribut und folglich der Song ein existierender Song, solange der Song nur über das Namensattribut identifiziert wird.

Mit den Einstellungen für das Importverhalten können wir steuern, wie der Import auf bereits vorhandene und neue Wissensnetzelemente reagieren soll. Folgende Tabelle zeigt eine Kurzbeschreibung der einzelnen Einstellungen, während die Unterkapitel dieses Kapitels ausführliche und anschauliche Beschreibungen beinhalten.

Einstellung Kurzbeschreibung

Vorhandene Elemente werden überschrieben (aktualisiert), keine neuen Elemente werden angelegt.

Aktualisieren oder neu anlegen wenn nicht vorhanden Vorhandene Elemente werden überschrieben, sollten keine vorhanden sein, werden sie neu angelegt.
Alle mit selbem Wert löschen (nur bei Eigenschaften verfügbar)

Alle Attributwerte, die mit dem importierten Wert übereinstimmen, werden für die jeweils entsprechenden Objekte gelöscht.

Alle vom selben Typ löschen Alle Attributwerte des ausgewählten Typs werden für die entsprechenden Objekte gelöscht, unabhängig davon, ob die Werte übereinstimmen oder nicht.

Wird verwendet, um genau das eine Element zu löschen.

Neu anlegen Legt eine neue Eigenschaft/Objekt an, ohne zu beachten, ob der Attributwert oder das Objekt bereits vorhanden ist.
Neu anlegen wenn noch nicht vorhanden (nur bei Attributen verfügbar) Nur, wenn noch kein Attribut des gewünschten Typs vorhanden ist, wird eines angelegt.
Nicht importieren Kein Import.
Synchronisieren Um die zu importierenden Inhalte mit den Inhalten der Datenbank zu synchronisieren, werden bei dieser Aktion alle Elemente, die noch nicht vorhanden sind, neu angelegt, alle die sich geändert haben, aktualisiert und alle, die nicht mehr vorhanden sind, gelöscht.

Bei einem Import müssen wir uns für jedes abgebildete Objekt, jede abgebildete Relation und jedes abgebildete Attribut einzeln entscheiden, welche Import-Einstellung wir jeweils verwenden wollen. Anders als in anderen Editoren des Knowledge-Buildes "vererbt" sich eine Einstellung nicht an die darunterliegenden Abbildungselemente. Auch die Import-Einstellung für ein Objekt "vererbt" sich nicht an seine Attribute. Aktualisieren

Wird diese Einstellung bei einem Attribut angewendet, sorgt sie dafür, dass der Wert aus der Tabelle den Attributwert genau eines bereits existierenden Attributs überschreibt. Mit dieser Einstellung werden keine neuen Attribute angelegt. Falls das Objekt mehr als einen Attributwert des ausgewählten Typs hat, wird kein Wert importiert.

Verwendet man die Einstellung "Aktualisieren" bei einem identifizierenden Attribut, während man bei dem dazugehörigen Objekt die Einstellung "Aktualisieren oder neu anlegen, wenn nicht vorhanden" verwendet, erscheint die Fehlermeldung "Attribut nicht gefunden", wenn das identifizierende Attribut nicht in k-infinity vorhanden ist.

Wird "Aktualisieren" bei einem Objekt angewendet, sorgt die Einstellung dafür, dass alle Eigenschaften des Objekts durch den Import hinzugefügt, bzw. geändert werden können. Neue Objekte werden nicht angelegt.

Beispiel: Angenommen wir führen eine Datenbank mit unseren Lieblings-Songs. Nun haben wir eine Liste mit Songs, die neue Informationen, enthalten. Wir wollen diese Informationen in unsere Datenbank bringen, gleichzeitig aber nicht, dass Songs importiert werden, die nicht zu unseren Lieblings-Songs gehören. Hierfür verwenden wir die Einstellung "Aktualisieren".

Der Song "About A Girl" ist bereits im Knowledge-Builder vorhanden.

Die Import-Tabelle enthält Angaben zu Dauer, Wertung und Autor des Songs.

Wir legen für Objekte von Song fest, dass sie aktualisiert werden sollen. Alle Attribute, Relationen und Relationsziele erhalten die Import-Einstellung "Aktualisieren oder neu anlegen wenn noch nicht vorhanden".

Das Ergebnis: Der Song wurde aktualisiert und hat nun neue Attribute und Relationen erhalten. Bereits vorhandene Eigenschaften wurden aktualisiert (Wertung). Aktualisieren oder neu anlegen wenn nicht vorhanden

Diese Import-Einstellung wird in den meisten Fällen benötigt und ist darum als Standard-Einstellung gesetzt. Wenn Elemente bereits vorhanden sind, werden sie aktualisiert. Wenn Elemente noch nicht vorhanden sind, werden sie in der Datenbank neu angelegt. Alle mit selben Wert löschen

Diese Import-Einstellung ist nur bei Eigenschaften (Relationen und Attributen) verfügbar und wird nur verwendet, wenn über die Import-Einstellung "Löschen" nicht gelöscht werden kann. Mit "Löschen" kann dann nicht gelöscht werden, wenn eine Relation oder ein Attribut bei einem Objekt mehrmals mit denselben Werten vorkommt. Versucht man es dennoch, erscheint eine Fehlermeldung. Zum Beispiel kann es sein, dass der Song "About A Girl" versehentlich zweimal mit der Band "Nirvana" über die Relation "hat Autor" verknüpft wurde.

In solchen Fällen greift die Import-Einstellung "Löschen" nicht, da sie bei Mehrfachvorkommen nicht weiß, welche der Relationen sie löschen soll. Hier muss also "Alle mit selben Wert löschen" verwendet werden. Alle vom selben Typ löschen

Diese Import-Einstellung wird verwendet, wenn alle Attribute, Objekte oder Relationen eines Typs gelöscht werden sollen, unabhängig von den vorhandenen Werten. Im Gegensatz dazu berücksichtigen die Einstellungen "Löschen" und "Alle mit selben Wert löschen" die vorhandenen Werte. Es werden nur die Elemente der Objekte gelöscht, die in der Import-Tabelle vorkommen.

Beispiel: Wir haben eine Import-Tabelle mit Songs und der Dauer der Songs. Wir sehen, dass sich die Dauer in vielen Fällen unterscheidet und beschließen, die Dauer für diese Songs zu löschen, damit wir keinesfalls falsche Angaben haben.

Die Dauer in der Import-Tabelle unterscheidet sich bei den meisten Songs...


... von der Dauer der Songs in der Datenbank.

Beim Attribut "Dauer" verwenden wir die Import-Einstellung "Alle vom selben Typ löschen".

Nach dem Import, sind alle Attributwerte des Attributtyps Dauer für diese 4 Songs gelöscht. Löschen

Die Import-Einstellung "Löschen" wird verwendet, um genau das eine Objekt / genau die eine Relation / genau den einen Attributwert zu löschen. Falls keine oder mehrere Objekte / Relationen / Attributwerte mit den zu importierenden Elementen übereinstimmen, erscheint diesbezüglich eine Fehlermeldung und die betroffenen Elemente werden nicht gelöscht. Neu anlegen

Diese Import-Einstellung legt eine neue Eigenschaft / ein neues Objekt an, ohne zu beachten, ob der Attributwert oder das Objekt bereits vorhanden ist. Einzige Ausnahme: Sollte eine Eigenschaft nur einmal vorkommen (man beachte die Einstellung "kann mehrfach vorkommen" bei der Attributdefinition), so wird das neue Attribut nicht angelegt und eine Fehlermeldung erscheint, die dies mitteilt. Neu anlegen wenn noch nicht vorhanden

Diese Import-Einstellung ist nur bei Attributen verfügbar. Ein neuer Attributwert wird nur angelegt, wenn das entsprechende Attribut noch keinen Wert hat. Die Werte müssen nicht gleich sein, es geht nur um das Vorhandensein, bzw. Nichtvorhandensein irgendeines Wertes des entsprechenden Attributtyps. Der Import mehrerer Attributwerte gleichzeitig auf einen Attributtyp ist nicht möglich, da hier nicht entschieden werden kann welcher der Attributwerte verwendet werden soll.

Beispiel: Angenommen, wir haben eine Import-Tabelle, die Musiker mit ihren alias-Namen beinhaltet. Einige Musiker haben auch mehrere alias-Namen. Hier können wir die Einstellung "Neu anlegen wenn noch nicht vorhanden" nicht verwenden, da dann alle Musiker mit mehreren alias-Namen keinen erhalten würden. Nicht importieren

Mit der Import-Einstellung "Nicht importieren" können wir sagen, dass ein Objekt oder eine Eigenschaft nicht importiert werden soll. Dies ist dann nützlich, wenn wir bereits eine Abbildung definiert haben und diese wiederverwenden wollen, jedoch bestimmte Objekte und Eigenschaften nicht noch einmal importieren wollen. Synchronisieren

Die Import-Einstellung "Synchronisieren" ist mit Vorsicht zu genießen, denn sie betrifft als einzige Import-Einstellung nicht nur die Objekte und Eigenschaften in k-infinity, die in ihren Werten mit denen der Import-Tabelle übereinstimmen, sondern darüber hinaus alle Elemente des gleichen Typs in k-infinity. Wenn man eine Import-Tabelle mit k-infinity synchronisiert, bedeutet das prinzipiell, dass das Ergebnis in k-infinity nach dem Import exakt so aussehen soll wie in der Tabelle.

Wenn Objekte eines Typs synchronisiert werden, werden alle Objekte dieses Typs gelöscht, die nicht in der Import-Tabelle vorkommen. Die Objekte, die vorkommen, werden aktualisiert und die Objekte, die nicht in k-infinity vorkommen, werden neu angelegt.

Beispiel: Wir wollen die Musikmessen in k-infinity (links) mit einer Tabelle mit den Messen und ihrem Datum (rechts) synchronisieren:

Für die Objekte des Typs Messe wählen wir die Import-Einstellung "Synchronisieren", für die einzelnen Attribute Name und Messedatum wird die Import-Einstellung "Aktualisieren oder neu anlegen, wenn nicht vorhanden" verwendet:

Das Attribut Name ist das identifizierende Attribut von Messe. Für das Objekt Musikmesse 2015 fehlt der Name in der Import-Tabelle. Importieren wir die Tabelle so, erhalten wir dazu eine Fehlermeldung:

Nach dem Import sehen wir nun, dass durch den Import zwei Objekte entfallen sind, die keine Entsprechung in der Import-Tabelle hatten. Das Datum bei Musikmesse 2016 wurde aktualisiert:

Wenn Attribute synchronisiert werden gilt folgendes: Wenn ein bestehendes Attribut durch einen Import keinen Wert erhält, wird es für das entsprechende Objekt der Import-Tabelle gelöscht. Wenn das bestehende Attribut einen anderen Wert hat als in der Import-Tabelle, wird es aktualisiert, auch dann, wenn es mehrmals vorkommen darf. Wenn das Attribut noch nicht vorhanden ist, wird es neu angelegt.

Wenn Relationen synchronisiert werden, und sie erhalten keinen Wert werden sie für das entsprechende Objekt gelöscht. Wenn die bestehende Relation einen anderen Wert hat, als in der Import-Tabelle, wird sie aktualisiert. Sollte es das Zielobjekt noch nicht in der Datenbank geben, wird es neu angelegt, vorausgesetzt, das Zielobjekt hat eine entsprechende Import-Einstellung zugewiesen bekommen. Kann das Zielobjekt nicht neu angelegt werden, da hier beispielsweise die Import-Einstellung "Aktualisieren" zugewiesen wurde erscheint eine Fehlermeldung, die uns mitteilt, dass das Zielobjekt nicht gefunden wurde und es wird nicht neu angelegt.

5.1.2 Tabellenspalten

Bei Abbildungen von Datenbank-Queries sind die Spalten, die zum Import zur Verfügung stehen, durch die Datenbanktabellen bzw. durch das Select-Statement vorgegeben. Beim Abbilden von Dateien können die Spalten mit der Schaltfläche "Aus Datenquelle lesen" aus der Datei übernommen werden. Man kann sie aber auch von Hand angeben. Dann hat man die Wahl, ob man eine Standard-Spalte oder eine virtuelle Eigenschaft anlegen möchte.

Will man aus der semantischen Graph-Datenbank exportieren, muss man die Spalten von Hand eingeben. Es können nur Standard-Spalten, nicht jedoch virtuelle Spalten exportiert werden.

Virtuelle Tabellenspalte / Virtuelle Eigenschaft
Virtuelle Spalten sind zusätzliche Spalten, die es erlauben die Inhalte, die wir in einer Spalte der zu importierenden Tabelle vorfinden, mit regulären Ausdrücken zu transformieren. Beispiel: Nehmen wir an in unserer Import-Tabelle steht bei den Jahreszahlen immer ein a.d. dahinter. Das können wir bereinigen, indem wir eine virtuelle Spalte anlegen, die aus der Spalte Jahr nur die ersten 4 Zeichen übernimmt.

Auch beim Export können wir virtuelle Eigenschaften definieren.

Den reguläre Ausdruck schreiben wir dabei einfach in die Spaltenüberschrift (in den Namen der Spalte). Dabei werden Teilzeichenketten, die in spitze Klammern <...> eingeschlossen sind, nach den folgenden Regeln ersetzt, wobei n, n1, n2, ... für die Inhalte anderer Tabellenspalten stehen.

Ausdruck Beschreibung Beispiel Eingabe Ausgabe
<np> Druckausgabe des Inhalts von Spalte n

Treffer: <1p>


1 (integer)



Treffer: 1



Treffer: 'keine'

<ns> Ausgabe der Zeichenkette in Spalte n Hallo <1s>! 'Peter' Hallo Peter!
<nu> Ausgabe der Zeichenkette in Spalte n in Großbuchstaben Hallo <1u>! 'Peter' Hallo PETER!
<nl> Ausgabe der Zeichenkette in Spalte n in Kleinbuchstaben Hallo <1l>! 'Peter' Hallo peter!
<ncstart-stop> Teilzeichenkette von Position start bis stop aus Spalte n












<nmregex> Test, ob der Inhalt von Spalte n den regulären Ausdruck regex matcht. Die folgenden Ausdrücke werden nur ausgewertet, wenn der reguläre Ausdruck zutrifft.




















<nxregex> Test, ob der Inhalt von Spalte n den regulären Ausdruck regex matcht. Die folgenden Ausdrücke werden nur ausgewertet, wenn der reguläre Ausdruck nicht zutrifft. <1x0[0-9]>hallo










<neregex> Selektiert alle Treffer von regex aus dem Inhalt von Spalte n. Einzeltreffer sind im Ergebnis durch Komma voneinander getrennt.













<nrregex> Entfernt alle Treffer von regex aus dem Inhalt von Spalte n <1rL> HELLO WORLD HEO WORD
<ngregex> Überträgt den Inhalt aller Gruppen des regulären Ausdrucks <1g\+(\d+)\-> +42-13 42
<nfformat> Formatiert Zahlen, Datums- und Zeitangaben aus Spalte n gemäß der Formatangabe 'format'













1. Mai 1935


1. Mai 1935    










Angenommen wir haben eine Import-Tabelle, in der konkrete Objekte ohne Namen vorkommen. In unserem Datenmodell sollen diese Objekte jedoch als eigene Objekte modelliert werden. Ein Beispiel: zu einem Lastpunkt steht in Spalte 88 sein Hauptwert, der Drehmoment. Als Definition unserer virtuellen Spalte, die für den Namen dieses Lastpunktes stehen soll, geben wir also den Ausdruck Lastpunkt <88s> ein. Der daraus entstehende Name für einen Lastpunkt mit dem Drehmoment von 850 wäre demnach "Lastpunkt 850".

Wir können die virtuelle Eigenschaft auch nutzen, um einen Usernamen herzustellen, der aus den ersten 4 Buchstaben des Vornamens und des Nachnamens zusammengesetzt ist. Heißt die Person Maximilian Mustermann und wir definieren die virtuelle Spalte mit dem entsprechenden Ausdruck <1c1-4><2c1-4>, erhalten wir das Ergebnis "MaxiMust".

Die virtuelle Eigenschaft kann auch dazu genutzt werden, einem User beim Import ein initiales Passwort anzulegen. Der Ausdruck könnte Pass4<2s> lauten. Das daraus resultierende Passwort für Maximilian Mustermann wäre "Pass4Mustermann".

Ein etwas umfangreicheres Beispiel zeigt, wie die virtuelle Eigenschaft dazu genutzt werden kann, Objekten die korrekte direkte Obergruppe zuzuordnen:

Die drei rechten Spalten sind virtuelle Spalten.

<1mUG>: In die erste der virtuellen Spalten wird die Nummer der Obergruppe des Objekts nur geschrieben, wenn der Begriff "UG" (für Untergruppe) in der ersten Spalte für das Objekt vorkommt.

<2c1-3>000: Die Nummer die in die Spalte geschrieben werden soll, setzt sich aus den ersten drei Zeichen der zweiten Spalte zusammen und drei Nullen.

<1m>: Nur wenn die erste Spalte für das Objekt leer ist, also keinen Wert enthält, wird die Nummer der Obergruppe des Objekts in die Spalte geschrieben.

<2c1-4>00: Die Nummer, die in die Spalte geschrieben werden soll, setzt sich aus den ersten vier Zeichen der zweiten Spalte zusammen.

Heimtextil 2016: Dieser Ausdruck wird für alle Objekte in die Spalte geschrieben.

5.1.3 Configuration of further table-oriented data sources


In einem Mapping für eine PostgreSQL-, Oracle- oder ODBC-Schnittstelle müssen die Datenbank, der Benutzer und das Passwort angegeben werden.

Angabe der Datenbank

Die Angabe für die Datenbank setzt sich aus Name des Host, dem Port und dem Namen der Datenbank zusammen. Die Syntax lautet.


Benutzername und Passwort konfigurieren

Benutzername und Passwort werden so angegeben, wie sie in der Datenbank abgelegt sind. Unter dem Punkt Tabelle kann die Tabelle angegeben werden, die importiert werden soll. Für den Import besteht aber auch die Möglichkeit, dass unter dem Punkt "Query" eine Query formuliert wird, die angibt, welche Daten importiert werden sollen.


Handelt es sich um ein PostgreSQL-Mapping, dann kann auf dem Reiter "Encoding" das Encoding angegeben werden.

Spezielle Anforderungen der Oracle-Schnittstelle

Die Funktion zum direkten Import aus einer Oracle Datenbank setzt voraus, dass auf dem importierenden Rechner bestimmte Laufzeit-Bibliotheken installiert sind.

Direkt benötigt wird das "Oracle Call Interface" (OCI) und zwar in einer Version, die laut Oracle zu dem Datenbankserver passt, der angesprochen werden soll. D.h., um eine Oracle 11i Datenbank anzusprechen, sollte auf dem importierenden Rechner das OCI in Version 11 installiert sein. Das OCI lässt sich am einfachsten installieren, wenn man den "Oracle Database Instant Client" installiert. Die Package Version "Basic" ist ausreichend. Der Client ist entweder vom Serverbetreiber zu bekommen oder von Oracle nach Registrierung unter http://www.oracle.com/technology/tech/oci/index.html ladbar.

Nach der Installation ist sicher zu stellen, dass die Bibliothek für den importierenden Client auffindbar ist, entweder indem sie im gleichen Verzeichnis liegt oder für das entsprechende Betriebssystem passende Umgebungsvariablen definiert werden (ist beim OCI dokumentiert).

Je nach Betriebssystem auf dem der Import stattfinden soll, sind weitere Bibliotheken notwendig, die nicht immer installiert sind.

  • MS Windows: neben der benötigten "oci.dll" sind noch zwei weitere Bibliotheken notwendig: advapi32.dll (Erweitertes Windows 32 Base-API) und mscvr71.dll (Microsoft C Runtime Library)

Bis auf den XML-Import/Export sind alle Importe/Exporte tabellenorientiert und unterscheiden sich nur in der Konfiguration der Quelle. Für die Beschreibung einer tabellenorientierten Abbildung kann das Beispiel der CSV-Datei herangezogen werden.

5.1.4 Mapping of a XML file

Das Prinzip von XML-Dateien ist, die unterschiedlichen Angaben zu einem Datensatz über Tags (<>) explizit zu machen (nicht über Tabellenspalten). Dementsprechend sind Tags auch die Grundlage der Abbildung beim Import von XML-Strukturen in k-infinity.

Ein Beispiel: Nehmen wir an, unsere Liste von Songs liegt als XML-Datei vor:

<?xml version="1.0" encoding="ISO-8859-1"?>
    <Album type="Oldie">
        <Song nr="1">
            <Title>Eleanor Rigby</Title>
            <Interpret>The Beatles</Interpret>
            <Thema>Mental illness</Thema>

Wenn wir nun diese XML-Datei importieren wollen, wählen wir bei der Auswahl des Typs der Datenquelle "XML-Datei" aus, wodurch sich der Editor für den Im- und Export von XML-Dateien öffnet. Bereits in der Angabe des Dateistandortes gibt es Unterschiede zum Editor für CSV-Dateien. Wir können nun zwischen einem lokalen Dateipfad und der Angabe einer URI wählen.

JSON preprocessing ermöglicht das Umwandeln einer JSON-Datei in XML vor dem eigentlichen Import.

Mit XSTL transformieren kann man auswählen, wenn man die XML-Daten aus der ausgewählten XML-Datei noch vor dem Import in andere XML-Daten umwandeln möchte, um beispielsweise die Struktur zu ändern oder einzelne Werte weiter aufzutrennen. Über die Schaltfläche "Bearbeiten" öffnet sich die XML-Datei, in der man die Änderungen mittels XSLT definieren kann.

Ist die Datei ausgewählt, können wir mit dem Button "Aus Datenquelle lesen" die XML-Struktur auslesen lassen, die uns daraufhin in rechten Fenster angezeigt wird.

Wir wollen die einzelnen Songs unserer Liste importieren. Darum legen wir eine neue Objektabbildung an und wählen über den Button bei "Abbilden auf" den Tag <Song> aus. Im Gegensatz zum CSV-Import, bei dem nur Attributwerte eine Entsprechung in der CSV-Tabelle finden und eine einzelne Zeile für ein Objekt steht, sodass auch nur die Attributwerte abgebildet werden müssen, erfolgt das Mapping der semantischen Objekte hier über die XML-Struktur. Darum müssen auch für alle abzubildenden Objekte jeweils ein entsprechendes Tag der XML-Datei angegeben werden.

Wie in unserem Beispiel, sind die Tags ohne Kontext nicht immer eindeutig: <Title> wird sowohl für Titel von Alben als auch für Songtitel verwendet. Erst in Kombination mit dem umgebenden Tag wird der Objekttyp klar. Oft laufen der Kontext der XML-Struktur und der Kontext der Abbildungshierarchie synchron: Da wir nun bereits festgelegt haben, dass die Objekte auf den Tag <Song> abgebildet werden sollen, ist durch die XML-Struktur klar, welcher <Title>-Tag nun gemeint ist, wenn wir <Title> mit dem Namensattribut von Songs mappen. Dort, wo Abbildungshierarchie und Tagstruktur nicht parallel laufen, können wir im XML-Import zusätzlich zu den in der XML-Datei vorkommenden Tags Ketten bilden - mit XPath.

Wie auch beim CSV-Import muss über den Reiter "Identifizieren" bei der Objektabbildung festgelegt werden, durch welche Attributwerte das Objekt in der semantischen Graph-Datenbank identifiziert werden soll. Das erste angelegte Attribut für ein Objekt wird auch hier wieder automatisch als identifizierendes Attribut verwendet.

Möglichkeiten mit XPath-Ausdrücken

Angenommen wir würden nur Songs aus Alben des Musik-Stils "Oldie" importieren wollen. In unserem XML-Dokument ist die Information über den Musik-Stil direkt im Album-Tag angegeben unter type="...". Im Editor müssen wir also einen XPath-Ausdruck definieren, der den Pfad im XML-Dokument beschreibt, der nur diejenigen Songs enthält, die aus Oldie-Alben stammen. Im rechten unteren Bereich des Editors finden wir ein Feld zum hinzufügen von XPath-Ausdrücken.

Der passende XPath-Ausdruck lautet:


Erklärung im Einzelnen: 

//AlbumSelektiert alle Alben, wobei es keine Rolle spielt, wo sie sich im Dokument befinden.
Album[@type="Oldie"]Selektiert alle Alben vom Typ "Oldie"
Album/SongSelektiert alle Songs, die Subelemente von Alben sind.

Diesen Ausdruck können wir nun verwenden, um eine Entsprechung für die Objektabbildung der Songs zu definieren.

Mit XPath stehen uns außerdem viele weitere nützliche Selektions-Funktionen zur Verfügung. So können wir beispielsweise Elemente über ihre Position im Dokument selektieren, Vergleichsoperatoren einsetzen, sowie alternative Pfade angeben.

5.1.5 Weitere Optionen, Log und Registratur Weitere Optionen beim Import

Im Reiter "Optionen" stehen uns folgende Funktionen zur Auswahl, die unabhängig von der Datenquelle sind:

In einer Transaktion importieren: Ist langsamer als ein Import mit mehreren Transaktionen und sollte darum nur dann verwendet werden, wenn es beim Import mit mehreren Transaktionen ansonsten zum Konfliktfall kommen kann, wenn viele Personen zur selben Zeit im Knowledge-Builder arbeiten oder wenn man Daten importieren will, bei denen es eine Rolle spielt, dass sie nicht getrennt voneinander betrachtet werden. Beispiel 1: Es erfolgt stündlich ein Import mit dem Status der Auslastung von Maschinen. Die addierten Werte der Auslastung dürfen einen gewissen Wert nicht übersteigen, da es ansonsten eventuell zum Stromausfall kommen kann. Damit diese Regel (z.B. mithilfe eines Skripts) berücksichtigt werden kann, müssen alle Werte gemeinsam betrachtet und dann importiert werden. Beispiel 2: Es erfolgt ein Import mit Personen, von denen höchstens eine den Hauptschlüssel haben kann, weil nur ein Hauptschlüssel existiert. Auch hier muss der Import in einer Transaktion erfolgen, da bei mehreren Transaktionen der Fehler übersehen werden könnte, dass bei zwei Personen das Attribut für den Hauptschlüsselbesitz gesetzt wurde.

Mehrere Transaktionen verwenden: Standardeinstellung für einen schnellen Import.

Journaling: Das Journaling sollte verwendet werden, wenn extrem viele Daten mit einem Import gelöscht oder geändert werden. Erst nach jeweils 4.096 Einträgen (die Zahl ist variabel), sollen die Änderungen, bzw. Löschungen für diese Einträge auch am Index vorgenommen werden. Dadurch wird der Import beschleunigt, da nicht für jede einzelne Änderung/Löschung der Index herangezogen werden muss, sondern spätestens nach 4.096 Veränderungen diese gemeinsam in den Index übernommen werden.

Metriken aktualisieren: Die Metriken sollten aktualisiert werden, wenn der Import eine große Auswirkung auf die Menge von Objekttypen oder Eigenschaftstypen hat, wenn also sehr viele Objekte oder Eigenschaften eines Typs der semantischen Graph-Datenbank hinzugefügt werden. Würden die Metriken nicht aktualisiert, könnte dies negative Auswirkungen auf die Performance von Suchen haben, in denen die entsprechenden Typen eine Rolle spielen.

Trigger aktiviert: Ob Trigger beim Import aktiviert sein sollen oder nicht kann hier über das Häkchen bestimmt werden. Falls es gewünscht ist, dass ein Trigger greift und ein anderer nicht, müssen zwei verschiedene Abbildungen mit den entsprechenden semantischen Elementen definiert werden. Informationen zu Triggern stehen im Kapitel Trigger zur Verfügung.

Automatische Namensgenerierung für namenlose Objekte: Ermöglicht die automatische Namensgenerierung für namenlose Objekte.


Liegt eine tabellenorientierte Quelle vor, können wir folgende Einstellungen vornehmen:

Komplette Tabelle einlesen: Obwohl es länger dauern kann, die komplette Tabelle auf einmal einzulesen, macht es Sinn diese Option auszuwählen, wenn Vorwärtsreferenzen vorhanden sind, d.h., wenn Relationen zwischen den zu importierenden Objekten gezogen werden sollen. In diesem Fall müssen nämlich beide Objekte bereits vorhanden sein, was beim zeilenweisen Einlesen der Tabelle nicht der Fall ist. Zudem ist die Fortschrittsanzeige genauer als beim zeilenweisen Einlesen.

Tabelle zeilenweise einlesen: Das zeilenweise Einlesen der Tabelle sollte immer dann verwendet werden, wenn keine Querreferenzen in der Tabelle vorhanden sind, da der Import so schneller geht.

Trennzeichen innerhalb einer Zelle: siehe Kapitel Abbildungen von mehreren Werten für einen Objekttyp bei einem Objekt.


Liegt eine XML-basierte Datenquelle vor, stehen uns folgende Funktionen zur Verfügung:

Inkrementeller XML-Import: Der XML-Import erfolgt schrittweise. Die Schritte werden durch das partitionierende Element festgelegt.

DTD einlesen: Liest die Dokumenttypdefinition (DTD) ein. Log

Die Funktionen im Reiter "Log" ermöglichen Änderungen, die beim Import vorgenommen werden, verfolgen zu können.

Erzeugte Wissensnetzelemente in einen Ordner stellen: Werden neue Objekte, Typen oder Eigenschaften durch den Import erzeugt, können diese in einen Ordner in der semantischen Graph-Datenbank gestellt werden.

Veränderte Wissensnetzelemente in einen Ordner stellen: Alle Eigenschaften oder Objekte, deren Eigenschaften sich durch den Import geändert haben, können in einen Ordner gestellt werden.

Fehlermeldungen in eine Datei schreiben: Beim Import können Fehler auftreten (z.B. kann es sein, dass ein identifizierendes Attribut für mehrere Objekte vorkam und daher das Objekt nicht eindeutig identifiziert werden konnte). Diese Fehler werden standardmäßig nach einem Import in einem Fenster angezeigt und man hat dann die Möglichkeit den Fehlerbericht zu speichern. Wenn dies automatisch passieren soll, kann hier der Haken gesetzt und eine Datei angegeben werden.

Letzter Import / Letzter Export: Hier werden das Datum und die Uhrzeit des zuletzt vorgenommen Imports und des zuletzt vorgenommen Export angezeigt.

Auch bei den einzelnen Abbildungs-Objekten ist der Reiter "Log" verfügbar. Hier kann bei Bedarf eine Kategorie für Logeinträge eingetragen werden. Zudem kann festgelegt werden, dass der Wert des entsprechenden Objekts / der entsprechenden Eigenschaft in den Fehlerlog geschrieben werden soll. Dies ist standardmäßig nicht aktiviert, um das Offenlegen sensibler Daten (z.B. Passwörter) zu vermeiden. Registratur

Unter dem Reiter "Registratur" findet man die Funktion "Registrierungsschlüssel setzen" mit der man die Datenquelle für andere Importe und Exporte registrieren kann.

Die Funktion "Bestehende Quelle verknüpfen" ermöglicht die Wiederverwendung einer registrierten Quelle.

Unter "Verwendungen" kann man einsehen, wo eine Datenquelle noch verwendet wird:

5.2 Attribute types and formats

Eine häufig auftretende Aufgabe einer Attributabbildung ist der Import bestimmter Daten von konkreten Objekten, beispielsweise von Personen: Telefonnummer, Geburtsdatum etc.

Beim Import von Attributen, für die k-infinity ein bestimmtes Format verwendet (z.B. Datum), müssen die Einträge der zu importierenden Spalte in einer Form vorliegen, die von k-infinity unterstützt wird. Beispielsweise kann in ein Attributfeld vom Typ Datum keine Zeichenkette der Form abcde... importiert werden; in einem solchen Fall wird für das entsprechende Objekt kein Wert importiert.

Die folgende Tabelle listet die von k-infinity unterstützten Formate beim Import von Attributen auf. Ein Tabellenwert ja oder 1 wird also beispielsweise korrekt als boolescher Attributwert (bei einem entsprechend definierten Attribut) importiert, ein Wert wie ein oder ähnliches hingegen nicht.

Attribut Unterstützte Werte-Formate
Auswahl Die Abbildung der Import- auf die Attributwerte kann über den Reiter "Wertzuweisung" konfiguriert werden.
Boolesch Die Abbildung der Import- auf die Attributwerte kann über den Reiter "Wertzuweisung" konfiguriert werden.
Datei Import nicht möglich.
  • <day> <monthName> <year>, z. B. 5 April 1982, 5-APR-1982
  • <monthName> <day> <year>, z. B. April 5, 1982
  • <monthNumber> <day> <year>, z. B. 4/5/1982
Das Trennzeichen zwischen <day>, <monthName> und <year> kann z.B. ein Leerzeichen, ein Komma oder ein Bindestrich sein (es sind aber noch weitere Zeichen möglich). Gültige Monatsnamen sind:
  • 'Januar', 'Februar', 'März', 'April', 'Mai', 'Juni', 'Juli', 'August', 'September', 'Oktober', 'November', 'Dezember'
  • 'Jan', 'Feb', 'Mrz', 'Mär', 'Apr', 'Mai', 'Jun', 'Jul', 'Aug', 'Sep', 'Okt', 'Nov', 'Dez'.

Achtung: Zweistellige Jahreszahlen xy werden zu 20xy expandiert (aus 4/5/82 wird also 4/5/2082).

Wenn das Mapping auf "Frei definierbares Format" eingestellt ist, können folgende Tokens verwendet werden: YYYY und YY (Jahr), MM und M (Monatsnummer), MMMM (Monatsname), MMM (abgekürzter Monatsname), DD und D (Tag)

Datum und Uhrzeit Für Datum und Uhrzeit siehe die jeweiligen Attribute. Das Datum muss vor der Uhrzeit stehen. Wenn die Uhrzeit weggelassen wird, wird 0:00 verwendet.
Farbe Import nicht möglich.
Festkommazahl Import möglich.
  • Ganzzahlen beliebiger Größe
  • Fließkommazahlen (mit Punkt getrennt), z.B. 1.82. Die Zahlen werden beim Import gerundet.
Internet-Verknüpfung Jede beliebige URL möglich.

<hour>: <minute>: <second> <am/pm>, z.B. 8:23 pm (wird zu 20:23:00) <minute>, <second> und <am/pm> können weggelassen werden.

Wenn das Mapping auf "Frei definiertes Format" eingestellt ist, könne folgende Tokens verwendet werden: hh und  h (Stunde), mm und m (Minute), ss und s (Sekunde), mmm (Millisekunde)

Zeichenkette Jede beliebige Zeichenkette. Es wird keine Dekodierung vorgenommen.


Boolesche Attribute und Auswahlattribute

Auswahl- oder boolesche Attribute können nur Werte aus einer vorgegebenen Menge annehmen; bei Auswahlattributen ist dies eine vorgegebene Liste, bei booleschen Attributen das Wertepaar ja/nein in Form eines Klickfelds. Beim Import dieser Attribute kann angegeben werden, wie die Werte aus der Import-Tabelle in Attributwerte der semantischen Graph-Datenbank übersetzt werden. Zum einen können die Werte so, wie sie in der Tabelle stehen, übernommen werden; entsprechen sie keiner der in der semantischen Graph-Datenbank definierten möglichen Werte des Attributs, werden sie nicht importiert. Zum anderen können Wertzuweisungen zwischen Tabellenwerten und Attributwerten, die dann importiert werden, festgelegt werden.

5.3 Export Configration

Der Export von Daten aus einer semantischen Graph-Datenbank in eine Tabelle wird in demselben Editor wie der Import und ganz analog vorbereitet:

  1. Im einem Tabellen-Mapping-Ordner im Hauptfenster wird ein neues Mapping angelegt.
  2. Im Tabellen-Mapping-Editor wird die zu erzeugende Datei angegeben.

Der Unterschied zum Import liegt darin, dass die Spalten jetzt nicht aus der Tabelle eingelesen werden, sondern im Tabellen-Mapping-Editor angelegt werden müssen. Da der Import- und der Export-Editor derselbe sind, muss man beim Anlegen einer neuen Spalte zunächst auswählen, ob es sich um eine Standard-Spalte oder eine Virtuelle Eigenschaft handelt. Virtuelle Eigenschaften sind bei einem Export jedoch nicht verwendbar.


Export von Strukturabfragen

Es besteht die Möglichkeit das Ergebnis einer Strukturabfrage zu exportieren. Diese Vorgehensweise bietet sich an, wenn nur bestimmte Objekte, die durch eine Suche eingeschränkt werden, exportiert werden sollen. Nehmen wir als Beispiel an, wir wollten alle Bands, die Songs geschrieben haben, die länger als 10 min. dauern, exportieren. Dafür müssen wir zunächst eine Strukturabfrage definieren, die die gewünschten Objekte zusammenstellt.

Auf diese Strukturabfrage greifen wir dann von der Konfiguration des Exports aus zu. Dazu wählen wir im Kopf der Mapping-Konfiguration anstelle einer Objekt-Abbildung die Abbildung einer Abfrage. Die Strukturabfrage benötigt einen Registrierungsschlüssel, um auf sie zugreifen zu können.

Damit werden nur noch die Ergebnisse der Strukturabfrage exportiert. Für diese Objekte können wir jetzt wieder Eigenschaften angeben, die in den Export mit aufgenommen werden sollen: z.B. Gründungsjahr der Band, Mitglieder und Songs. Jetzt kann es aber vorkommen, das wir von den Bands, die wir so zusammengestellt haben, nicht alle Songs exportieren wollen, sondern gerade nur die, die auch dem Suchkriterium entsprechen, in unserem Beispiel die Songs über 10 min. Dazu können wir die einzelnen Suchbedingungen in der Strukturabfrage mit Bezeichnern belegen. Diese Bezeichner können dann wiederum in der Export-Definition angesprochen werden.


Export von Sammlungen semantischer Objekte

Auch Sammlungen semantischer Objekte können exportiert werden. Diese brauchen ebenfalls einen Registrierungsschlüssel, den man unter TECHNIK -> Strukturordner setzen kann.


Export der Frame-ID

Die Abbildung der Frame-ID ermöglicht es uns, die in der semantischen Graph-Datenbank für ein Wissensnetzelement vergebene ID, zu exportieren. Hierzu wählen wir einfach das Objekt, den Typ oder die Eigenschaft aus, für die wir die ID brauchen und wählen dann den Button "Neue Abbildung der Frame-ID":

Wir können außerdem entscheiden, ob wir die ID im Format eines Strings wollen (ID123_456) oder, ob wir sie als 64 Bit Integer ausgegeben haben wollen.


Export mithilfe von Skripten

Schließlich steht uns beim Export noch ein weiteres mächtiges Werkzeug zur Verfügung: die Skriptabbildung. Informationen hierzu sind im Kapitel Die Skriptabbildung verfügbar.


Export-Aktionen bei Datenbankexporten

Die Abbildung der Eigenschaften eines Objekts wird für einen Export in eine Datenbank genauso vorgenommen wie für einen Import und wie für alle anderen Mappings. Einzig ist für den Export die Export-Aktion zu bestimmen. Diese gibt an, welche Art von Query in der Datenbank ausgeführt werden soll. Es stehen drei Export-Aktionen zur Verfügung:

Folgende Aktionen stehen in dem sich öffnenden Auswahldialog zur Verfügung:

  • Datensätze in Tabelle neu anlegen: Es werden neue Datensätze in der Datenbanktabelle hinzugefügt. Diese Aktion entspricht einem INSERT.
  • Existierende Datensätze aktualisieren: Die Datensätze werden über eine ID in der Tabelle identifiziert. Sie werden nur überschrieben, wenn der Wert sich geändert hat. Gibt es keinen passenden Datensatz, dann wird ein neuer hinzugefügt. Diese Aktion entspricht einem UPDATE.
  • Tabelleninhalt beim Export überschreiben: Alle Datensätze werden erst gelöscht und dann neu geschrieben. Diese Aktion entspricht einem DELETE auf der ganzen Tabelle mit folgendem INSERT.

5.4 RDF import and export

RDF ist ein Standardformat für semantische Datenmodelle. Mit dem RDF-Import und -Export können wir die Daten der semantischen Graph-Datenbank mit anderen Anwendungen austauschen, aber auch Daten von einem k-infinity-Wissensnetz in ein anderes transportieren.

Beim RDF-Export wird das gesamte Wissensnetz in eine RDF-Datei ausgeleitet. Der RDF-Import dagegen ist interaktiv und selektiv. D.h. wir können sowohl auf Schema-Ebene als auch bei den einzelnen Objekten und Eigenschaften angeben, was importiert werden soll und was nicht.


Abgleich der Objekte aus RDF mit den existierenden Objekten im semantischen Netz

Wenn die RDF-Daten aus demselben Schema stammen, wie das Netz in das sie importiert werden - z.B. aus einer Sicherungskopie - dann ordnet der RDF-Import Objekte und Objekttypen automatisch anhand ihrer ID zu. In den Import-Einstellungen können wir wie bei den Tabellen- und XML-Importen nun bestimmen z.B. existierende Objekte durch den Import aktualisiert werden sollen, ob neue angelegt werden etc.

Wenn die Daten aus einer anderen Quelle kommen, ist die Default-Einstellung der Import in ein eigenes Subnetz. Wir können aber auch diese externen Informationen in unseren Bestand integrieren - durch manuelle Zuordnungen mit der Abbilden-auf-Funktion im Mapping-Interface.

Daneben gibt es einige globale Einstellungen: Möchten wir überhaupt Änderungen am Schema erlauben? Erlauben wir es, dass Eigenschaften mehrfach angelegt werden? Schließlich werden alle Schema-Änderungen auf einem separaten Reiter angezeigt.

6 Access rights and triggers

In diesem Abschnitt wird die Prüfung von Zugriffsrechten und Trigger behandelt:

  • Zugriffsrechte regeln, welche Operationen am semantischen Modell bestimmte Nutzergruppen durchführen dürfen. Sie werden in k-infinity im Rechtesystem definiert. Das Rechtesystem befindet sich im Bereich Technik > Rechte.
  • Trigger sind automatische Operationen, die bei einem bestimmten Ereignis ausgelöst werden und die zugehörigen Aktionen ausführen. Der Bereich Trigger befindet sich unter Technik > Trigger

Das Rechtesystem und Trigger sind in einer neu angelegten semantischen Graph-Datenbank initial noch nicht aktiviert. Diese Bereiche müssen erst aktiviert werden, bevor sie eingesetzt werden können.

Bei der Erstellung von Rechten und Triggern ist die grundsätzliche Vorgehensweise identisch: Es werden Filter benötigt, die prüfen ob bestimmte Bedingen erfüllt sind oder nicht. Sind diese Bedingen erfüllt, wird beim Rechtesystem ein Zugriffsrecht oder -verbot erteilt sowie bei Triggern ein Log eingetragen oder ein Script ausgeführt. Im Rechtesystem wird die Anordnung der Filter als Rechtebaum und bei Triggern als Triggerbaum bezeichnet.

6.1 Testing Access Rights

Mit Rechten regeln wir den Zugriff von Nutzern auf die Daten im semantischen Netz. Die zwei grundsätzlichen Ziele, deren Erreichung mit dem sogenannten Rechtesystem ermöglicht werden, sind:

  • Schutz von sensiblen Daten: Es werden Nutzern oder Nutzergruppen, nur die Daten angezeigt, die sie auch lesen dürfen. Damit werden Geheimhaltungs- und Vertraulichkeitsbeschränkungen gewährleistet.
  • Arbeitsspezifische Übersicht: Bestimmte Nutzer benötigen für ihre Arbeit mit dem System häufig nur einen Ausschnitt der Daten des Modells. Mit Hilfe des Rechtesystems ist es möglich ihnen nur die Elemente anzuzeigen, die sie für das Erledigen ihrer Aufgaben brauchen.

Das Rechtesystem von k-infinity zeichnet sich durch einen hohen Grad an Flexibilität aus. Es kann auf verschiedene Erfordernisse eines Projektes zielgenau konfiguriert werden. Durch die Definition von Regeln im Rechtebaum bestehend aus einzelnen Filtern und Entscheidern, entsteht ein netzspezifische Konfiguration des Rechtesystems. Es gibt vielfältige Möglichkeiten diese Regeln für das Rechtesystem zusammenzusetzen, wodurch hoch differenzierte Rechte erzeugt werden. Es ist nicht möglich, alle möglichen Kombinationen von Konfigurationen aufzulisten; hier muss eine Beratung für den Einzelfall stattfinden.

Wie funktioniert das Rechtesystem?

Zugriffsrechte im System werden immer dann geprüft, wenn durch einen Nutzer eine Operation auf die Daten vorgenommen wird. Die grundsätzlichen Operationen sind:

  • Lesen: Ein Element soll angezeigt werden.
  • Modifizieren: Ein Element soll geändert werden.
  • Erzeugen: Ein neues Element soll erstellt werden.
  • Löschen: Ein Element soll gelöscht werden.

Soll in einer bestimmten Zugriffssituation das Zugriffsrecht geprüft werden, wird der Rechtebaum abgearbeitet, bis eine Entscheidung für oder gegen den Zugriff in dieser Situation getroffen werden kann. Der Rechtebaum besteht aus Bedingungen, gegen die die Zugriffsituation geprüft wird. Um die Bedingungen zu prüfen, werden Filter verwendet, die Elemente des Wissensnetzes und Operationen filtern. Am Ende eines Teilbaumes aus Filtern im Rechtebaum befinden sich die Entscheider. Von diesen wird der Zugriff entweder erlaubt oder abgewiesen.

In Bezug auf die Zugriffssituation werden Aspekte ausgewählt, die als Bedingung für die Erlaubnis oder das Verbot des Zugriffes eingesetzt werden. In Zugriffssituationen werden häufig folgende Aspekte für die Entscheidung herangezogen:

  • die Operation (Erzeugen, Lesen, Löschen oder Modifizieren)
  • das Element, auf das zugegriffen werden soll
  • der aktuelle Nutzer

Es kann sein, dass nur ein Aspekt der Zugriffsituation als Bedingung ausgewählt wird, aber es kann auch eine Kombination der aufgeführten Aspekte abgefragt werden. Beispiel: "Paul [Nutzer] darf keine Beschreibungen [Element] löschen [Operation]".

6.1.1 Activation of the Access Right System

In einem neu angelegten Wissensnetz ist das Rechtesystem standardmäßig deaktiviert. Damit es genutzt werden kann, muss es in den Einstellungen des Knowledge-Builders aktiviert werden.

Anleitung für die Aktivierung des Rechtesystems

  1. Rufen Sie im Knowledge-Builder das Menü Einstellungen auf und wählen Sie den Reiter System aus. Wählen Sie dort das Feld Rechte.
  2. Setzten Sie im Feld Rechtesystem aktiviert einen Haken.
  3. Geben Sie im Feld Benutzertyp den Objekttyp an, dessen Objekte die Benutzer des Rechtesystems sind. Das ist i.d.R. der Objekttyp "Person". (Typ darf nicht abstrakt sein.)
  4. Wenn Sie das Knowledge-Portal von k-infinity angebunden haben, geben Sie in dem Feld Standard Web-Benutzer einen Benutzer an (Objekt des zuvor definierten Personenobjekttyps).

Vor der Aktivierung des Rechtesystems heißt der Ordner Rechte (deaktiviert). Wurde das Rechtesystem aktiviert heißt der Ordner Rechte. Durch eine Deaktivierung des Rechtesystem, werden keine Prüfungen der Zugriffsrechte mehr durchgeführt. Die definierten Regeln im Rechtebaum bleiben aber erhalten und werden bei einer erneuten Aktivierung des Rechtesystems wieder verwendet.

Beachte: Greift man vom Web-Frontend aus ohne spezielle Anmeldung auf ein Element zu, wird die unter Standard Web-Benutzer angegebene Person verwendet. Gewöhnlich legt man hier eine Scheinperson namens "anonymous" oder "Gast" an.

Damit das Rechtesystem auch im Knowledge-Builder funktioniert, muss der Benutzer-Accounts des Knowledge-Builders mit einem Objekt aus dem semantischen Modell verknüpft werden. Der Benutzer-Account kann nur mit Objekten des Typs verknüpft werden, der bei der Aktivierung des Rechtesystems im Feld Benutzertyp angegeben wurde.

Die Verknüpfung ist für die Verwendung des Operationsparameter Benutzer bei Suchfiltern bzw. bei für die Verwendung des Zugriffsparameters Benutzer bei Strukturabfragen generell notwendig, wenn das Rechtesystem bzw. die Suche nicht in einer Anwendung sondern im Knowledge-Builder selbst ausgeführt.

Anleitung für die Verknüpfung von Knowledge-Builder Nutzern mit Objekten des Personen Typs

  1. Im Knowledge-Builder das Menü Einstellungen aufrufen und den Reiter System wählen. Dort das Feld Benutzer auswählen.
  2. Den Nutzer auswählen, der verknüpft werden soll. Über Verknüpfen kann der Benutzer mit einem Personenobjekt verknüpft werden, das noch mit keinem Knowledge-Builder-Account verknüpft ist.
    Die Funktion Verknüpfung aufheben führt dazu, dass die Verknüpfung des Knowledge-Builder-Account mit dem Personenobjekt aufgehoben wird.

Beachte: Der aktuell angemeldete Nutzer kann nicht verknüpft werden.

Benutzer mit Administratorenrechten dürfen generell alle Operationen durchführen, unabhängig davon welche Rechte im Rechtesystem definiert wurden. Die Definition als Administrator wird ebenfalls im Menü Einstellungen auf dem Reiter System im Feld Benutzer durchgeführt.

6.1.2 Access Right Tree

Traversierung des Rechtebaumes

Der Rechtebaum besteht aus Regeln, die in einem Baum definiert sind. Die Äste des Baumes, auch als Teilbaum bezeichnet, bestehen aus den Bedingungen, die geprüft werden sollen. Die Bedingungen werden im System als Filter definiert, die ineinander geschachtelt werden. Bei der Auswertung läuft das System den Baum von oben nach unten ab. Wenn eine Bedingung auf die Zugriffssituation passt, dann geht die Prüfung zum nächsten Filter des Teilbaumes. Dieser Filter wird wiederum geprüft. Dies wird bis zum Ende des Teilbaumes durchgeführt, dort steht ein Zugriffsrecht oder -verbot. Trifft eine Bedingung nicht auf die Zugriffssituation zu, wird zum nächsten Teilbaum gewechselt. Wenn das System bei der Abarbeitung des Rechtebaumes auf ein Zugriffsrecht oder -verbot stößt, wird die Rechteprüfung mit diesem Ergebnis beendet. Die Äste (Teilbäume) des Baumes werden also nacheinander abgearbeitet, der Baum wird "traversiert", bis eine Entscheidung getroffen werden kann.

Filter und Entscheider werden in Form von Ordnern ineinander geschachtelt, so dass ein Baumkonstrukt entsteht, das aus verschiedenen Teilbäumen besteht. Ein Ordner kann mehrere Unterordner haben (mehrere Nachfolgefilter auf einer Ebene), wodurch Verzweigungen im Rechtebaum entstehen. Ordner, die auf einer Ebene definiert sind, werden nacheinander abgearbeitet (von oben nach unten).

Gestaltung des Rechtebaumes

Bei der Erstellung des Rechtebaumes ist es wichtig die Regeln sinnvoll zu gruppieren, denn wenn eine Entscheidung für eine Zugriffserlaubnis oder ein Zugriffsverbot getroffen wurde, werden keine weiteren Regeln mehr geprüft. Deswegen sollten Ausnahmen vor den globalen Regeln definiert werden.

Die zwei grundlegenden Fälle, die man unterscheiden muss, sind:

  • Negativ-Konfiguration: Im untersten Teilbaum wird pauschal alles erlaubt, darüber werden Verbote formuliert.
  • Positiv-Konfiguration: Unten ist pauschal alles verboten, außer dem, was weiter oben erlaubt ist.

Die Reihenfolge der Teilbäume ist also ausschlaggebend bei der Erstellung des Rechtebaumes. Die Reihenfolge der Bedingungen in einem Teilbaum dagegen (ob wir zuerst die Operation und dann die Eigenschaft prüfen oder umgekehrt) ist beliebig.

Für die Definition eines Teilbaumes des Rechtebaumes, ist es nicht unbedingt notwendig alle Filterarten zu verwenden. Ein Teilbaum besteht aus mindestens einem Filter und einem Entscheider. Eine Ausnahme ist der letzte Teilbaum der i.d.R. nur aus einem Entscheider besteht, der alle restlichen Operationen erlaubt (die vorher im Rechtebaum nicht verboten wurden) bzw. alle restlichen Operationen verbietet (die vorher im Rechtebaum nicht erlaubt wurden).

Beispiel: Rechtebaum

In dieses einfache Beispiel zeigt einen Rechtebaum bestehend aus einem Rechteteilbaum und einen Default-Entscheider, der alles erlaubt:

Im dem Rechteast wird das Löschen oder Modifizieren von den Attributen Name, Dauer und Erscheinungsdatum verboten. Dafür wird ein Operationsfilter verwendet, der die Operationen Löschen oder Modifizieren als Bedingung hat. Nur diese Operationen werden von diesem Operationsfilter durchgelassen. Der nächste Filter ist ein Eigenschaftsfilter, der auf bestimmte Eigenschaften filtert. In diesem Fall werden die Attribute Name, Dauer und Erscheinungsdatum gefiltert unabhängig davon, an welchem Objekt oder an welcher Eigenschaft diese gespeichert sind. Der letzte Knoten des Rechteast ist der Entscheider Verboten, der jede Zugriffsoperation verbietet, die auf die beiden vorgestellten Filter passt. Trifft eine der beiden Bedingungen nicht auf die Zugriffsituation zu, wird der Default Entscheider Erlaubt ausgeführt. 

Dieser einfache Rechtebaum würde in k-infinity folgender Maßen aussehen:

Prüfung einer Operation anhand des Rechtebaum Beispiels:

Die linke Seite zeigt die zu prüfende Operation: Der Nutzer Paul möchte das Attribut Beschreibung löschen. Auf der rechten Seite ist der Rechtebaum abgebildet. Die Prüfung der Bedingung des ersten Filters fällt positiv aus, da Paul die Operation Löschen durchführen möchte. Im Rechtebaum wird der nächste Filter des Rechteteilbaumes ausgeführt. Dies ist der Eigenschaftsfilter der Attribute Name, Dauer und Erscheinungsdatum. Die Prüfung des Filters fällt negativ aus, da die Beschreibung keine der gefilterten Eigenschaften ist. Die Abarbeitung des Teilbaumes wird angebrochen. Es wird zum nächsten Teilbaum des Rechtebaumes gewechselt. Dies ist bereits der Default-Entscheider Erlaubt, der alles erlaubt, was nicht im Rechtebaum explizit verboten ist.

6.1.3 Decider

Entscheider stehen immer an der letzten Stelle eines Rechteteilbaumes. Durch die Kombination mit Filtern werden Zugriffsituationen bestimmt in denen der Zugriff explizit erlaubt bzw. verboten ist. Wenn bei der Traversierung des Rechtebaumes ein Entscheider erreicht wird, dann wird mit dieser Entscheidung die Rechteprüfung beantwortet. Die zu prüfende Operation wird dann entweder erlaubt oder abgewiesen. Der Rechtebaum wird dann nicht weiter geprüft.

 Symbol ZugriffsrechtBeschreibung
 Zugriff gewährenDer Zugriff wird in der zu prüfenden Zugriffssituation erlaubt.
 Zugriff verweigernDer Zugriff wird in der zu prüfenden Zugriffssituation nicht erlaubt.

Es gibt grundsätzlich zwei verschiedene Entscheider einen positiven - Zugriff erlaubt und einen negativen - Zugriff verboten.

Anleitung zum Anlegen eines Entscheiders

  1. Wählen Sie im Rechtebaum die Stelle aus, an der sie einen Entscheider anlegen wollen.
  2. Über die Buttons  und  werden neue Entscheider als Unterordner des aktuell ausgewählten Ordners angelegt.
  3. Geben Sie dem Ordner einen Namen.

6.1.4 Assemble Access Rights

Für die Definition von Rechten werden Filter und Entscheider im Rechtebaum miteinander kombiniert. Im Kapitel Filter werden die verschiedenen Filterarten und deren Einsatzmöglichkeiten dargestellt. Die Entscheider Zugriff gewähren oder Zugriff verweigern stellen jeweils den letzten Knoten eines Teilbaumes des Entscheidungsbaumes dar. Wird ein Entscheider erreicht, so wird mit dieser Entscheidung die Traversierung des Rechtebaumes beendet.

Um Regeln im Rechtesystem zu definieren stehen die folgenden Funktionen zur Verfügung:

 Neuer OperationsfilterEin neuer Operationsfilter wird erstellt.
 Neuer SuchfilterEin neuer Suchfilter wird erstellt.
 Neuer EigenschaftsfilterEin neuer Eigenschaftsfilter wird erstellt.

Neuer Strukturordner

Ein neuer Strukturordner wird erstellt.

Zugriff gewähren

Ein positiver Entscheider, der den Zugriff erlaubt, wird erstellt.
 Zugriff verweigernEin negativer Entscheider, der den Zugriff verbietet, wird erstellt.

Um Rechte sinnvoll zu strukturieren, können Strukturordner verwendet werden. Sie haben keinen Einfluss auf die Traversierung des Rechtebaumes. Sie dienen lediglich dazu bei einer Vielzahl von Rechten, inhaltlich zusammengehörige Teilbäume des Rechtebaumes zu gruppieren.

Anordnung von Ordner im Rechtebaum ändern

Um die Filter und Entscheider im Rechtebaum in die richtige Reihenfolge zu bringen, kann über ein Klick mit der rechten Maustaste ein Kontextmenü aufgerufen werden:

In diesem Kontextmenü kann der Filter oder Entscheider umbenannt, gelöscht und exportiert sowie die Position im Rechtebaum verändert werden. Liegen zwei Ordner (Filter oder Entscheider) auf der gleichen Ebene, kann mithilfe der Funktion Nach oben, Nach unten der Ordner im Rechtebaum weiter nach vorne oder hinten verschoben werden. Ganz nach oben und Ganz nach unten verschiebt den Ordner entsprechend an die erste bzw. letzte Stelle der Ebene im Rechtebaum.

Sollen Ordner ineinander geschachtelt werden, also die Ebene im Entscheidungsbaum verändert werden, kann dies mit Drag & Drop durchgeführt werden.

Zusammensetzen von Rechten

Durch das Zusammensetzen von Filtern und Entscheidern im Rechtebaum gibt es eine Vielzahl von Kombinationsmöglichkeiten um Rechte zu definieren. Es gibt grundsätzlich 3 verschiedene Vorgehensweisen um Rechte zu definieren:

  • Definition von Rechten für jede mögliche Zugriffsituation
  • Positiv-Konfiguration
  • Negativ-Konfiguration

Da die Definition von Zugriffsrechten für jede mögliche Zugriffsituation eine sehr aufwendige Vorgehensweise ist, wird i.d.R. eine der beiden anderen Konfigurationswiesen angewendet. Diese werden in den beiden folgenden Abschnitten erläutert. Positive Configuration

Wenn im Rechtebaum nur Rechte definiert werden, die bestimmte Zugriffe erlauben und alle anderen Zugriffe, über die nichts ausgesagt wird, verboten sind, spricht man von einer Positiv-Konfiguration des Rechtebaumes. In jedem Teilbaum des Rechtebaumes werden Regeln definiert, die bestimmte Operationen erlauben. Alle zu prüfenden Operationen durchlaufen den Rechtebaum: Passt die zu prüfende Operation nicht auf die Bedingungen der Teilbäume, wird sie am Ende des Rechtebaumes abgelehnt.

Beispiel: Positiv-Konfiguration

Dieses Beispiel zeigt, wie ein positiv formulierter Rechtebaum im Knowledge-Builder aussehen kann:

Der erste Teilrechtebaum definiert den lesenden Zugriff auf die Attribute Name, Dauer und Erscheinungsdatum. Die Operation Lesen wird für diese Attribute erlaubt. Der zweite Teilrechtebaum erlaubt das Anlegen von neuen Objekten des Typs Song. Alle anderen Operationen werden am Ende des Rechtebaumes generell verboten. Negative Configuration

Werden im Rechtebaum Regeln definiert, die bestimmte Operationen ablehnen und alle nicht darauf passenden zu prüfenden Operationen erlaubt werden, spricht man von einer Negativ-Konfiguration. In den Teilbäumen des Rechtebaumes werden bestimmte Operationen verboten. Passt eine zu prüfende Operation nicht auf die Bedingungen der Teilbäume, dann wird die Operation am Ende des Rechtebaumes erlaubt.

Beispiel: Nagativ-Konfiguration

Dieses Beispiel zeigt, wie ein negativ formulierter Rechtebaum im Knowledge-Builder aussehen kann:

Der erste Teilrechtebaum verweigert im Gegensatz zum Beispiel Positiv-Konfiguration die Zugriffsrechte für das Löschen und Modifizieren der Attribute Name, Dauer und Erscheinungsdatum. Der Zweite Teilrechtebaum verbietet das Löschen der Relation die Songs mit dem Album verbindet, in dem sie enthalten sind. Alle anderen Operationen dürfen durchgeführt werden. Example

Was wird gebraucht um dieses Recht in k-infinity zu definieren? Zum einen wird ein Operationsfilter benötigt, da es um das Ändern und Löschen von Elementen geht. Zum anderen muss der Zusammenhang zwischen dem Benutzer und dem Element, an dem er eine Operation ausführen möchte, formuliert werden - das geht nur mithilfe von Suchfiltern. 


Im Operationsfilter wurden die Operationen Löschen und Modifizieren ausgewählt.


Im Suchfilter wird die Relation wurde erstellt von mit dem Relationsziel Person ausgewählt. An dem Relationsziel Person wurde der Zugriffsparameter Benutzer angegeben. Die Einstellung Alle Parameter müssen zutreffen und Suchbedingung muss erfüllt sein sind ausgewählt. In diesem Fall wurde der Operationsparameter Primärelement ausgewählt.

Ein Frage, die das Schema betrifft, ist: An welchen Elementen ist die Relation wurde erstellt von definiert? Es gibt verschiedene Möglichkeiten diese Relation in einem semantischen Netz umzusetzen:

  1. Fall Definition an Objekten und Typen: Nur an Objekten und Typen wird die Relation verwendet.
  2. Fall Definition an allen Elementen: An allen Objekten, Typen, Erweiterungen, Attributen und Relationen wird die Relation verwendet.

Im ersten Fall macht es Sinn den Operationsparameter Primärelement oder übergeordnetes Element zu verwenden. Definiert man das Recht mit dem übergeordneten Element, so gilt es für nicht nur für das Objekt an sich sondern auch für alle Eigenschaften, die an Objekten gespeichert sind, welche vom Nutzer erstellt wurden. Verwendet man stattdessen den Operationsparameter Primärelement so gilt das Recht ebenfalls für alle Metaeigenschaften des Objektes.
Im zweiten Fall wird der Operationsparameter Zugriffselement verwendet, da nur die Elemente geändert werden dürfen, an denen die Relation wurde erstellt von mit dem entsprechenden Relationsziel, dem Benutzer, vorkommt.

Das Recht im Rechtebaum zusammensetzen

Es gibt zwei verschiedene Varianten die Filter zu kombinieren. Gibt es in dem Rechteteilbaum keine Verzweigungen so ist die Reihenfolge der Teilbäume nicht relevant. 

Die Graphik zeigt, die zwei möglichen Kombinationsweisen: Version 1 (links) erst Operationsfilter dann Suchfilter, Version 2 (rechts) erst Suchfilter dann Operationsfilter, als letztes folgt jeweils der Entscheider Erlaubt.

Empfehlung: Es ist sinnvoll den Operationsfilter an erster Stelle zu haben, so ist es möglich unter ihm alle anderen Rechte, welche auf die selbe Operation filtern, anzulegen. Dies schafft eine einfacher nachvollziebare Struktur in den Rechtebaum.

Erweitertes Recht: Elemente die nicht vom Nutzer erstellt wurden, dürfen nicht geändert oder gelöscht werden

Das Recht impliziert das Verbot für alle Elemente, die nicht vom Nutzer erstellt wurden - jedoch haben wir das in der Rechtedefinition noch nicht ausgedrückt. Dafür mussen wir bei der Rechteerstellung den Entscheider Zugriff verboten berücksichtigen. Betrachtet man beide Rechteversionen und kombiniert diese mit dem negativen Entscheider, kommen folgende Varianten heraus. Jedoch haben die beiden Varianten unterschiedliche Auswirkungen im Rechtesystem.

Fügt man an die beiden eben dargestellten Kombinationsweisen jeweils den Entscheider Verboten hinzu, so entstehen die beiden Versionen: Version 1 (links) erst Operationsfilter, dann Suchfilter und Entscheider Erlaubt. Auf den Operationsfilter folgt außerdem in einem zweiten Teilbaum der Entscheider Verboten. Version 2 (rechts) erst Suchfilter, dann Operationsfilter und Entscheider Erlaubt. In dieser Version folgt auf den Suchfilter ein zweiter Teilbaum mit dem Entscheider Verboten.

Auswirkungen der verschiedenen Versionen auf das Rechtesystem

Version 1 (links)

  • Erlaubt wird das Modifizieren und Löschen selbst erstellter Elemente.
  • Verboten wird das Modifizieren und Löschen aller anderen Elemente.
  • Es wird keine Aussage über alle anderen Operationen gemacht.

Version 2 (rechts)

  • Erlaubt wird das Modifizieren und Löschen selbst erstellter Elemente.
  • Verboten werden alle anderen Operationen auf selbst erstellte Elemente (wie z.B. das Lesen)
  • Es wird keine Aussage über alle anderen Elemente gemacht.

Die Punkte zeigen, dass Version 2 nicht das geforderte Zugriffsrecht ausdrückt. Nur Version 1 formuliert das gewünschte Zugriffsrecht - Jeder Benutzer darf selbst erstellte Elemente ändern oder löschen sowie Elemente, die nicht vom Nutzer erstellt wurden, dürfen nicht geändert oder gelöscht werden.

6.1.5 Configuration og User Generated Operations

Wird im Bereich System der Ordner Rechte ausgewählt, werden im Hauptfenster die Reiter Gespeicherte Testfälle und Konfigurieren angeboten. Auf dem Reiter Konfigurieren können eigene Operationen konfiguriert werden.

Die Konfiguration von eigenen Operationen findet i.d.R. nur dann Anwendung, wenn der Knowledge-Builder zusammen mit anderen Anwendungen verwendet wird. Eigene Operationen sind anwendungsspezifische Operationen, die gemeinsam geprüft werden sollen. Dabei geht es darum, dass eine Kette von Operationen geprüft werden soll und nicht nur eine Operation.

Anleitung zur Konfiguration von eigenen Operationen

  1. Wählen Sie im Knowledge-Builder den Bereich System den Ordner Rechte aus.
  2. Wählen Sie im Hauptfenster den Reiter Konfigurieren aus.
  3. Klicken Sie auf Hinzufügen, damit eine neue Operation erstellt wird.
  4. Geben Sie in nachfolgenden Fenstern für die neue Operation einen internen Namen und eine Beschreibung an.
  5. Die neue Operation wird als Benutzerdefinierte Operation hinzugefügt.
  6. Über Entfernen können benutzerdefinierte Operationen wieder gelöscht werden.
6.2 trigger

Trigger sind automatische Operationen, die in k-infinity ausgeführt werden, wenn ein bestimmtes Ereignis eintritt. Sie helfen dabei Arbeitsabläufe zu unterstützen, in dem immer gleich bleibende Arbeitsschritte automatisiert werden.

Beispiele für den Einsatz von Trigger sind:

  • Versenden von E-Mails aufgrund einer bestimmten Änderung
  • die Bearbeitung von Dokumenten in einer bestimmten Reihenfolge durch bestimmte Personen
  • die Kennzeichnung von Aufgaben als offen oder erledigt aufgrund einer bestimmten Bedingung
  • die Erstellung von Objekten und Relationen, wenn eine bestimmte Änderung durchgeführt wird
  • die Berechnung von Werten in einer vorher definierten Art und Weise
  • automatische Generierung des Namensattribut von Objekten (z.B. Zusammensetzung aus Eigenschaften des Objektes)

Wie funktionieren Trigger?

Trigger sind eng verwandt mit dem Rechtesystem. Sie nutzen den selben Filtermechanismus, um festzulegen, wann ein Trigger ausgelöst wird. Die Filter werden in einem Baum angeordnet, dem Triggerbaum, der wie der Rechtebaum aufgebaut ist. Er besteht aus Filtern, mit denen Bedingungen definiert werden, wann eine Trigger-Aktion ausgeführt werden soll. Tritt durch die Durchführung einer Operation eine Zugriffsituation ein, welche auf die definierten Bedingungen passt, wird die zugehörige Trigger-Aktion ausgeführt.

Trigger-Aktionen sind in den meisten Fällen Skripte, die abhängig von den Elementen der Zugriffsituation, mit diesen Operationen durchführen. Somit ist es möglich gleichbleibende Arbeitsschritte zu automatisieren oder intelligente Auswertungen auf Grundlage von bestimmten Konstellationen im sem. Netz durchzuführen. In Skripten können jegliche Operationen auf Elemente, die in Abhängigkeit von komplexen Auswertungen stehen, ausgeführt werden und damit situations- und anwendungsspezifische Anforderungen an das sem. Netz gewährleisten. Die meisten Trigger sind aus diesem Grund i.d.R. projekt- und netzspezifisch; Für den Einzelfall sollte eine Beratung durchgeführt werden.

6.2.1 Activate Trigger

Um mit Triggern arbeiten zu können, muss die Trigger-Funktionalität zunächst im Knowledge-Builder aktiviert werden.

Anleitung zur Aktivierung von Triggern

  1. Rufen Sie die Einstellungen des Knowledge-Builders auf.
  2. Wählen Sie dort den Reiter System und das Feld Trigger aus.
  3. Setzten Sie im Feld Trigger aktiviert einen Haken.

Hier kann ein Limit für rekursive Trigger angeben werden. Die Standardeinstellung ist "Keine". Als rekursive Trigger werden Trigger bezeichnet, die sich selber aufrufen. Dies passiert, wenn im Trigger-Skript selbst Operationen im sem. Netz durchgeführt werden, die wiederum selbst auf die Filterdefinition des Triggers passen.

Vor der Aktivierung des Trigger-Funktionalität heißt der Trigger Ordner im Technikbereich von k-infinity Trigger (deaktiviert). Durch die Aktivierung wird der Ordner in Trigger umbenannt.

Anmerkung: Wenn in Triggern der aktuelle Nutzer verwendet wird (z.B. in Suchfiltern oder über die entsprechende Skriptfunktion) und der Nutzer nicht in einer Anwendung Operationen ausführt sondern im Knowledge-Builder selbst, ist die Verknüpfung des Knowldge-Builder-Benutzer-Accounts mit einem Personenobjekt notwendig. Wie eine solche Verknüpfung erstellt wird, wird im Kapitel Aktivierung des Rechtesystems erklärt.

6.2.2 Trigger Tree

Der Triggerbaum ist wie der Rechtebaum aufgebaut. Er besteht aus Ästen (Teilbäumen), die aus Filtern und Triggern bestehen. Die Filter sind die Bedingungen, die geprüft werden müssen, damit der Trigger am Ende des Teilbaumes ausgeführt werden kann, wenn alle vorher zu prüfenden Bedingungen erfüllt sind.

Der Triggerbaum wird bei jeder Operation auf die Daten abgefragt - der Baum wird "traversiert". Passt ein Teilbaum auf die Zugriffsituation, so wird der Trigger ausgeführt. Passt die Bedingung eines Filters nicht auf die Zugriffssituation, so wird zum nächsten Teilbaum gewechselt. Nach der Ausführung einer Trigger-Aktion wird der Triggerbaum weiter durchlaufen, im Gegensatz zum Rechtesystem, dessen Abarbeitung mit dem Erreichen eines Entscheiders beendet ist. Um im Triggerbaum zu definieren, dass nach der Ausführung einer Aktion keine weiteren Filter geprüft werden sollen, dient die Schaltfläche Keine weiteren Trigger auslösen:

Keine weiteren Trigger auslösenDie Traversierung des Triggerbaumes wird beendet.

Am Ende eines Teilbaumes steht im Gegensatz zum Rechtesystem kein Entscheider sondern Aktionen zur Verfügung.




Trigger definieren

Es wird eine neue Trigger-Aktion erstellt.

Die verfügbaren Trigger-Aktionen sind:

  • Log eintragen: Ein Logeintrag wird geschrieben.
  • Script ausführen > JavaScript: Eine Script-Datei in JavaScript wird ausgeführt.
  • Script ausführen > KScript: Eine Script-Datei in KScript wird ausgeführt.

Gestaltung des Triggerbaumes

Bei der Gestaltung des Triggerbaumes hat die Reihenfolge, in der man die Trigger definiert i.d.R. keinen Einfluss auf die Performance von k-infinity. Beim Rechtebaum gibt es Empfehlung zur Gestaltung, die aber nicht auf den Triggerbaum übertragbar sind, da nach Ausführung einer Trigger-Aktion der Triggerbaum weiter traversiert wird.

Für die übersichtlichere Gestaltung der Trigger können diese in Strukturordnern gesammelt werden. Die Strukturordner selbst haben keinen Einfluss auf die Traversierung des Triggerbaumes.



StrukturordnerStrukturordner für die Gruppierung von Teilbäumen


Beispiel: Triggerbaum

Dieses Beispiel zeigt einen Triggerbaum, der die Namen von Personen und Konzerten automatisch aus Eigenschaften der Objekte zusammensetzt:

Dieser einfach Triggerbaum beginnt mit einem Operationsfilter und teilt sich nach den Operationsfilter in zwei getrennte Teilbäume. Wird einer der beiden Operationen Modifizieren oder Erzeugen ausgeführt, wird diese vom Operationsfilter durchgelassen. Der Teilbaum Person filtert Operationen, die an Attributen, Relationen von Objekten des Typs Person durchgeführt werden. Ist von der Operation entweder das Attribut Vorname oder das Attribut Nachname betroffen, wird diese vom Eigenschaftsfilter durchgelassen. Das dazugehörige Skript, welches das Namensattribut einer Person aus Vor- und Nachname zusammensetzt wird ausgeführt. Der zweite Teilbaum bezieht sich ebenfalls auf den Operationsfilter Modifizieren oder Erstellen aber filtert dann Attribute und Relationen, die an Objekte des Typs Konzert gespeichert sind. Der Eigenschaftsfilter lässt nur Operationen durch, welche an den Attributen Datum, die Relationen zum Veranstaltungsort oder dem Künstler durchgeführt werden. Treffen diese Bedingungen zu, wird das dazugehörige Skript ausgeführt, welches den Name des Konzertes zusammensetzt.

So würde dieser Trigger Baum in k-infinity aussehen:

6.2.3 Create Trigger

Wie im Abschnitt Triggerbaum beschrieben, bestehen Trigger aus Filtern und Trigger-Aktionen. Diese werden miteinander kombiniert, so dass eine bestimmte Trigger-Aktion nur dann ausgeführt wird, wenn sie benötigt wird.

Die folgenden Funktionen stehen im Bereich Trigger zur Verfügung:

Neuer OperationsfilterEin neuer Operationsfilter wird erstellt.
Neuer SuchfilterEin neuer Suchfilter wird erstellt.
Neuer EigenschaftsfilterEin neuer Eigenschaftsfilter wird erstellt.
Neuer LöschfilterEin neuer Löschfilter wird erstellt.
Neuer StrukturordnerEin neuer Strukturordner wird erstellt.
Neuer TriggerEine neue Trigger-Aktion wird erstellt.
Keine weiteren Trigger auslösenEin neuer "Stopp"-Ordner wird erstellt. Dieser beendet die Traversierung des Triggerbaumes.

Bei der Erstellung von Triggern sollten zwei grundsätzliche Eigenschaften des Trigger Mechanismus beachtet werden:

  • Die Ausführung eines Trigger Skriptes, kann dazu führen, dass weitere Trigger ausgelöst werden. Dies passiert dann wenn im Trigger-Skript selbst Operationen in der semantischen Graph-Datenbank ausgeführt werden.
  • Nach der Ausführung einer Trigger-Aktion wird der Triggerbaum weiter durchlaufen. Alle Trigger-Aktionen der Teilbaume, die auf die Zugriffssituation zutreffen, werden ausgeführt.

6.2.4 Trigger Action

Trigger-Aktionen dienen dazu intelligente Operationen in der semantischen Graph-Datenbank durchzuführen, die beispielsweise Arbeitsabläufe automatisieren oder unterstützen. Sie werden nur in bestimmten Situationen ausgeführt, nämlich dann wenn die Zugriffsituation und die Verknüpfungen im semantischen Netz einen bestimmten Zustand annehmen, der durch Filter definiert wird.

Anleitung zum Anlegen von Trigger-Aktionen

  1. Wählen Sie im Triggerbaum die Stelle, an der die Trigger-Aktion angelegt werden soll.
  2. Fügen Sie über den Button  einen neuen Trigger ein.
  3. Wählen Sie aus der Liste den Aktionstyp aus: Log eintragen oder Skript ausführen (Wenn Sie ein Skript ausführen wollen, wählen Sie die Skriptsprache aus.)
  4. Der Trigger wird als Unterordner des aktuell ausgewählten Ordners erstellt. Script Trigger

Für die Ausführung des Skriptes muss ein Operationsparameter angegeben werden. Im Gegensatz zu Suchfiltern, kann nur ein Operationsparameter angegeben werden. Auf dem im Operationsparameter enthaltenem Element startet die Ausführung des Skriptes.

Zeitpunkt/Art der Ausführung

  • Vor der Änderung: Der Trigger wird ausgeführt bevor die Operation durchgeführt wird.
  • Nach der Änderung: Der Trigger wird direkt nach der Durchführung der Operation ausgeführt.
  • Ende der Transaktion: Der Trigger wird erst am Ende der gesamten Transaktion ausgeführt.
  • Job-Client: Der Jobclient bestimmt den Zeitpunkt der Ausführung.

Beachte: Trigger, die bei Löschoperationen ausgelöst werden, sollten vorzugsweise als Zeitpunkt Vor der Änderung verwenden, da ansonsten das zu löschende Element nicht mehr zur Verfügung steht. Für andere Operationen bietet sich als Zeitpunkt eher Nach der Änderung oder Ende der Transaktion an, da dann beispielsweise eine Eigenschaft zu dem neu erstellten Element hinzugefügt werden kann oder automatisch der Name aus verschiedenen Eigenschaften eines Objektes generiert werden kann, wenn eine oder mehrere Eigenschaften geändert wurden.
Werden z.B. mehrere Datensätze in einem Import in k-infinity importiert, die eine Trigger-Aktion auslösen, die auf Basis von importierten Relationen, Aktionen im sem. Netz durchführen, kann es sinnvoll sein den Import in einer Transaktion durchzuführen und entsprechend Ende der Transaktion als Zeitpunkt der Ausführung auszuwählen, da sonst noch nicht alle Relationen die das Script benötigt importiert wurden.

Je Operationsparameter nur ein mal ausführen

Ist diese Einstellung ausgewählt, dann wird das in Operationsparameter ausgewählte Element maximal ein mal pro Transaktion ausgeführt. Wenn diese Einstellung gesetzt ist, sollte der Ausführungszeitpunkt auf Ende der Transaktion gesetzt werden, damit im Skript der endgültige Zustand des Elements verwendet wird.

Beispiel: Bei Personen soll der Name des Objekts aus Vorname und Nachname zusammengesetzt werden. Mit dieser Einstellung wird bei gleichzeitiger Änderung von Vor- und Nachname der Trigger nur ein mal ausgeführt.

Ausführung löst keine Trigger aus

Mit dieser Einstellung wird festgelegt, dass durch die Operationen, die innerhalb eines Triggers ausgeführt werden, keine weiteren Trigger ausgelöst werden können. Mit dieser Einstellung lassen sich Endlosschleifen vermeiden.

Bei Skriptfehlern Skript weiter ausführen

Ist diese Einstellung aktiv, so wird versucht nach Ausführungsfehlern wieder aufzusetzen und die Ausführung des Skriptes fortzuführen. Diese Einstellung eignet sich vorwiegend für Skripte, die voneinander unabhängige Anweisungen ausführen sollen, nicht für solche, die auf vorherige Schritte des Skriptes aufbauen. 

Transaktion abbrechen, wenn Trigger fehlschlägt

Diese Einstellung legt das Abbruchverhalten bei Skriptfehlern fest. Tritt bei der Ausführung des Skriptes ein Fehler auf und diese Einstellung ist aktiv, werden alle Aktionen der Transaktion rückgängig gemacht. Ist diese Einstellung nicht aktiv, werden alle Aktionen durchgeführt außer diese, die von der Fehlerstelle betroffen sind. Die ursprüngliche Aktion, die zum Aufruf des Triggers geführt hat, wird trotzdem durchgeschrieben.

Ausführen während eines Daten-Refactorings

Unter Daten-Refactoring werden Operationen zur Umstrukturierung des semantischen Netzes verstanden wie z.B. Typ wechseln oder Relationsziel neu wählen. Daten-Refactoring-Operationen können unter Umständen ungewollte Trigger-Aktionen auslösen und in bestimmten Fällen auch Fehler bei der Durchführung des Skriptes erzeugen. Aus diesem Grund kann pro Trigger eingestellt werden, ob er bei Daten-Refactorings ausgeführt werden soll. JavaScript Trigger

Der Funktionsrumpf für JavaScript-Triggerfunktion wird automatisch angelegt. Ein JavaScript Trigger braucht zwangsläufig den Funktionsrumpf der Triggerfunktion. (Er darf z.B. nicht auskommentiert werden.)

 * Perform the trigger
 * @param parameter The chosen parameter, usually a semantic element
 * @param {object} acccess Object that contains all parameters of the access
 * @param {$k.User} user User that triggered the access

function trigger(parameter, access, user)

Das Parameter "access" kann (je Operation variierend) folgende Eigenschaften enthalten:

Eigenschaft Beschreibung
accessedObject Zugriffselement
core Kernobjekt
detail Detail
inversePrimaryCoreTopic Primäres Relationsziel
inverseRelation Inverse Relation
inverseTopic Relationsziel
operationSymbol "read", "deleteRelation", etc.
primaryCoreTopic Primäres Kernobjekt
primaryProperty Primäreigenschaft
primaryTopic Primärelement
property Eigenschaft
topic Übergeordnetes Element
user Benutzer (identisch zu "user"-Parameter der Funktion) Log Trigger

Möchte man die Trigger-Funktionalität überwachen bzw. dokumentieren, wann welcher Trigger ausgelöst wurde und welche Operationen im sem. Netz ausgeführt wurden, eignen sich Log Trigger. Der Log wird in das jeweilige Log File (bridge.log, importtool.log etc.) geschrieben in dessen Anwendungsumgebung die Operation, welche den Trigger ausgelöst hat, durchgeführt wird.

Zeilen des LogeintragesZustand des sem. Netzes zum Zeitpunkt
#prevor Auslösung
#postnach Auslösung
#endam Ende der Transaktion
#commitbei erfolgreicher Beendigung der Transaktion

Logeinträge dienen dazu nachzuvollziehen, ob in einer bestimmten Zugriffsituation, die tatsächlich geschehen ist, ein Trigger ausgeführt wurde und was er gemacht hat. Im Gegensatz dazu kann in der Testumgebung getestet werden, ob in einer bestimmten Zugriffsituation ein Trigger ausgelöst werden würde oder nicht, ohne dass die konkrete Zugriffsituation durchgeführt wird.

Anleitung zum Anlegen von Log Triggern

  1. Wählen Sie im Triggerbaum das Trigger-Skript aus, welches geloggt werden soll.
  2. Erstellen Sie über den Button ein Trigger vom Typ Log eintragen im Triggerbaum direkt vor dem Skript-Trigger.


Logeintrag der das Ändern des Attributs e-mail durch einen Trigger dokumentiert.

6.3 Filter

Mithilfe von Filtern werden die Bedingungen im Rechtebaum bzw. im Triggerbaum definiert, um Zugriffssituationen einschränken zu können, wann ein Entscheider bzw. Trigger ausgeführt werden soll. Neue Filter werden im Baum unterhalb des aktuell ausgewählten Knotens angelegt. Auf diese Weise werden sie untereinander geschachtelt.

Im Rechtesystem stehen die drei Filterarten Operationsfilter, Suchfilter und Eigenschaftsfilter zur Verfügung. Zusätzlich zu den drei grundsätzlichen Filterarten bietet der Bereich Trigger einen spezifischen Filter - den Löschfilter.

Es gibt verschiedene Arten von Filtern - Wann benutzen wir welchen Filter?

OperationsfilterFiltert die Operationen; Auswahl aus Liste
SuchfilterFiltert Elemente durch Strukturabfrage
EigenschaftsfilterFiltert Relationen und Attribute; Auswahl aus Liste
LöschfilterFiltert das Löschen von Elementen

Operationen können nur mit einem Operationsfilter bestimmt werden. Benutzer können nur durch Suchfilter bestimmt werden. Eigenschaften können entweder mit Such- oder Eigenschaftsfiltern bestimmt werden. Die Verwendung von Eigenschaftsfiltern ist dann sinnvoll, wenn unabhängig von weiteren Eigenschaften im semantischen Modell wie Relationen zum Nutzer, Eigenschaften gefiltert werden sollen. Vor allem wenn große Mengen von Eigenschaften gefiltert werden sollen, ist es einfacher und übersichtlicher, das in einer Liste zu tun, anstatt in einer Strukturabfrage. Sollen Relationen zum Zugriffsobjekt oder zum Nutzer einbezogen werden, muss allerdings ein Suchfilter verwendet werden.

Anleitung zum Anlegen eines Filters

  1. Wählen Sie im Rechte- bzw. Triggerbaum die Stelle aus, an der Sie einen neuen Filter anlegen wollen.
  2. Erstellen Sie über die Buttons , oder einen neuen Filter.
  3. Der Filter wird als Unterordner des aktuell ausgewählten Ordners im Baum angelegt.
  4. Geben Sie dem Ordner einen Namen.
6.3.1 Gear Filter

Für welche Operationen ein Zugriffsrecht gelten soll oder ein Trigger ausgeführt werden soll, kann nur mithilfe von Operationsfiltern angegeben werden. Durch die Auswahl der gewünschten Operation kann diese dem Filter hinzugefügt oder wieder entfernt werden.

Die Operationen sind in Gruppen gegliedert. Wählt man den übergeordneten Knoten einer Gruppe aus, werden auch alle darunterliegenden Operationen mit gefiltert. Wenn beispielsweise die Erzeugen Operation ausgewählt wird, dann werden die Operationen Attribut erzeugen, Erweiterung erzeugen, Ordner erzeugen, Relation erzeugen, Relationshälfte erzeugen, Typ erzeugen und Übersetzung erzeugen vom Filter berücksichtigt.

Im Kapitel Operationen werden alle verfügbaren Operationen aufgelistet und zusätzlich wird angegeben, welche Operationsparameter in Kombination verwendet werden können. Die verschiedenen Operationsparameter werden entsprechend im Kapitel Operationsparameter erklärt.

6.3.2 Property Filter

Mit Eigenschaftsfiltern können Attribute und Relationen gefiltert werden. Es gibt zwei verschiedene Vorgehensweisen einen Eigenschaftsfilter zu verwenden:

  • Einschränkung auf Eigenschaften: Angabe der Eigenschaften für die die Bedingung gelten soll. Nachfolgende Filter oder Entscheider des Teilbaumes werden nur ausgeführt, wenn die Zugriffseigenschaft mit den ausgewählten Eigenschaft übereinstimmt.
  • Ausgenommen folgende Eigenschaften: Angabe der Eigenschaften für die die Bedingung nicht gelten soll. Stimmt die Zugriffseigenschaft mit einer der ausgewählten Eigenschaften überein, werden nachfolgende Filter, Entscheider oder Trigger nicht ausgeführt.

Über Hinzufügen und Entfernen können die unten aufgeführten Eigenschaften selektiert werden. Alle unten stehenden Eigenschaften können mithilfe von Alle ausgewählt werden. Keine entfernt alle ausgewählten Eigenschaften. Über das Bearbeiten Feld wird der Detaileditor des Attributs oder der Relation aufgerufen, das oder die im oberen Auswahlfeld markiert ist. Die Reiter Alle Eigenschaften, Generische Eigenschaften, Attribut, Relation, View-Konfiguration und Wissensnetz sollen dem Anwender helfen, die zu filternden Eigenschaften schneller zu finden. Im Reiter Wissensnetz werden alle selbst angelegten Relationen und Attribute angezeigt.

6.3.3 Expert Query Filter

Suchfilter ermöglichen es Elemente im Umfeld des Elementes, auf das zugegriffen werden soll, einzubeziehen. So können nicht nur einzelne Eigenschaften sondern auch Zusammenhänge zwischen Objekten, Eigenschaften und Attributen in die Rechte- bzw. Triggerdefinition einbezogen werden. Bei der Verwendung von Suchfiltern muss ein Operationsparameter angegeben werden, mit dem das Ergebnis der Strukturabfrage verglichen wird. Alle verfügbaren Operationsparameter werden im Kapitel Operationsparameter erklärt.

Es gibt zwei verschiedene Vorgehensweise Suchfilter zu definieren:

  • Suchbedingung muss erfüllt sein: Diese Einstellung ist initial ausgewählt. Stimmt das Suchergebnis der Strukturabfrage mit dem Operationsparameter überein, ist die Bedingung des Filters erfüllt und nachfolgende Filter, Entscheider oder Trigger werden ausgeführt.
  • Suchbedingung darf nicht erfüllt sein: Liefert die Strukturabfrage als Ergebnis das selbe Element wie der Zugriffsparameter, ist die Bedingung nicht erfüllt und die Prüfung des Rechte- bzw. Triggerbaumes wechselt zum nächsten Teilbaum. Ist das Ergebnis der Strukturabfrage ein anderes als der Zugriffsparameter liefert, ist die Bedingung erfüllt und der nachfolgende Filter, Entscheider oder Trigger wird ausgeführt.

Die Objekte des Typs links oben, die auf die Suchbedingung passen, sind das Ergebnis der Strukturabfrage. Diese werden mit dem Element, das vom Operationsparameter übergeben wird, verglichen. In der Strukturabfrage können Zugriffsparameter verwendet werden, mit diesen können beispielsweise der Benutzer, das Zugriffsobjekt usw. in die Suche einbezogen werden.

Bei der Auswahl der Operationsparameter kann konfiguriert werden, ob

  • alle ausgewählten Parameter zutreffen müssen (Alle Parameter müssen zutreffen)
  • oder nur ein Parameter zutreffen muss (Ein Parameter muss zutreffen).

Beachte: Initial ist die Einstellung Alle Parameter müssen zutreffen ausgewählt. Werden beispielsweise die Operationsparameter Zugriffselement und Primärelement ausgewählt, ist die Bedingung nur dann erfüllt, wenn das Ergebnis der Strukturabfrage sowohl Zugriffselement als auch Primärelement der zu prüfenden Operation ist.

Beispiel 1: Suchfilter im Rechtesystem

Es soll ein Recht definiert werden, das besagt, dass bereits veröffentlichte Songs von allen gesehen werden dürfen unveröffentlichte Songs hingegen nicht.

In diesem Beispiel möchte die Benutzer Paul den Song X lesen. Diese Operation wird nun vom Rechtesystem geprüft. Dort ist ein Suchfilter definiert, der prüft, ob der Song bereits veröffentlicht ist. In der Strukturabfrage des Suchfilters werden Objekte vom Typ Song gesucht, mit der Einschränkung, dass das Attribut Erscheinungsdatum in der Vergangenheit liegt. Die Strukturabfrage liefert alle Songs, die diese Bedingung erfüllen. Ist der Song X einer davon, fällt die Prüfung des Filters positiv aus und der auf den Suchfilter nachfolgende Ordner (mit einem Filter oder Entscheider) wird ausgeführt.    

Bei dem Suchfilter wurden die Einstellungen Suchbedingung muss erfüllt sein und Alle Parameter müssen zutreffen ausgewählt.

Beispiel 2: Suchfilter im Rechtesystem

In den meisten Fällen gibt es eine Verbindung zwischen dem Benutzer, der zugreifen will und den Objekten oder Eigenschaften, auf die er zugreifen will. Ein Beispiel dafür wäre: "Mitarbeiter einer Abteilung die eine Branche betreuen, dürfen alle Kunden aus dieser Branche bearbeiten." Eine andere Version dieses Beispiels, das unten dargestellt wird, wäre: "Nutzer, die einen Künstler pflegen, dürfen diesen bearbeiten und löschen."

Auf der linken Seite ist ein Ausschnitt des Wissensnetzes abgebildet: Das Objekt Paul ist mit den Objekten Künstler A, Künstler B und Künstler C über die Relation pflegt verknüpft. Die inverse Relation von pflegt ist wird gepflegt von, die zwischen den Objekten Künstler A, Künstler B, Künstler C und dem Objekt Paul besteht und im Suchfilter abgefragt wird. Diese Relation im semantischen Netz steht dafür, dass eine Person für die Datenpflege rund um einen Künstler verantwortlich ist.

In diesem Beispiel möchte der Benutzer Paul das Objekt Künstler A löschen. Der dazugehörige Suchfilter liefert als Suchergebnis alle Künstler die von einem bestimmten Benutzer gepflegt werden. Der aktuelle Benutzer wird als Zugriffsparameter in die Strukturabfrage übergeben. Zugriffsparameter in Strukturabfragen werden im Kapitel Strukturabfragen erklärt. Somit liefert die Suche in dieser Zugriffsituation alle Künstler, die von Paul gepflegt werden. Da Künstler A einer davon ist, fällt die Prüfung des Suchfilters positiv aus.

Von der Zugriffssituation werden in diesem Beispiel zwei Aspekte in den Suchfilter eingebracht. Das ist der Künstler der gelöscht werden soll und der Benutzer. Der Suchfilter kann entsprechend auf zwei verschiedene Arten definiert werden. Entweder wird der Künstler als Zugriffselement an den Suchfilter übergeben und der Benutzer als Zugriffsparameter in der Strukturabfrage verwendet. Oder der Benutzer wird als Operationsparameter Benutzer an den Suchfilter übergeben und die Firma als Zugriffsparameter Zugriffselement in der Strukturabfrage verwendet.

6.3.4 *

Löschfilter stehen nur bei der Definition von Triggern zur Verfügung. Sie werden dazu eingesetzt, in einer Löschsituation zu testen, ob das übergeordnete Element auch von dem Löschvorgang betroffen ist. Will man beispielsweise, dass ein Trigger nicht ausgeführt wird, wenn ein Objekt samt all dessen Eigenschaften gelöscht wird, aber dann wenn eine bestimmte Eigenschaft des Objektes gelöscht wird, muss ein Löschfilter verwendet werden.

Bei der Definition eines Löschfilters, muss mindestens ein Operationsparameter angegeben werden, der bestimmt, die Löschung welches Objektes getestet werden soll.

  • Alle Parameter müssen zutreffen: Alle angegebenen Operationsparameter müssen zutreffen. Werden beispielsweise zwei Operationsparameter angegeben (Zugriffsobjekt und Primärobjekt), dann wird geprüft, ob der Löschvorgang sowohl für Zugriffsobjekt als auch für Primärobjekt gilt, das kann nur der Fall sein, wenn das Primärobjekt auch das Zugriffsobjekt ist.
  • Ein Parameter muss zutreffen: Nur einer der angegebenen Operationsparameter muss zutreffen.

Anmerkung: In den meisten Fällen bietet sich der Operationsparameter übergeordnetes Element oder Primärobjekt an, da überprüft werden soll, ob entweder nur die Eigenschaft gelöscht wird, oder ob die Eigenschaft gelöscht wird, weil das gesamte Objekt gelöscht wurde.

  • Nicht vom Löschvorgang erfasst: Die Bedingung des Filters ist positiv, wenn das in Operationsparameter übergebene Element in dieser Transaktion nicht gelöscht wird. 
  • Vom Löschvorgang erfasst: Die Bedingung des Filters ist entsprechend positiv, wenn das in Operationsparameter übergebene Element in dieser Transaktion gelöscht wird.

Beispiel: Löschfilter bei Triggern

In diesem Beispiel soll ein Trigger nur dann ausgeführt werden, wenn der Künstler, der Ort oder das Datum einer Veranstaltung geändert oder gelöscht wird, aber nicht wenn das Objekt gelöscht wird, an denen die Eigenschaften gespeichert sind. Dafür wird die Einstellung Nicht vom Löschvorgang erfasst verwendet. Ist das übergeordnete Zugriffselement vom Löschvorgang erfasst, das in diesem Fall das Konzert-Objekt selbst ist, dann wird die Prüfung des Teilbaumes, aufgrund des negativen Ergebnisses des Filters, abgebrochen.

Verwendet wird der Operationsparameter Übergeordnetes Element und die Einstellung Nicht vom Löschvorgang erfasst.


In dieser beispielhaften Zugriffsituation wird das Attribut Datum mit dem Wert "19.10." am Objekt "Konzert X" gelöscht. Das Objekt selbst wird nicht gelöscht. Der Suchfilter "Konzert", der mit dem Operationsparameter übergeordnetes Zugriffselement definiert ist, und der Eigenschaftsfilter "Künstler, Ort und Datum" werden positiv beantwortet. Der darauffolgende Löschfilter liefert ebenfalls eine positive Antwort, da das Objekt an dem die Eigenschaft gespeichert ist (übergeordnetes Zugriffselement) nicht vom Löschvorgang betroffen ist - entsprechend der Einstellung Nicht vom Löschvorgang erfasst des Löschfilters.


In dieser Zugriffsituation wird das Objekt "Konzert X" vom Nutzer Paul gelöscht. Durch das Löschen des Objektes werden automatisch alle Eigenschaften des Objektes mit gelöscht - also auch alle Attribute des Objektes. Die Prüfung des Triggerbaums wird sowohl für die Löschung des Objektes als auch des Attributes durchgeführt. Der Suchfilter "Konzert" und der Eigenschaftsfilter "Künstler, Ort und Datum" sind in der Prüfung des Triggerbaumes für den Löschvorgang des Attributs erfüllt. Der Löschfilter selbst ist in dieser Situation nicht erfüllt, da das Objekt "Konzert X" an dem die Eigenschaft "Datum 19.10." gespeichert ist, gelöscht wird.

Die Verwendung von Löschfiltern ist z.B. dann sinnvoll, wenn das Trigger-Skript den Namen des Objektes aus dessen Eigenschaften zusammensetzt. So wird der Name Objektes nicht erst mehrmals geändert, wenn die Eigenschaften des Objekts gelöscht werden, sondern das Objekt und alle damit verbunden Eigenschaften werden gelöscht ohne, dass das Skript ausgeführt wird, welches den Namen zusammensetzt. Dies erspart i.d.R. unnötige Berechnungszeit und kann in bestimmten Anwendungsszenarien, z.B. wenn der Trigger eine E-Mail Benachrichtigung schickt, dass ein Objekt umbenannt wird, durchaus sinnvoll sein (, da so das Verschicken von zahlreichen überflüssigen E-Mails zur Namensänderung vermieden wird).

6.4 operation parameters

Operationsparameter steuern bei Suchfiltern, mit welchem Element das Ergebnis der Strukturabfrage für die Prüfung der Bedingung verglichen werden soll. Im einfachsten Fall wird das Ergebnis mit dem Element verglichen, mit dem die zu prüfende Operation durchgeführt werden soll. Mithilfe von Operationsparametern kann das übergebene Element verändert werden. Es kann der aktuelle Benutzer oder Elemente aus dem Umfeld des Elements ausgewählt werden, die als Vergleichselement für den Suchfilter verwendet werden sollen.

Sie werden unter anderem auch bei Löschfiltern und Skript-Triggern verwendet. Dort geben sie an, ausgehend vom Element auf dem der Zugriff durchgeführt wird, auf welchem Element das Skript ausgeführt werden soll bzw. das Löschen welchen Elements gefiltert werden soll.

Wann ist dies sinnvoll? Statt des betroffenen Objekts ein Element aus dessen Umgebung zum Vergleich herziehen zu können, ist in manchen Fällen unverzichtbar: z.B. wenn es darum geht Zugriffsrechte für das Anlegen neue Objekte oder Typen zu prüfen. Es ist nicht möglich eine Strukturabfrage zu definieren, die das noch nicht angelegte Objekt zurückliefert. In diesem Fall muss der Suchfilter gegen etwas anderes verglichen werden, nämlich gegen den Typ des anzulegenden Objekts und bei Objekttypen gegen den Obertyp des anzulegenden Typs.


Der (Ober)typ ist bei Typen der Obertyp des Typs. Bei Objekten ist der (Ober)typ der Typ des Objektes. Bei Attributen oder Relationen ist der (Ober)typ der Typ der Eigenschaft.

BenutzerDer Benutzer ist das Objekt des Benutzers, der die Operation ausführt.
EigenschaftDie Eigenschaft ist die von der Operation betroffene Eigenschaft (Attribut oder Relation). Wird die Operation an einem Objekt, Typ oder Erweiterung durchgeführt, ist der Operationsparameter Eigenschaft leer.
Inverse RelationFalls die von der Operation betroffene Eigenschaft eine Relation ist, enthält der Parameter die inverse Relationshälfte. 
Inverser Relationstyp

Der Inverse Relationstyp ist der Typ der inversen Relation. Dieser kann bei Erzeugung von Relationen verwendet werden.


Wenn das übergeordnete Element eine Erweiterung ist, dann ist das Kernobjekt das Objekt an dem die Erweiterung gespeichert ist. Ansonsten ist das Kernobjekt identisch mit Zugriffselement.

OrdnerDer Operationsparameter Ordner ist der von der Operation betroffene Ordner.

Bei Metaeigenschaften ist die Primäreigenschaft die dem Objekt, Typ oder Erweiterung nächste Eigenschaft. Ansonsten ist Primäreigenschaft identisch mit Eigenschaft. 

Primäres Kernobjekt

Wenn das Primärelement eine Erweiterung ist, dann ist das Primäre Kernobjekt das Kernobjekt der Erweiterung. Ansonsten ist das Primäre Kernobjekt identisch mit Kernobjekt.

Primäres RelationszielDas Primäre Relationsziel ist das Primärelement des Relationsziels.

Falls das übergeordnete Zugriffselement eine Eigenschaft ist, ist das Primärelement das Objekt, der Typ oder die Erweiterung an dem die Eigenschaft gespeichert ist (transitiv). Ansonsten ist das Primärelement identisch mit dem übergeordneten Element.

RelationszielFalls die von der Operation betroffene Eigenschaft eine Relation ist, enthält der Parameter Relationsziel das Relationsziel der Relationshälfte. (Die Relationsquelle wäre in diesem Fall das übergeordnete Element.)
Übergeordnetes ElementDas Übergeordnete Element ist das von der Operation betroffene Objekt, der Typ oder die Erweiterung. Bei Eigenschaften ist das Übergeordnete Element das Objekt, der Typ oder die Erweiterung an der die Eigenschaft gespeichert ist.
ZugriffselementDas Zugriffselement ist das von der Operation betroffene Element.


6.4.1 Access Object

Das Zugriffselement ist das Element aus dem semantischen Netz auf das gerade zugegriffen wird. Bei Suchfiltern im Rechtesystem ist das Zugriffselement beispielsweise das Element auf das durch eine Operation zugegriffen werden soll. Beim Prüfen einer Zugriffsituation wird dann das Element an den Suchfilter übergeben, an dem die Operation durchgeführt werden soll. Der Suchfilter vergleicht dann das Zugriffselement mit dem Ergebnis der Strukturabfrage.

6.4.2 User

Der Parameter Benutzer ist unabhängig vom Zugriffselement immer das Benutzerobjekt des aktuell angemeldeten Nutzers. Hierfür muss der Knowledge-Builder-Account mit einem Wissensnetzobjekt verknüpft werden. Wie die Verknüpfung vorgenommen wird, wird im Kapitel Aktivierung des Rechtesystems vorgestellt.

Objekt, Typ, Erweiterung oder EigenschaftObjekt des aktuell angemeldeten Nutzers


6.4.3 Superior Type

Der Parameter (Ober)typ wird beispielsweise dann verwendet, wenn im Rechtesystem Operationen geprüft werden sollen, die neue Elemente anlegen. Beim Anlegen von Elementen kann der Suchfilter nicht so definiert werden, dass er das noch nicht angelegte Element findet. Der Suchfilter muss auf dem Obertyp oder Typ des Elements arbeiten, welches angelegt werden soll. Bei der Erstellung von Objekten, Attributen und Relationen wird der Typ des Objektes, Attributes oder der Relation verwendet. Bei Typen wird der Obertyp des anzulegenden Typs verwendet.

Objekt oder ErweiterungDer Typ des Objektes oder der Erweiterung
TypDer Obertyp
EigenschaftDer Typ der Eigenschaft


6.4.4 Semantic Element

Das übergeordnete Element wird dann verwendet, wenn direkte Eigenschaften eines Elementes abgefragt werden sollen.

ZugriffselementÜbergeordnetes Element
Objekt, Typ oder ErweiterungDas Zugriffselement selbst
EigenschaftObjekt, Typ oder Erweiterung an dem oder der die Eigenschaft gespeichert ist
MetaeigenschaftEigenschaft, an der die Metaeigenschaft gespeichert ist


6.4.5 Property

Als Eigenschaften werden Attribute und Relationen verstanden. Der Operationsparameter enthält das Attribute oder die Relation auf der die Operation durchgeführt wird. Wird die Operation auf einem Objekt oder Typ durchgeführt, ist der Operationsparameter Eigenschaft leer.


Attribute oder Relation

Das Zugriffselement selbst
Objekt, Typ oder ErweiterungLeer


6.4.6 Inverse Relation

Die inverse Relation ist die "Gegenrichtung" einer Relationshälfte. Betrachtet man eine Relationshälfte als gerichteten Graphen, so besteht eine Relation aus zwei entgegengesetzten Graphen (der "Hinrichtung" und der "Rückrichtung" der Relation), die zwischen zwei Elementen aufgehängt ist. Die inverse Relation ist also die entgegengesetzte Relationshälfte. Die inverse Relationshälfte hat als Relationsziel die Relationsquelle der Relationshälfte und umgekehrt.

ZugriffselementInverse Relation
RelationshälfteDie inverse Relationshälfte
Objekt, Typ, Erweiterung oder AttributLeer


6.4.7 Inverse Relation Type

Der inverse Relationstyp ist der Typ der inversen Relation.

ZugriffselementInverser Relationstyp
RelationshälfteTyp der inversen Relationshälfte
Objekt, Typ, Erweiterung oder AttributLeer


6.4.8 Relation Target

Das Relationsziel ist nicht die Quelle sondern das "Ziel" einer Relationshälfte. Es kann auch als Relationsquelle der inversen Relationshälfte betrachtet werden.

RelationshälfteDas Relationsziel ist die Relationsquelle der inversen Relation
Objekt, Typ, Erweiterung oder AttributLeer


6.4.9 Primary Object

Das Primärelement liefert immer ein Objekt, Typ oder Erweiterung. Wird das Primärelement auf Metaeigenschaften ausgeführt, werden die Eigenschaften transitiv abgearbeitet, bis das Objekt, der Typ oder die Erweiterung gefunden wurde, an dem die Eigenschaften aufgehängt sind.

Objekt, Typ oder ErweiterungDas Zugriffselement selbst
EigenschaftObjekt, Typ oder Erweiterung an dem oder der die Eigenschaft gespeichert ist
MetaeigenschaftObjekt, Typ oder Erweiterung an dem oder der die Eigenschaft gespeichert ist, an der wiederum die Metaeigenschaft gespeichert ist (transitiv)


6.4.10 Primary Relation Target

Das primäre Relationsziel ist im Gegensatz zum Primärelement einer Relationshälfte nicht das Objekt, der Typ oder die Erweiterung an der die Relationshälfte angebracht ist sondern das Objekt, der Typ oder die Erweiterung an der die inverse Relationshälfte aufgehängt ist.

ZugriffselementPrimäres Relationsziel
RelationshälfteDas Primärelement des Relationsziels (Objekt, Typ oder Erweiterung an dem oder der die inverse Relationshälfte gespeichert ist)
Relationshälfte deren Relationsziel eine Eigenschaft oder Metaeigenschaft istDas Primärelement des Relationsziels (Objekt, Typ oder Erweiterung der Metaeigenschaft oder Eigenschaft an der die inverse Relationshälfte gespeichert ist)
Objekt, Typ, Erweiterung oder AttributLeer


6.4.11 Core Object

Das Kernobjekt wird verwendet, wenn mit Erweiterungen gearbeitet wird. Das Kernobjekt liefert anstatt der Erweiterung das Objekt, an dem die Erweiterung gespeichert ist.

Objekt, Typ oder EigenschaftDas Zugriffselement selbst
ErweiterungDas Objekt an dem die Erweiterung gespeichert ist


6.4.12 Primary Core Object

Wenn bei einem Element das zugehörige Objekt oder der zugehörige Typ verarbeitet werden soll, muss das primäre Kernobjekt verwendet werden. Im Gegensatz zum Primärelement werden keine Erweiterungen zugelassen. Bei diesen wird das Kernobjekt ausgegeben. 

ZugriffselementPrimäres Kernobjekt
ErweiterungDas Objekt an dem die Erweiterung gespeichert ist
Objekt oder TypDas Zugriffselement selbst

Eigenschaft oder Metaeigenschaft einer Erweiterung

Das Objekt an dem die Erweiterung gespeichert ist
Eigenschaft oder Metaeigenschaft eines Objektes oder TypsPrimärelement - Objekt oder der Typ an dem die Eigenschaft gespeichert ist (transitiv)


6.4.13 Primary Property

Die Primäreigenschaft ist immer eine Eigenschaft. Sie ähnelt dem Primärelement in der Hinsicht, dass sie transitiv Metaeigenschaften abarbeitet. Sie liefert aber im Gegensatz die letzte Eigenschaft die vor dem Primärelement kommt - also die Eigenschaft, die direkt am Primärelement gespeichert ist.

EigenschaftDas Zugriffselement selbst
Metaeigenschaft (oder Metaeigenschaft einer Metaeigenschaft)Die Eigenschaft, die dem Objekt, Typ oder der Erweiterung am nächsten ist
Objekt, Typ oder ErweiterungLeer


6.4.14 Folder

Soll ein Ordner aus dem Bereich Ordner des Wissensnetzes als Parameter an die Suche übergeben werden, dann muss der Operationsparameter Ordner verwendet werden.

OrdnerDas Zugriffselement selbst
Objekt, Typ, Erweiterung oder EigenschaftLeer


6.4.15 Examples

Beispiel 1: Zugriffselement und Eigenschaft im Rechtesystem

Das unten aufgeführte Beispiel zeigt auf der linken Seite die Zugriffsituation und auf der rechten Seite den dazugehörigen Suchfilter.

Zugriffsituation: Der Nutzer Paul möchte das Attribut Dauer von Song X ändern.

Suchfilter: Es werden alle Attribute gefiltert die, die von einem bestimmten Benutzer angelegt wurden. In der Strukturabfrage wird der Zugriffsparameter Benutzer verwendet, der die Objekte von Nutzer auf die Person einschränkt, welche die Operation ausführen möchte. Entsprechend sind das alle Attribute, die von Paul angelegt wurden.

Prüfung der Zugriffsrechte: Für die Prüfung der Zugriffsrechte wird das Attribut (das Zugriffselement/die Eigenschaft), an dem die Operation durchgeführt werden soll, an den Suchfilter übergeben. Ist dieses Attribut in der Menge der Suchergebnisse enthalten, dann ist die Prüfung des Suchfilters positiv. 

Operationsparameter: Das Attribut Dauer selbst wird an den Suchfilter übergeben. In diesem Fall könnte sowohl der Operationsparameter Zugriffselement als auch Eigenschaft verwendet werden, da das Attribut Dauer selbst eine Eigenschaft ist und das Zugriffselement der Operation darstellt.

Beispiel 2: Übergeordnetes Element und Primärelement im Rechtesystem

Dieses Beispiel zeigt auf der linken Seite die Zugriffsituation und auf der rechten Seite den dazugehörigen Suchfilter.

Zugriffssituation: Der Nutzer Paul nimmt eine Änderung des Attributes Dauer, das aktuell den Wert 02:30 annimmt und zum Objekt Song X gehört, vor.

Suchfilter: Der Suchfilter ist so definiert, dass er alle Objekte sucht, die von einem bestimmten Benutzer angelegt wurden, das ist als Zugriffselement der aktuell angemeldete Nutzer. Entsprechend findet der Suchfilter alle Objekte, die von Paul angelegt wurden.

Prüfung der Zugriffsrechte: Ist in der Ergebnismenge des Suchfilters der Song X enthalten, wird der nachfolgende Ordner (Filter oder Entscheider) ausgeführt.

Operationsparameter: Die Verwendung des Operationsparameter übergeordnetes Element führt dazu, dass nicht das Attribut Dauer an dem die Änderung stattfinden soll, an den Suchfilter übergeben wird, sondern das Objekt an dem es definiert wurde. Das ist in diesem Fall der Song X. Neben dem übergeordneten Element könnte in diesem Fall auch der Operationsparameter Primärelement verwendet werden. Der Operationsparameter übergeordnetes Element führt dazu, dass alle Eigenschaften und das Objekt selbst positiv von Filter bewertet würde. Zusätzlich würde der Operationsparameter Primärelement auch Metaeigenschaften des Objektes zulassen, egal wie viele andere Eigenschaften zwischen Objekt und Metaeigenschaft hängen.

Beispiel 3: (Ober)typ im Rechtesystem

Das Beispiel stellt auf der linken Seite die Zugriffsituation dar und auf der rechten Seite wird der Suchfilter abgebildet, der in dieser Situation zum Einsatz kommt.

Zugriffsituation: Der Nutzer Paul möchte das Attribut Dauer am Objekt Song X erstellen. Es soll den Wert 02:30 haben.

Suchfilter: Der Suchfilter liefert den Attributtyp Dauer.

Prüfung der Zugriffsrechte: Ist das zu erstellende Attribut vom Typ Dauer, dann fällt die Prüfung des Suchfilters positiv aus. 

Operationsparameter: Bei der Erstellung von Elementen, kann kein Suchfilter definiert werden, der das zu erstellende Element zurückliefert und damit die Zugriffsrechte prüfen kann. Bei der Erstellung von Elementen muss also ein anderer Operationsparameter als Zugriffselement ausgewählt werden. Der Operationsparameter (Ober)typ ist in diesen Situationen geeignet. In diesem Beispiel wird der Typ des Attributes verwendet, das ist der Attributtyp Dauer.

6.5 Operations

In Operationsfiltern können Operationen angegeben werden, die dann im Filterprozess von Operationsfilter zugelassen werden. Wird in der Zugriffssituation eine andere Operation ausgeführt, als im Operationsfilter angegeben, wird bei der Traversierung des Rechte bzw. Triggerbaumes zum nächsten Teilbaum gewechselt.

Die allgemeinen Operationen Erzeugen, Lesen, Modifizieren und Löschen bestehen aus mehreren einzelnen Operationen. Wird eine der Operationsgruppen verboten, werden somit auch alle darin enthaltenen Operationen nicht erlaubt und umgekehrt wird eine Operationsgruppe erlaubt, so werden alle enthaltenen Operationen automatisch mit erlaubt.

Die Tabelle zeigt eine Übersicht zu allen verfügbaren Operationen, die in Operationsfiltern ausgewählt werden können. Je nach Operation können nur bestimmte Operationsparameter in Suchfiltern verwendet werden. Diese werden in der Spalte Operationsparameter angegeben. 

Anmerkung: Abgeleitete Operationsparameter wie z.B. Primärelement oder primäres Kernobjekt können immer dann eingesetzt werden, wenn der Parameter von dem sie abgeleitet sind, verwendet werden kann.

Besonderheiten bei Triggern
Bei Triggern können keine lesenden Operationen verwendet werden. Außerdem stehen bei Triggern die Operationsgruppen Abfrage (Operation: In Strukturabfrage verwenden), Anzeige von Objekten (Operation: Im Grapheditor anzeigen) und Bearbeiten (Operation: Attributwert validieren) nicht zur Verfügung.

Außerdem steht bei den Erzeugen Operationen bei Triggern der Operationsparameter Zugriffselement zur Verfügung, wenn Zeitpunkt/Art der Ausführung auf Nach der Änderung oder Ende der Transaktion gesetzt ist.


AbfrageIn Strukturabfrage verwendenZugriffselement
Anzeigen von Objektenim Grapheditor anzeigenZugriffselement
BearbeitenAttributwert validierenZugriffselement, Eigenschaft, übergeordnetes Element, (zu prüfender Parameter: Attributwert)
Benutzerdefinierte Operation  
ErzeugenAttribut erzeugen(Ober)typ, übergeordnetes Element
Erweiterung erzeugen(Ober)typ, übergeordnetes Element, Kernobjekt
Objekt erzeugen(Ober)typ
Ordner erzeugenOrdner
Relation erzeugen(Ober)typ, übergeordnetes Element, Relationsziel, inverser Relationstyp
Relationshälfte erzeugen(Ober)typ, übergeordnetes Element, Relationsziel
Typ erzeugen(Ober)typ
Übersetzung hinzufügenZugriffselement, Eigenschaft, übergeordnetes Element
LesenAlle Objekte/Eigenschaften des Typs lesen(Ober)typ
Attribut lesenZugriffselement, Eigenschaft, übergeordnetes Element
Objekt lesenZugriffselement, übergeordnetes Element
Relation lesenZugriffselement, übergeordnetes Element, Eigenschaft, inverse Relation, Relationsziel, inverses Relationsziel
Typ lesenZugriffselement, übergeordnetes Element
LöschenAttribut löschenZugriffselement, übergeordnetes Element
Erweiterung löschenZugriffselement, Eigenschaft, übergeordnetes Element
Objekt löschenZugriffselement, übergeordnetes Element
Ordner löschenOrdner
Relationshälfte löschenZugriffselement, inverse Relation, Eigenschaft, übergeordnetes Element, Relationsziel, inverses Relationsziel
Typ löschenZugriffselement, übergeordnetes Element
Übersetzung entfernenZugriffselement, Eigenschaft, übergeordnetes Element
Arttributwert modifizierenZugriffselement, Eigenschaft, übergeordnetes Element
Ordner modifizieren


Schema modifizierenZugriffselement, übergeordnetes Element
Typ wechselnZugriffselement, übergeordnetes Element
Werkzeuge verwendenExport 
KScript bearbeiten/ausführen 


Objekt lesen
Die Operation Objekt lesen deckt das Anzeigen von Objekten auf dem Reiter Objekte bei dem enstprechenden Objekttyp ab. Die Operation verbietet aber nicht das Anzeigen des Objektes, wenn es über ein verknüpftes Objekt aufgerufen wird. In diesem Fall gelten dann die Operationen für Eigenschaften Attribut lesen und Relation lesen.

In Strukturabfrage verwenden
Ist ein negatives Zugriffsrecht für ein Element definiert, das auf die Operation In Strukturabfrage verwenden gefiltert wird, dann darf das Element nicht in einer Strukturabfrage verwendet werden. Es wird auch dann nicht in Strukturabfragen berücksichtigt, wenn der (abstrakte) Obertyp angegeben wird.  

Attributwert validieren
Die Operation Attributwert validieren wird dann verwendet, wenn der zu setzende Attributwert bestimmte Bedingungen erfüllen muss. Die Definition der Bedingung an den Attributwert wird in einer Strukturabfrage gemacht. Dort stehen für die Validierung des Attributwertes zwei Definitionsmöglichkeiten zur Verfügung:

  • Bedingung für den zu setzenden Attributwert:
    Der neue Wert des Attributes kann durch Vergleich mit einem angegebenen Wert in der Strukturabfrage validiert werden.

    Beispiel: Der Attributwert darf nur kleiner gleich 4,0 sein.
  • Vergleiche mit dem zu setzenden Attributwert:
    Hierbei wird der aktuelle Wert mit dem neuen Wert verglichen.

    Beispiel: Der neue Wert des Attributs Alter darf in diesem Fall nur größer werden. Kleinere Werte werden nicht zugelassen.

Für die Validierung stehen verschiedene Vergleichsoperatoren zur Verfügung, mit denen der zu setzende Attributwert gegen einen anderen Wert geprüft werden kann.
Entspricht der neue Wert nicht der definierten Bedingung, so ergibt die Prüfung des Filters ein negatives Ergebnis, sofern die initiale Einstellung Suchbedingung muss erfüllt sein ausgewählt ist.

Schema modifizieren
Die Operation Schema modifizieren, betrifft Änderungen am Definitionsbereich von Relationen und Änderungen an der Typenhierarchie (ist Untertyp von und ist Obertyp von Relationen).

6.5.1 *

In diesem Beispiel wird gezeigt wie Operationsgruppen (Lesen, Erzeugen, Modifizieren, Löschen) bei der Rechtedefinition sinnvoll eingesetzt werden können. Es sollen alle Operationen für den Typ Song und dessen Objekte verboten werden. Dies umfasst die folgenden Aktionen:

  • Das Löschen des Objekttyps Song
  • Das Löschen von bestimmten Songs (Objekte von Songs)
  • Das Löschen von Attributen, welches an einem Song vorkommt
  • Das Löschen von Relationen, die an einem Song vorkommt (Relationsziel und -quelle)
  • Das Löschen von Erweiterungen, die Objekte von Song erweitern
  • Das Löschen von Attribut- und Relationstypen die Objekte oder Untertypen von Song als Definitionsbereich haben

Sollen beispielsweise alle Löschen Operationen bei einem Objekt und dem dazugehörigen Typen verboten werden, muss man bei der Auswahl der Operationsparameter im Suchfilter des Rechtes darauf achten alle Löschen Operationen durch die entsprechenden Parameter abzudecken:

Der verwendete Suchfilter hat als einzige Bedingung den Objekttyp Song, bei dem die Einstellung Objekte und Untertypen ausgewählt ist. Der Operationsparameter Zugriffselement deckt den Objekttyp Song und alle Objekte, die zu diesem Typ gehören, ab. Der Parameter Kernobjekt deckt die Erweiterungsobjekte ab, die zu Songs gehören. Attribute und Relationen werden durch den Operationsparameter übergeordnetes Element abgedeckt.

Im Rechtebaum kommt der Operationsfilter der Operation Löschen an erster Stelle. Darauf folgt der unten abgebildete Suchfilter und als letztes der Entscheider Zugriff verweigert.

Im Beispiel verwendeter Suchfilter: Kernobjekt, übergeordnetes Element und Zugriffselement wurden als Operationsparameter ausgewählt. Die Einstellungen Ein Parameter muss zutreffen und Suchbedingung muss erfüllt sein werden verwendet.

Erweiterung des Rechtes um Attribut- und Relationstypen

Ein so definiertes Recht deckt die alle bis auf einen der oben formulierten Anforderungspunkte des Rechtes ab. Lediglich das Löschen von Attribut- und Relationstypen, die für Objekte und Untertypen von Songs definiert sind, wird in dieser Rechtedefinition nicht berücksichtigt.

Eine Erweiterung der Rechtedefinition wird durch den folgenden Filter realisiert:

Der Suchfilter erfasst alle Eigenschaftstypen (Attribut- und Relationstypen) die für Objekte bzw. Untertypen von Songs definiert sind. In der Suchfilterdefinition wird der Parameter Zugriffselement und die Einstellung Suchbedingung muss erfüllt sein verwendet.

6.6 Test Environment

Wird im Bereich System der Ordner Rechte ausgewählt, werden im Hauptfenster die Reiter Gespeicherte Testfälle und Konfigurieren angeboten. Der Bereich des Testsystems befindet sich im Reiter Gespeicherte Testfälle. Das Testsystem für Trigger wird über den Bereich System im Ordner Trigger aufgerufen.

Hier können die gespeicherten Testfälle erneut getestet werden. Die Testoberfläche in der die Testfälle definiert werden können, kann über die Schaltfläche Testumgebung öffnen aufgerufen werden.

Zusätzlich zu den Funktionalitäten, die in den folgenden Kapiteln Eine Zugriffssituation testen und Testfälle definieren beschrieben werden, gibt es die Möglichkeit direkt an einem Objekt oder Typ Zugriffsrechte zu testen. Über das Kontextmenü (rechte Maustaste) die Funktion Zugriffsrechte auswählen. Dort stehen die folgenden Menüpunkte zur Auswahl:

  • Objekt: Es werden alle Operationen (Modifizieren, Löschen, Lesen und im Graph-Editor anzeigen) am Objekt geprüft und deren Ergebnis ausgegeben.
  • Alles: Es werden alle Operationen (Modifizieren, Löschen, Lesen und im Graph-editor anzeigen) am Objekt und all dessen Eigenschaften (Attribute und Relationen) geprüft.
  • Testumgebung Berechtigungssystem: Die Testumgebung für die Rechteprüfung wird geöffnet.
6.6.1 Test Environment

Zum Testen des Rechtesystems und der Trigger-Funktionalität sind zwei Bereiche relevant:

  • Die Testumgebung selbst: Die Testumgebung bietet die Möglichkeit für einen bestimmten Testfall die Zugriffsrechte bzw. wann ein Trigger ausgeführt wird zu testen.
  • Der Reiter Gespeicherte Testfälle: Hier werden die Testfälle aufgelistet und für spätere Überprüfungen zur Verfügung gestellt.

Anleitung zum Öffnen der Testumgebung

  1. Wählen Sie im Knowledge-Builder im Bereich Technik den Ordner Rechte bzw. Trigger aus.
  2. Wenn Sie im Rechtesystem arbeiten, wählen Sie im Hauptfenster den Reiter Gespeicherte Testfälle aus.
  3. Klicken Sie Testumgebung öffnen (rechts unten) an, damit sich die Testumgebung in einem neuen Fenster öffnet.

Die Testumgebung besteht aus mehreren Bereichen: Im oberen Bereich wird der Benutzer und das Element definiert, an dem die Eigenschaft angebracht ist, die geprüft werden soll. Das Element kann ein Objektes, ein Typs oder eine Eigenschaft (wenn diese als Element übergeben wird) sein.

Der Bereich Eigenschaften listet alle Eigenschaften des ausgewählten Elements aus. Nicht kursive Eigenschaften, sind konkrete Eigenschaften, die bereits am Objekt oder der Eigenschaft vorliegen. Kursive Eigenschaften hingegen sind Eigenschaften, die vom Schema her angelegt werden können, aber noch nicht wurden. Soll die Erstellung einer neuen Eigenschaft getestet werden, muss die Eigenschaft in kursiv-Form ausgewählt werden. 

Im Fenster Operation kann die Operation ausgewählt werden, die getestet werden soll. Je nach ausgewählten Parametern, ist eine Rechteprüfung möglich oder nicht.

Beachte: Soll eine Eigenschaft einer Eigenschaft also eine Metaeigenschaft getestet werden, dann muss die Eigenschaft im Eigenschaftsfenster markiert werden und die Schaltfläche Als Element ausgewählt werden. Dann wird beispielsweise bei Relationen die konkrete Relation zwischen zwei Objekten oder Eigenschaften als Objekt ausgewählt. Jetzt stehen im Eigenschaftsfenster alle Eigenschaften der konkreten Relation zur Verfügung. (Dies geht auch mit Attributen.) Über die Schaltfläche Überg. Element kann dieser Schritt wieder rückgängig gemacht werden.

Das Ergebnis der Prüfung wird im unteren Fenster angezeigt. Hierfür muss die Schaltfläche Überprüfen ausgewählt werden. Das Ergebnisfenster zeigt alle getesteten Fälle an.

  • Element: das Objekt, der Typ oder die Eigenschaft an dem oder der die Eigenschaft definiert ist
  • Eigenschaft: die konkrete Eigenschaft die getestet werden soll (ist leer wenn kursive Eigenschaften getestet werden)
  • Operation: die Operation, die überprüft werden soll
  • Zugriff erlaubt: das Ergebnis der Prüfung des Testfalls
  • Entscheidungspfad: die entsprechenden Ordner, die zu dem Testergebnis führen
  • Zeit: die Zeit, die für die Rechteprüfung benötigt wurde

Beachte: Bei der Prüfung von Relationen werden i.d.R. die Relation, die inverse Relation und beide Relationshälften einzeln getestet. 

6.6.2 Define Testcases

Um die Funktionalität des Rechtesystems zu überwachen, können Testfälle gespeichert werden. Dies ist gerade dann wichtig, wenn Änderungen am Rechtesystem vorgenommen werden und hinterher geprüft werden soll, ob das neue Ergebnis noch dem erwarteten Ergebnis entspricht. Alle gespeicherten Testfälle werden auf dem Reiter Gespeicherte Testfälle angezeigt. Dort können alle Testfälle gleichzeitig geprüft werden.

Anleitung zur Definition eines Testfalls

  1. Wählen Sie in der Testumgebung das Element und die zu prüfende Eigenschaft aus.
  2. Wählen Sie die Operation aus, die getestet werden soll.
  3. Betätigen Sie die Schaltfläche Überprüfen. Jetzt werden die Zugriffsrechte für die abgegebenen Parameter getestet.
  4. Wählen Sie in der Ergebnisausgabe den Testfall aus, der gespeichert werden soll. (Es kann immer nur eine Operation als Testfall gespeichert werden.)
  5. Betätigen Sie die Schaltfläche Testfall. Der ausgewählte Testfall wird gespeichert und steht für spätere Prüfungen zur Verfügung.

Mehrere Testfälle gleichzeitig testen

Screenshot mit gespeicherten Testfällen, der zweite Testfall wird in Rot angezeigt.

In Grün werden alle Testfälle angezeigt, deren Testergebnis mit dem erwarteten Testergebnis übereinstimmen. Wird ein Testfall Rot angezeigt, dann ist das Ergebnis der Prüfung ein anderes als das erwartete Testergebnis. Das erwartete Testergebnis wird dadurch bestimmt, dass bei der Definition des Testfalls die Prüfung des Testfalls erstmalig durchgeführt wurde. Das Ergebnis dieser ersten Prüfung wird bei späteren Prüfungen des Testfalls als erwartetes Ergebnis angezeigt. Im Testsystem ist das erwartete Ergebnis entweder Zugriff erlaubt oder Zugriff verweigert; Bei Triggern ist das erwartete Ergebnis entweder Skript ausführen oder "nichts passiert" in Form eines Bindestriches.

Gespeicherte Testfälle können über Entfernen gelöscht werden. Soll ein Testfall bearbeitet werden, kann dies über die Schaltfläche Testumgebung öffnen gemacht werden. Der Testumgebung werden dann alle Parameter des Testfalls übergeben. 

7 View configuration
7.1 Basics

Die View-Konfiguration ermöglicht es verschiedene Sichten auf die Daten von k-infinity zu konfigurieren. Die konfigurierten Sichten kommen in Anwendungen zum Einsatz. Es können beispielsweise Teilausschnitte des semantischen Modells gezeigt oder bestimmte Zusammenstellungen der Daten (z.B. in Formularen, Tabellen, Ergebnislisten u.v.m.) erstellt werden.

So können wir u.a. folgende Fragen entscheiden und die entsprechend gewünschten Ansichten mit View-Konfigurationen erstellen:

Wie sollen die Eigenschaften von bestimmten Objekten dargestellt werden? In welcher Reihenfolge sollen die Eigenschaften dargestellt werden? Wenn wir ein neues Objekt anlegen, welche Attribute und Relationen sollen dann so dargestellt werden, damit sie auf keinen Fall übersehen und nicht ausgefüllt werden? Wie soll die Liste von Objekten zu einem Typ aussehen? Soll es überhaupt eine einfache Liste sein oder sollen die Objekte in Tabellen dargestellt werden? Welche Elemente sollen dann in den einzelnen Spalten zu sehen sein? Sollen Relationsziele direkt dargestellt werden? Oder nur bestimmte Attribute? Sollen wir verschiedene Reiter definieren, die zusammengehörige Eigenschaften und Attribute zusammenfassen? ...

Ein Beispiel: Konkrete Personen haben die Eigenschaften Name, Alter, Geschlecht, Adresse, Festnetznummer, E-Mail, Mobilnummer, Fax, kennt, ist befreundet mit und ist Kollege von. Nun könnten wir mithilfe der View-Konfiguration mehr Struktur in die Ansicht der Daten bringen, indem wir einen Reiter mit der Überschrift „Allgemeines“ definieren, der Name, Alter und Geschlecht zusammenfasst, einen mit der Überschrift „Kontaktdaten“, der Adresse, Festnetznummer, E-Mail, Mobilnummer und Fax beinhaltet und einen Reiter mit der Überschrift „Kontakte“, der die Eigenschaften kennt, ist befreundet mit und ist Kollege von enthält.

Beispiel einer View-Konfiguration. Oberer Screenshot: Unkonfigurierter Ausschnitt eines Objektes in der Graph-Ansicht mit allen seinen Eigenschaften. Unterer Screenshot: Konfigurierte Ansicht desselben Objektes, in der zusammengehörige Eigenschaften gruppiert, unwichtige Relationen weggelassen und Ähnlichkeitsbeziehungen direkt dargestellt sind.

Ein Spezialfall der View-Konfiguration ist die Konfiguration der Ansicht der Daten im Knowledge-Builder, denn auch der Knowledge-Builder ist eine Anwendung, in der verschiedene Sichten auf die Daten möglich sind. Hilfreich ist dies dann, wenn wir den Knowledge-Builder als Preview benutzen wollen, um bestimmte Konfigurationen auszuprobieren. Die View-Konfiguration im Knowledge-Builder eignet sich außerdem, wenn Daten systematisch erfasst werden sollen, denn dann kann man beispielsweise die Detailseiten von Objekten so konfigurieren, dass wichtige zu ergänzende Eigenschaften gut sichtbar abgefragt werden.

7.1.1 Creation of a View-Configuration - Step by Step

Anhand eines Beispiels aus einer Datenbank zu Reisezielen und Sehenswürdigkeiten wird hier gezeigt, wie eine View-Konfiguration Schritt für Schritt erstellt wird. Die Detailseite zu Sehenswürdigkeiten in einer Web-Anwendung zur Reise-Datenbank soll konfiguriert werden. Die unkonfigurierte Standard-Ansicht einer Sehenswürdigkeit (links), listet alle ihre Attribute und Relationen untereinander auf, was in diesem Fall weder sinnvoll noch attraktiv für Anwender ist:

Die konfigurierte Ansicht (rechts) zeigt hingegen nur relevante und nützliche Informationen zur Sehenswürdigkeit, stellt diese übersichtlich, geblockt und mit passenden Überschriften dar und beinhaltet zudem eine Relation, die eine indirekte Beziehung darstellt: dass das Ägyptische Museum in Kairo steht, bedeutet es befindet sich im Land Ägypten. Darüber hinaus wurden der Graph-Button zur Ansicht des Objektes in einer Graph-Ansicht und mehrere Reiter hinzugefügt ("Details", "Ähnliche Sehenswürdigkeiten" und "Suche"), mit denen die Anwender definierte Aktionen durchführen können. Im Folgenden wird erläutert, wie diese Konfigurationen im Einzelnen erstellt werden. Open the editor of the view-configuration

Wir wollen die Detail-Ansicht von Objekten des Typs "Sehenswürdigkeit" konfigurieren. Darum bewegen wir uns im Knowledge-Builder zum Typ "Sehenswürdigkeit", wählen dort den Reiter "Details" aus und klicken in der angezeigten Hierarchie dann unter "View-Konfiguration" -> "Objekt" auf "Details":

Unter "View-Konfiguration" stehen neben "Details" (von Objekten) noch andere Auswahlmöglichkeiten bereit:

  • Objekt -> Objektliste: Hier kann die Objektliste konfiguriert werden, die im Knowledge-Builder die Objekte des ausgewählten Typs anzeigt.
  • Typ -> Details: Hier kann die Detailansicht zu Typen konfiguriert werden.
  • Typ -> Objektliste: Hier kann die Objektliste der Untertypen des ausgewählten Typs konfiguriert werden, die im Knowledge-Builder zu sehen ist.

Mit einem Klick auf "Neu" können wir hier eine neue View-Konfiguration anlegen. Für eine View-Konfiguration der Art Details bei Objekten stehen in einem sich anschließend öffnenden Dialog sechs Typen der View-Konfiguration bereit, von denen man einen auswählen muss:

Wir benötigen den Typ "Gruppe", da wir verschiedenste Unterkonfigurationen in einer Ansicht zusammenfassen wollen. (Die anderen Typen sind im Kapitel Objektkonfiguration erklärt.)

Nachdem wir den Typ der Konfiguration ausgewählt haben sehen wir unsere neu angelegte View-Konfiguration im rechten Fenster. Für den Namen der View-Konfiguration wurde automatisch der Name des Typs übernommen, der in Spalte vier noch einmal zu sehen ist. Die zweite Spalte zeigt den Typ der View-Konfiguration. In der dritten Spalte "Kontext" wird angezeigt, in welcher Anwendung die View-Konfiguration zum Einsatz kommt. Da wir noch keine Anwendung definiert haben, ist die Spalte noch leer.

Mit einem Klick auf den Bearbeiten-Button oder einem Doppelklick auf die ausgewählte View-Konfiguration öffnen wir den Editor, mit dem wir die Ansicht konfigurieren können. Determining the application

Bevor wir eine Ansicht konfigurieren, gehen wir auf den Reiter "Verwendung" um dort die Anwendung festzulegen, in der die View-Konfiguration gültig ist. Die Anwendung legt man unter anwenden in fest:

Folgende Anwendungen sind bereits zu Anfang definiert:

  • Graph-Editor
  • Knowledge-Builder
  • Knowledge-Portal
  • Net-Navigator
  • Topic-Chooser
  • Viewkonfiguration-Mapper

Darüber hinaus können noch eigene Anwendungen definiert werden, die an dieser Stelle mit der View-Konfiguration verknüpft werden können.

Unter anwenden auf wird der Objekttyp angegeben, der in unserem Fall bereits übernommen ist. View-Konfigurationen können in anderen View-Konfigurationen wieder verwendet werden. Falls die View-Konfiguration Baustein einer anderen View-Konfiguration ist, wird dies unter [inverse] anwenden in angezeigt.

Die View-Konfiguration hat eine Baumstruktur. Unser "Wurzelelement" ist die von uns zu Anfang angelegte Gruppe. Darum genügt es, wenn wir nur hier Angaben zur Verwendung machen, da das Prinzip der Vererbung auch in der View-Konfiguration greift und das Wurzelelement die Verwendung an seine Unterelemente "vererbt". Configuring the flags

Um dem der erstellten Wurzelkonfiguration vom Typ Gruppe nun weitere Konfigurationselemente hinzuzufügen klicken wir "Objektkonfiguration neu anlegen" . Es öffnet sich ein Dialog, der alle möglichen Arten der View-Konfiguration anzeigt. (Die einzelnen Typen sind im Kapitel Objektkonfiguration erklärt.) 

Da wir eine Darstellung mit Reitern erstellen wollen, müssen wir das Konfigurationselemente "Alternative" anlegen.

Die einzelnen Reiter müssen nun unter der "Alternative" angelegt werden.

Der erste Reiter soll die Details der Sehenswürdigkeit zum Inhalt haben, also die wichtigen direkten Attribute und Relationen (Beschreibungstext, Bild, Themen, etc.). Hierfür könnten wir demnach das Konfigurationselement "Eigenschaften" wählen, mit dem man einzelne Eigenschaften eines Objekttyps anzeigen lassen kann. Da wir allerdings noch Überschriften definieren und eine einzelne indirekte Relation abbilden wollen, benötigen wir stattdessen ein weiteres Konfigurationselement des Typs "Gruppe".

Der zweite Reiter soll ähnliche Sehenswürdigkeiten anzeigen, die mithilfe einer Ähnlichkeitssuche berechnet werden und der dritte Reiter soll die Suchfunktion der Web-Anwendung zugänglich machen. Für beide Reiter müssen wir demnach jeweils ein Konfigurationselement des Typs "Suche" wählen. 

Wir müssen uns zu jedem Reiter eine passende Beschriftung überlegen, denn ohne Beschriftung kann der Reiter in der Anwendung nicht angezeigt werden. Diese können wir unter "Konfiguration" bei Beschriftung eintragen.

Wenn wir die View-Konfiguration nun über den Button "View-Konfigurationen aktualisieren" aktualisieren, können wir das Ergebnis in unserer Web-Anwendung betrachten:

Wir sehen, dass die Beschriftung nicht nur als Beschriftung der Reiter dient, sondern auch als Überschrift bei einem ausgeklappten Reiter. Wenn wir dieses im Prinzip doppelte Vorkommen der Überschrift nicht wollen, können wir jedem Reiter eine Style-Eigenschaft geben, die die Überschrift versteckt. Dazu müssen wir bei dem jeweligen Konfigurationselement unter "Aktionen und Styles" mithilfe des Knopfes "Style hinzufügen"   das Style-Element "hideLabel" auswählen.

Das Ergebnis: unsere drei Reiter sind fertig konfiguriert. Mit dem Style-Element hideLabel können wir Beschriftungen verstecken. Configuring direct properties

Nun wollen wir festlegen, welche Attribute und Relationen der Objekte des Typs Sehenswürdigkeit in dem Reiter "Details" zu sehen sein sollen. Den Reiter "Details", haben wir in unserem Konfigurationsbaum bereits als Gruppe definiert. Das Unterelement, das wir nun benötigen ist "Eigenschaften". Dieses Element dient dazu die verschiedenen Eigenschaften eines Objektes in einer Liste untereinander darzustellen. Mit einem weiteren Klick auf den Button "Eigenschaft neu anlegen" , fügen wir der Eigenschaftsliste nun eine Eigenschaft hinzu. Damit haben wir in unserem Baum ein Blatt erreicht, d.h. wir sind an einem Punkt angelangt, bei dem wir schließlich eine Eigenschaft festlegen, die in einer Anwendung dargestellt werden soll. Wir können hier keine weiteren Unterelemente mehr anlegen.

Unter Eigenschaft müssen wir festlegen, welche Eigenschaft angezeigt werden soll. Eine Eigenschaft kann ein Attribut, eine Relation oder eine Abkürzungsrelation sein. Alle Einstellungsmöglichkeiten werden in Kapitel Eigenschaft erläutert.

So definieren wir alle Eigenschaften der Sehenswürdigkeit, die wir für die Anwendung als sinnvoll erachten. Die Reihenfolge, wie wir sie im View-Konfigurationsbaum sehen ist dieselbe, wie wir sie nach der Aktualisierung über den Button "View-Konfigurationen aktualisieren"  sehen:

Um sie Ansicht noch etwas schöner zu gestalten, können wir verschiedene Style-Elemente verwenden:

  • Mit dem Style-Element HideLabel können wir die Namen der Eigenschaften verstecken.
  • Mit dem Style-Element H1 können wir den Namen der Sehenswürdigkeit wie eine Überschrift darstellen.
  • Mit dem Style-Element Html können wir den Text des Wiki-Textes ohne die HTML-Codes ausgeben.

Mithilfe weiterer Eigenschaftslisten stellen wir nun noch die Themen der Sehenswürdigkeiten, sowie die Schöpfer und den Ort dar. Configuring indirect properties

Wenn wir wissen, in welcher Stadt sich eine Sehenswürdigkeit befindet, wissen wir auch in welchem Land sie sich befindet, auch wenn das Land nicht direkt mit der Sehenswürdigkeit verbunden ist. Diese indirekte Beziehung zwischen Sehenswürdigkeit und Land können wie auch mit der View-Konfiguration darstellen. Dazu brauchen wir ein Konfigurationselement des Typs "Suche", denn hier können wir eine beliebige Abfrage, also auch die hierfür benötigte Strukturabfrage, definieren:

Die Strukturabfrage muss so aufgebaut sein, dass das gewollte Ergebnis, bzw. die gewollten Ergebnisse, Ausgangspunkt der Strukturabfrage sind. Das Objekt Sehenswürdigkeit wird mit einem Parameter versehen.

Der Parameter des Objekts muss ebenfalls in der View-Konfiguration angegeben werden. Ob der Wert über ein Skript oder über eine Benutzereingabe ermittelt werden soll, muss unter Wertermittlung angegeben werden. Ein Skript, das das Element des Parameters zurückgibt, wird ebenfalls benötigt. Als Typ muss angegeben werden, dass es sich um ein Element des semantischen Modells handelt (k:element). Ausführlichere Erklärung zu diesen und den weiteren Einstellungsmöglichkeiten sind im Kapitel Suche nachzuschlagen.

Unter Tabelle wird definiert, wie (d.h. mit welchen Eigenschaften) das Ergebnis, bzw. die Ergebnisse der Suche dargestellt werden sollen. Hier können ebenfalls Style-Elemente angegeben werden. Wir verwenden das Style-Element MediaList, welches die Ergebnisse mit Namen und dem Icon ihres Objekttyps darstellt. Alle Details zur Konfiguration einer Ergebnistabelle sind im Kapitel Tabelle nachzuschlagen.

Das Style-Element MediaList ermöglicht eine alternative Darstellung von Ergebnissen einer Abfrage

Prinzipiell funktioniert die Einstellung der Konfiguration von ähnlichen Sehenswürdigkeiten genau wie die Konfiguration der indirekten Eigenschaft "Land", mit dem einzigen Unterschied, dass hier eine Such-Pipeline anstelle einer Strukturabfrage verwendet wird, um beispielsweise die fünf ähnlichsten Sehenswürdigkeiten auf Grundlage von Themen, Schöpfer und Ort zu berechnen. Configuring Queries

Der letzte Reiter unserer Anwendung soll eine Suche beinhalten. 

Den Reiter "Suche" haben wir in unserem Konfigurationsbaum bereits als Konfigurationselement vom Typ "Suche" definiert. Hier legen wir in einer Strukturabfrage fest, dass die Namen aller konkreten Objekte der Datenbank mögliche Ergebnisse sein können. Der Wert des Namens wird über den Parameter q definiert. Der Parameter q soll nicht zwischen Groß- und Kleinschreibung einer Benutzereingabe unterscheiden und wenn der Benutzer ein Wort eines zusammengesetzten Begriffes eingibt (z.B. "Museum"), so sollen alle Objekte, bei denen dieses Wort im Namen vorkommt, in der Ergebnisliste erscheinen (z.B. "Ägyptisches Museum"). Dies wird durch den Operator Enthält Zeichenkette (strings to words filter (Beschreibungstexte bereinigen)) in der Strukturabfrage festgelegt.

Im Editor der View-Konfiguration des Reiters "Suche" muss der Parameter q noch unter Parametername angegeben werden. Hier muss zudem definiert werden, dass sich der Wert des Parameters über die Benutzereingabe ermittelt und dass die Benutzereingabe eine beliebige Zeichenkette sein kann (Typ xsd:string).

Wie die Ergebnisliste dargestellt werden soll, wird wieder über das Element Tabelle konfiguriert. In unserem Fall wird hier eine Tabelle angelegt, die lediglich die Namen der Ergebnisse zeigt und das Style-Element MediaList verwendet.

7.1.2 Useage of View-Configurations
7.1.3 Validity of View-Configurations
7.2 Types of view configuration
7.2.1 Semantic element configuration

Eine Detailkonfiguration beschreibt, wie Objekte oder Typen dargestellt werden sollen. Im folgenden werden die verschiedenen Detailkonfigurationsarten, die der View-Konfiguration zur Verfügung stehen, beschrieben.

Die einzelnen Detailkonfigurationen lassen sich teilweise beliebig zusammenstecken. Ebenfalls können die Konfigurationen mehrfach als Unterkonfiguration verwendet werden.

Liste der verschiedenen Detailkonfigurationstypen


Top-Level-Konfiguration Kann folgende Unterkonfiguration enthalten
Alternative  x  beliebig
Eigenschaften  x  Eigenschaft
Gruppe  x  beliebig
Hierarchie  x  beliebig
Skriptgenerierter Inhalt  x  
Statischer Text    
Suche   Tabelle


Einstellungsmöglichkeiten, die alle Detailkonfigurationstypen gemeinsam haben

Name Wert
Konfigurationsname Findet keine Verwendung im Userinterface. Der Ersteller einer Konfiguration hat hier die Möglichkeit einen für ihn verständlichen Namen zu vergeben, um diese Konfiguration später besser wiederfinden und in anderen Konfigurationen wieder verwenden zu können.
Skript für Fenstertitel

Nur zur Verwendung im Knowledge-Builder. Öffnet man ein Objekt beispielsweise per Doppelklick in der Objektliste, öffnet sich ein Fenster mit den Eigenschaften dieses Objektes. Der Titel dieses Fensters kann durch ein Skript bestimmt werden.

Anmerkung: In den folgenden Abschnitten werden die Einstellungsmöglichkeiten für die einzelnen Konfigurationstypen beschrieben. Die obligatorischen Parameter sind fett gedruckt. Alternative

Eine Alternative verwenden wir, um beliebig viele verschiedene alternative Ansichten auf ein Objekt zu konfigurieren. Die alternativen Ansichten können in der Anwendung mittels Reitern ausgewählt werden. Zur Beschreibung, wie man eine Alternative anlegt, siehe Kapitel Reiter konfigurieren.


BeschriftungEine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. einer weiteren Alternative eingebettet ist.
hat Default-AlternativeDie Unteransicht, die initial selektiert sein soll, kann hier festgelegt werden.


Darstellung in einer Anwendung

Werden die Ansichten in JSON herausgeschrieben, werden die einzelnen Unteransichten in einem ARRAY an den KEY alternatives gehängt.

Beispiel einer Alternative in einer Anwendung: Mittels der Reiter kann zwischen den Ansichten "Details", "Ähnliche Sehenswürdigkeiten" und "Suche" gewechselt werden.


Darstellung im Knowledge-Builder

Im Knowledge-Builder werden dem Anwender die verschieden konfigurierten und mit der Alternative verknüpften Ansichten eines Objekts durch Reiter zur Verfügung gestellt.

Beispiel einer Alternative im Knowledge-Builder: Mittels der Reiter kann zwischen der Ansicht "Details" und der Ansicht "Wiki-Verweise" gewechselt werden.


Diese Konfiguration ist ähnlich der Konfiguration Gruppe. Allerdings werden bei einer Gruppe alle Unteransichten gleichzeitig angezeigt. Property

Mit der View-Konfiguration Eigenschaft kann definiert werden, wenn beispielsweise eine abstrakte Eigenschaft benutzt wird, die eine Menge von Eigenschaften zusammenfasst, angezeigt werden soll.


Name Wert
Absteigend sortieren Steuert, ob die Eigenschaften auf- oder absteigend nach ihrem Namen sortiert werden. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert.

Steht in zwei Fällen zur Verfügung:

1. Die Eigenschaft ist eine Relation:

Auswahlmöglichkeit für die Darstellung der Beschriftung eines Relationsziels. Diese Einstellungsmöglichkeit steht nur dann zur Verfügung, wenn die Einstellung Relationszielansicht den Wert Auswahl oder Relationsstruktur hat.

2. Die Eigenschaft ist ein Datei-Attribut:

Auswahlmöglichkeit für die Darstellung des Wertes eines Datei-Attributs.


  • Symbol (topicIcon): Icon des Relationsziels/die Datei als Icon
  • Symbol und Zeichenkette
  • Zeichenkette (Namensattribut): Name des Relationsziels/Name der Datei
Beschriftung Anzeigename der Eigenschaft. Ist keine Beschriftung angegeben wird der Name des Eigenschaftstyps ausgegeben.
Eigenschaft Verknüpfung zu einem Eigenschaftstyp, der angezeigt werden soll.
Skript für virtuelle Eigenschaften Alternativ zu 'Eigenschaft': Skript zur Berechnung anzuzeigender Werte
Einblendung des Relationsziels

Standardmäßig wird lediglich der Name des Relationsziels angezeigt. Wird der Name angeklickt, öffnet sich das Relationsziel in einem weiteren Editor.

Wird hingegen die Option Einblendung des Relationsziels gewählt, werden die Relationsziele direkt angezeigt, d.h. nicht nur ihr Name, sondern alle ihre Eigenschaften.

Einblendung zusätzlicher Eigenschaften

Nur bei der Ansicht zum Bearbeiten von Objekten relevant: Ist diese Option gesetzt, wird zu der Eigenschaft eine weitere Eigenschaft eingeblendet, sodass diese bequem und schnell ausgefüllt werden kann. Die Eigenschaft muss mehrfach vorkommen dürfen.

Einblendung zusätzlicher neuer Eigenschaften

Nur bei der Ansicht zum Bearbeiten von Objekten relevant: Ist diese Option gesetzt, wird die Eigenschaft nur dann eingeblendet, wenn die Eigenschaft noch nicht angelegt wurde. So kann sie bequem und schnell ausgefüllt werden und wird nicht so leicht vergessen.


Nur bei der Ansicht zum Bearbeiten von Objekten relevant: Mit dieser Option kann eine Verknüpfung zur einer Abfrage, die entscheidet, ob diese Konfiguration angezeigt wird, angelegt werden. Die Abfrage wird mit dem Objekt dieser Eigenschaft gefüllt. Nur, wenn die Abfrage ein Ergebnis enthält, wird die Eigenschaft zum bearbeiten angezeigt.
Konfiguration für eingebettete Metaeigenschaften

Angabe der Konfiguration, die verwendet werden soll, um Metaeigenschaften anzuzeigen. Die Metaeigenschaften werden eingebettet, d.h. hinter dem Wert der Eigenschaft angezeigt. Der Name des Eigenschafttyps wird nicht angezeigt.

Konfiguration für Metaeigenschaften

Angabe der Konfiguration, die verwendet werden soll, um Metaeigenschaften anzuzeigen. Die Metaeigenschaften werden unter dem Wert der Eigenschaft angezeigt.


Wird als Eigenschaft eine Relation gewählt, kann mit diesem Parameter die Ansicht der Relationsziele definiert werden:

  • Auswahl: Alle Relationsziele werden aufgelistet und mit einer vorangestellten Checkbox angezeigt. Bei bestehenden Relationen ist die CheckBox mit einem Häkchen versehen.
  • Drop Down: Diese Einstellung ist nur sinnvoll, wenn die Relation nur einmal vorkommen darf. Es wird eine Drop Down-Liste mit allen möglichen Relationszielen zur Auswahl angezeigt.
  • Relationsstruktur: Alle Relationsziele werden im linken Bereich aufgelistet, ähnlich einer Hierarchie, angezeigt. Im rechten Bereich ist dann die Detailansicht des selektierten Relationsziels zu sehen. Diese Ansicht kommt nur zur Geltung, wenn die Konfiguration direkt einer Top-Level-Konfiguration untergeordnet ist.
  • Tabelle: Tabellenansicht der Relationen. Die Tabellenansicht kann nicht im Knowledge-Builder angewendet werden. Für die Tabellenansicht muss die Einstellung Tabelle ausgefüllt werden.
  • Tabelle (Relationsziele): Tabellenansicht der Relationsziele. Diese Tabelle kann im Knowledge-Builder angewendet werden.
Skript für Sortierung Anhand des Skriptes wird ein Wert, nach dem sortiert wird, ermittelt. Siehe Beispiel unten.
Suche zur Zielauswahl Die Suche bestimmt, welche Wissensnetzelemente als mögliche Relationsziele angeboten werden. Zur Konfiguration der Suche, siehe auch Kapitel Suchen/Abfragen.
Tabelle Steht nur zur Verfügung, wenn Relationszielansicht den Wert Tabelle, bzw. Tabelle (Relationsziele) hat und ist dann obligatorisch. Die hier angegebene Tabellenkonfiguration gibt an, welche Eigenschaften der  Relationsziele tabellarisch ausgegeben werden sollen. Um das Relationsziel anzuzeigen muss mindestens sein Name in der Tabelle konfiguriert werden. Zur Konfiguration einer Tabelle, siehe Kapitel Tabelle.

Beispiel für Skript für Sortierung

Vorbedingung: An allen Eigenschaften kann das Attribut sortKey angebracht werden.

function sortKey(element)
    if (element instanceof $k.Property)
        var attribute = element.attribute('sortKey')
        if (attribute)
            return attribute.value();
    if (element instanceof $k.Domain)
        var attribute = element.type().attribute('sortKey');	
        if (attribute)
            return attribute.value();
    return undefined;

Eigenschaftsanzeige einer Person

Anmerkung: Beim Attributtyp Vorname ist für sortKey der Wert 20 eingetragen, daher steht dieser vorläufige Wert am Ende der Liste. Properties

Die Konfiguration Eigenschaften ist im Prinzip eine Liste von einzelnen Eigenschaften. Die Unterkonfigurationen können ausschließlich vom Typ Eigenschaft sein.


Name Wert
Beschriftung Anzeigename der Sammlung von Eigenschaften. Ist keine Beschriftung angegeben wird im Knowledge-Builder die Zeichenkette 'Eigenschaften' verwendet.
Initial ausgeklappt

Ist diese Konfiguration z.B. als Metakonfiguration eingehängt, kann mit diesem Parameter bestimmt werden, ob diese beim Öffnen des Knowledge-Builder-Editors bereits ausgeklappt sein soll.

Achtung: Das Front-End stellt die betroffene Metaeigenschaft gar nicht dar, wenn der Haken hier nicht gesetzt ist.

Einstellungsmöglichkeiten für die Sortierung

Name Wert
Absteigend sortieren Steuert, ob auf- oder absteigend sortiert wird. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert.
Primäres Sortierkriterium

Auswahlmöglichkeit für das Kriterium, nach dem die Eigenschaften sortiert werden:

  • Position: Die in der Konfiguration festgelegte Reihenfolge wird verwendet (Default).
  • Wert: Inhalt des Attributes bzw. Anzeigename des Relationszieles wird verwendet.
  • Skript zur Sortierung: Das in dem Attribut Skript zur Sortierung hinterlegte Skript wird zur Ermittlung des Sortierkriteriums verwendet.
Sekundäres Sortierkriterium Sortierkriterium für Eigenschaften, die für das primäre Sortierkriterium den gleichen Wert haben. Einstellmöglichkeiten analog zum Primären Sortierkriterium
Skript zur Sortierung Verweis auf ein registriertes Skript, das den Sortierschlüssel für das primäre bzw. sekundäre Sortierkriterium zurückgibt.

Darstellung in Anwendungen

Die Ansichten der Unterkonfiguration einzelner Eigenschaften werden in einem ARRAY abgelegt und mit dem KEY properties angehängt.

Darstellung im Knowledge-Builder

Die in der Konfiguration eingestellte Beschriftung wird prominent angezeigt. Ihm folgen die Ansichten der konfigurierten Eigenschaften.


Meta-Eigenschaften werden mit dem gleichen Vorgehen angehängt. Group

Mit Hilfe der Gruppe lassen sich verschiedenste Unterkonfigurationen in einer Ansicht zusammenfassen. Ausnahme, die nur für Front-End gilt: Das Element Eigenschaft kann keine direkte Unterkonfiguration von Gruppe sein. Hierfür braucht es zunächst die Konfiguration Eigenschaften.


BeschriftungEine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.

Darstellung in einer Anwendung

Wird die Ansicht in JSON herausgeschrieben, werden die einzelnen Unteransichten in einem ARRAY an den KEY group angehängt.

Darstellung im Knowledge-Builder

Im Knowledge-Builder wird um eine Gruppe ein Rahmen gezeichnet. Die Ansichten der Unterkonfigurationen werden dann in diesem Rahmen angezeigt.

Eine Gruppe mit folgenden Unterkonfigurationen: der Eigenschaftsliste "Bild und Text", der Eigenschaftsliste "Eigenschaften" und der Suche "Ähnliche Sehenswürdigkeiten" Hierarchy

Der Konfigurationstyp "Hierarchie" stellt Elemente eines semantischen Modells hierarchisch dar.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Skript für Beschriftung Es ist auch möglich durch ein Skript eine Beschriftung festzulegen.
Banner der Hierarchiewurzel anzeigen Betrifft nur den Knowledge-Builder: Banner wird angezeigt.
Detailansicht ausblenden Standardmäßig wird die Detailansicht eines ausgewählten Objektes angezeigt (Knowledge-Builder) oder ausgegeben (json, als subview). Durch Aktivieren dieser Option wird keine Detailansicht angezeigt bzw. ausgegeben.
Subkonfiguration Wird eine Detailansicht angezeigt, muss die View-Konfiguration für diese Detailansicht hier angegeben werden.
Unterelemente erzeugen ohne Frage nach Namen Wenn neue Unterelemente in der Hierarchie erzeugt werden, wird standardmäßig gefragt, wie ihr Name lauten soll. Ein Häkchen hier, erzeugt ohne Frage nach Namen namenlose Objekte.
Verbiete manuelles Sortieren Standardmäßig kann der Anwender im Knowledge Builder Elemente dem Schema entsprechend durch Drag&Drop umhängen. Wird diese Option aktiviert, ist dies nicht mehr möglich.

Einstellungsmöglichkeiten für die Sortierung

Name Wert
Absteigend sortieren Steuert, ob auf- oder absteigend sortiert wird. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert.
Primäres Sortierkriterium

Auswahlmöglichkeit für das Kriterium, nach dem die Eigenschaften sortiert werden:

  • Position: Die in der Konfiguration festgelegte Reihenfolge wird verwendet (Default).
  • Wert: Inhalt des Attributes bzw. Anzeigename des Relationszieles wird verwendet.
  • Skript für Sortierung: Das in dem Attribut Skript zur Sortierung hinterlegte Skript wird zur Ermittlung des Sortierkriteriums verwendet.
Sekundäres Sortierkriterium Sortierkriterium für Eigenschaften, die für das primäre Sortierkriterium den gleichen Wert haben. Einstellmöglichkeiten analog zum Primären Sortierkriterium.
Skript für Sortierung Verweis auf ein registriertes Skript, das den Sortierschlüssel für das primäre bzw. sekundäre Sortierkriterium zurückgibt.

Ermittlungsmöglichkeiten der hierarchiebildenden Elemente

Name Ermittlung von ...
Relation (absteigend) Unterelementen
Relation (aufsteigend) Oberelementen
Strukturabfrage (absteigend) Unterelementen
Strukturabfrage (aufsteigend) Oberelementen
Skript (absteigend) Unterelementen
Skript (aufsteigend) Oberelementen

Aktionen und Styles

Es lassen sich sowohl für die gesamte Hierarchie als auch für die einzelnen Knoten Aktionen und Styles anbringen.

Darstellung in einer Anwendung

Erst ab Version 4.1 gibt es die JSON-Repräsentation einer Konfiguration vom Typ Hierarchie.

Darstellung im Knowledge-Builder

In der Detail-Anzeige eines Elements wird im linken Bereich eine Hierarchie eingeblendet. Im rechten Bereich wird das Element mit einer View-Konfiguration ohne Hierarchie angezeigt. Diese View-Konfiguration muss eigens definiert werden und unter Verwendung >> anwenden in muss der Konfigurationsname der Hierarchie angegeben werden. Die Subkonfiguration lässt sich alternativ auch direkt an der Hierarchie unter Subkonfiguration angeben.


  • Die Werte aller Eigenschaften, die für die Hierarchiebildung ausgefüllt werden können, sind Relationen.
  • Die einzelnen Attribute wie z.B. Relation - absteigend können mehrfach vergeben werden.
  • Für jeden Attributtyp werden die Relation oder Relationen ermittelt und aufgesammelt. Sind verschiedene Attributtypen angegeben, wird mit den Teilmengen eine Schnittmenge gebildet.

Beispiel - Anwendungsfall

Typischerweise werden Hierarchien verwendet, um Ober-/Unterthema-Relationen oder Teil-von-Relationen darzustellen.

1. Hierarchiebildende Relation

Die direkteste Variante. Die Relationen, die die Hierarchie bilden, werden eingetragen.

2. Hierarchiebildende Strukturabfrage

Die Relationen lassen sich ebenfalls über eine Strukturabfrage ermitteln.

3. Hierarchiebildendes Skript

Auch durch ein Skript lassen sich die möglichen hierarchiebildenden Relationen aufsammeln.

Skript hat Oberthema

function relationsOf(element)
    return element.relations('hatOberthema');
} Script generated content

Eine durch ein Skript generierte HTML-Beschreibung wird an dieser Stelle angezeigt.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Skript Zur Generierung einer HTML-Beschreibung



function render(topic, document)
	var writer = document.xmlWriter();

Generierter Inhalt



Hermann Static text

Ein nicht veränderlicher Text wird ausgegeben.


BeschriftungEine Beschriftung wird nur ausgegeben, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
TextText, der ausgegeben werden soll Query

Das View-Konfigurationselement "Suche" kann als Unterkonfiguration einer Alternative oder einer Gruppe ausgewählt werden. Eine beliebige Abfrage ist hier obligatorisch, deren Ergebnisse angezeigt werden. Ein Beispiel, wie man eine solche Suche anlegt wurde bereits in Kapitel Indirekte Eigenschaften konfigurieren gegeben. Auch Suchen zur Benutzereingabe können konfiguriert werden. Ein Beispiel hierfür findet sich in Kapitel Suchen konfigurieren.



Hier kann die Suche ausgewählt werden, die sofort ausgeführt wird. Das semantische Objekt für welches die View-Konfiguration angezeigt wird, kann als Zugriffselement in der Abfrage verwendet werden.

BeschriftungEine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.

Einstellungsmöglichkeiten für eine Abfrage

Die folgenden Parameter werden als Meta-Eigenschaften für eine Abfrage gepflegt.

ParameternameAngabe eines Parameternamens, wie er in der Abfrage verwendet wird.

Einstellungsmöglichkeiten für einen Parameternamen

Die folgenden Parameter werden als Meta-Eigenschaften für einen Parameternamen gepflegt:

SkriptDas Skript parameterValue wird zur Ermittlung des Suchwertes für den angegebenen Parameternamen verwendet.

Angabe über den Weg der Wertermittlung

Skript: Der Wert wird aus dem Skript ermittelt und darf nicht von einem Benutzer überschrieben werden.

Skript, überschreibbar: Das Skript ermittelt Wert. Der Benutzer darf überschreiben.

Benutzereingabe: Keine Skriptauswertung. Nur Eingabe durch einen Benutzer.

BeschriftungBeim Herausschreiben nach JSON landet dieser Wert in label.

Darstellung in einer Anwendung

Eine Ausgabe für die Suchergebnisse gibt es erst ab Version 4.1 von k-infinity.

Darstellung im Knowledge-Builder

Die Ergebnisse einer beliebigen Abfrage werden im Knowledge-Builder stets in einer Objektliste angezeigt.


In der View-Konfiguration werden die Reiter "Eigenschaften" und "Bekannte" definiert. "Bekannte" ist ein Konfigurationselement des Typs "Suche. Unter "Abfrage" kann eine Suche ausgewählt oder direkt neu angelegt werden.

Definition der Suche

Das Ergebnis der Abfrage wird im Reiter "Bekannte" bei Objekten des Typs "Person" im Knowledge-Builder angezeigt.

7.2.2 Table

Tabellen können als Unterkonfiguration für die Ergebnisanzeige von Abfragen des Konfigurationstyps "Suche" oder als eigenständige Konfiguration zur Darstellung der Objektlisten im Knowledge-Builder verwendet werden.

Eine Tabelle listet konkrete Objekte, Eigenschaften oder Untertypen eines bestimmten Typs auf. Ob alle Objekte, Eigenschaften oder Untertypen oder nur eine Auswahl angezeigt werden, lässt sich über die Eingabe in den Spaltenköpfen steuern. Mit den eingegebenen Werten wird eine Strukturabfrage nach passenden Objekten, Eigenschaften oder Untertypen ausgeführt und das Ergebnis tabellarisch dargestellt. Außerdem kann bei Objektlisten nach Eingabe von Werten in die Spaltenköpfe ein neues Objekt, ein neuer Eigenschaftswert oder ein neuer Untertyp mit den ausgefüllten Eigenschaften erzeugt werden.

Bestandteile der Konfiguration Tabelle sind Spaltenkonfigurationen. Diese wiederum beinhalten Spaltenelemente. Diese Aufteilung dient der Trennung von spaltenrelevanten Eigenschaften, wie Reihenfolge und Benennung der Spalte in der Tabelle, und der Zuordnung, welche Inhalte in der Spalte angezeigt werden sollen. Spaltenelemente wiederum erlauben die Zuordnung von Eigenschaften, zusätzlich können Skript-Bausteine und Strukturabfrage-Bausteine eingebettet werden.

Die hierarchische Darstellung aller Unterkonfigurationselemente der Tabellenkonfiguration weist eine Menü-Zeile auf, die wie folgt mit Aktionen belegt ist:

  •  Neues Unterelement anlegen und verknüpfen.
  •  Bereits vorhandene mögliche Unterelement durchsuchen und verknüpfen
  •  Verknüpfung wieder löschen, Unterelement bleibt dabei als Objekt erhalten. und kann in anderen Konfigurationen wieder verwendet werden.
  •  Gewähltes Unterelement komplett löschen. Falls es in anderen Konfigurationen verwendet wird, öffnet sich vor der Löschung eine Warnung, die alle vorhandenen Verknüpfungen aufzeigt.
  • Gewähltes Unterelement in der Liste nach oben schieben.
  • Gewähltes Unterelement in der Liste nach unten schieben.
  •  Aktualisierung. Erst nach einer Aktualisierung werden alle Änderungen für die Anwendungen übernommen.


Beispiel einer einfachen Tabellenkonfiguration

Zu einer Liste von Sehenswürdigkeiten soll der Ort, an dem sie sich befinden, Themen, mit denen sie zu tun haben und Reisen, bei denen sie besucht werden in einer Tabelle zu sehen sein. Nicht zu vergessen ist das Namensattribut, durch das die Sehenswürdigkeiten in der ersten Spalte repräsentiert werden.


Einstellungsmöglichkeiten (Tabelle)

Name Wert
Anzahl Zeilen (Page size) Gibt an, wie viele Zeilen auf einer Seite angezeigt werden sollen. Standardwert: 20
Keine automatische Suche Es wird keine automatische Suche durchgeführt.
Namenlose Unterelemente erlauben Namenlose Unterelemente werden ebenfalls angezeigt.
Ohne Sortierung Es findet keine Sortierung statt. Standardverhalten: es wird nach der ersten Spalte sortiert.

Durch Angabe einer Ganzzahl lässt sich steuern an welcher Stelle, falls mehreren Konfigurationen vom Typ Tabelle angezeigt werden sollen, die aktuelle Konfiguration angezeigt wird.

Die Sortierung wird nach zwei Kriterien durchgeführt, die in der folgenden Reihenfolge überprüft werden:

  1. Attribut Reihenfolge vorhanden, wenn ja, dann wird dieses als Sortierkriterium verwendet, wenn nein, werden erst die Konfigurationen für Typen und dann die für Objekte angezeigt.
  2. Sortierung nach Anzeigename

Aktionen und Styles

Aktionen und Styles lassen sich für die gesamte Tabelle, aber auch für Zeilen festlegen.


Wo die Tabelle zur Verwendung kommt, wird auf dem Reiter Verwendung angegeben.

Unter anwenden auf wird der Objekttyp angegeben, auf den die Tabelle angewendet werden soll. Tabellen können in anderen View-Konfigurationen wieder verwendet werden. Falls die Tabelle Baustein einer anderen View-Konfiguration ist, wird dies unter [inverse] anwenden in angezeigt.

Die Eigenschaft anwenden in verweist auf eine Anwendung. Mehrere Verknüpfungen sind möglich.


  • Soll die Tabelle im Knowledge-Builder rechts im Hauptfenster bei der Navigation durch die Ordnerstruktur verwendet werden, dann muss die Tabellenkonfiguration mit dem entsprechenden Ordnerstrukturelement verknüpft sein.
  • Sollen mögliche Relationsziele im Knowledge-Builder tabellarisch dargestellt werden, dann muss die Tabelle mit der Anwendung Knowledge-Builder verknüpft sein.

Tabellen / Objektslisten im Knowledge-Builder

Für die Konfiguration der tabellarische Darstellung von Objekten oder Typen im Knowledge-Builder findet sich im Reiter Details beim jeweiligen Typen der Abschnitt View-Konfiguration -> Objekt/Typ -> Objektliste. Das Erstellen und Pflegen der Tabellen-Konfiguration wird am Beispiel der Objekte des Typs Thema erläutert.

Objekte vom Typ Thema bieten selbst als zusätzliche Eigenschaften Synonym und die Relation ist Thema von an. Diese Eigenschaften, zusammen mit dem Namen des Themas sollen die Bestandteile der zu bauenden Tabelle ergeben.

Der Typ Thema wird bearbeitet, in der Ansicht wird der Reiter Details gewählt und hier der Punkt View-Konfiguration -> Objekt -> Objektliste angeklickt.

Noch wurde keine Tabellenkonfiguration mit diesem Typ verknüpft. Durch Klicken auf den Knopf Neu wird eine neue, leere Konfiguration erzeugt. Diese kann dann selektiert und wie oben beschrieben bearbeitet werden.

Einstellungsmöglichkeiten für die Sortierung

Name Wert
Absteigend sortieren Steuert, ob auf- oder absteigend sortiert wird. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert.
Primäres Sortierkriterium

Auswahlmöglichkeit für das Kriterium, nach dem die Eigenschaften sortiert werden:

  • Position: Die in der Konfiguration festgelegte Reihenfolge wird verwendet (Default).
  • Wert: Inhalt des Attributes bzw. Anzeigename des Relationszieles wird verwendet.
  • Skript zur Sortierung: Das in dem Attribut Skript zur Sortierung hinterlegte Skript wird zur Ermittlung des Sortierkriteriums verwendet.
Sekundäres Sortierkriterium Sortierkriterium für Eigenschaften, die für das primäre Sortierkriterium den gleichen Wert haben. Einstellmöglichkeiten analog zum Primären Sortierkriterium
Skript zur Sortierung Verweis auf ein registriertes Skript, das den Sortierschlüssel für das primäre bzw. sekundäre Sortierkriterium zurückgibt. Columconfigurations

Wie bereits erwähnt, tragen Spaltenkonfigurationen Eigenschaften, die der Festlegung der Darstellung und des Verhaltens der Spalte in der Tabelle dienen. Erst wenn Eigenschaften an den in der Spaltenkonfiguration enthaltenen Spaltenelementen konfiguriert werden, wird die Spalte angezeigt.


Name Wert

Wird in der Titelzeile der Spalte angezeigt. Hierbei ist zu beachten, dass Beschriftung der Anzeige in der Tabelle dient, die Spaltenkonfiguration aber zusätzlich noch das Attribut Konfigurationsname enthält. Dieser Name dient allein der Verwaltung und dem Auffinden der Konfiguration in der semantischen Graph-Datenbank und wird nicht angezeigt oder ausgegeben.

Breite der Spalte (%) Für die Breite der Spalte wird hier ein prozentualer Wert erwartet (für 60% muss also "60" eingegeben werden).
Nicht anzeigen Ist dieser Wert gesetzt, wird die komplette Spalte nicht angezeigt. Dies dient dazu z.B. eine Suche mit den Werten dieser Spalte durchzuführen. Der Anwender soll aber nicht die Möglichkeit haben Veränderungen an dieser Spalte vorzunehmen.
Obligatorisch für Abfrage Ist dieser Wert gesetzt, muss die Spalte ausgefüllt sein, um suchen zu dürfen.
Sortierpriorität Nach der Spalte mit Sortierpriorität 1 wird primär sortiert. Bei gleichen Werten wird nach der Spalte mit der nächst höheren Sortierpriorität sortiert usw. Die Standardsortierreihenfolge ist aufsteigend. Um absteigend zu sortieren negiert man die Sortierpriorität oder setzt das Meta-Attribut "Absteigend sortieren".
Standard-Operator Operator, der initial bei der Suche für einen Suchtext angewendet wird.
Suchtext Initial kann eine Spalte mit einem Suchtext versehen werden.


Spaltenkonfiguration für die Spalte Name Column elements

Ein Spaltenelement dient der Zuweisung, welche Inhalte eine Tabellenspalte darstellen soll und wie dies zu geschehen hat. Es können entweder an den semantischen Objekten definierte Eigenschaften wie Attribute und Relationen spezifiziert oder Strukturabfrage-Bausteine oder Skript-Bausteine verwendet werden.


Name Wert


(obligatorisch oder Skript)

Verknüpfung zu einem Eigenschaftstyp, der angezeigt werden soll.


(obligatorisch oder Eigenschaft)

Ausführen des Skripts cellValues zur Ermittlung der Werte, die angezeigt werden sollen.
Nicht anzeigen Über dieses boolesche Attribut kann gesteuert werden, ob Werte der ausgewählten Eigenschaft angezeigt werden sollen. Standardmäßig werden alle Eigenschaften angezeigt.
Nicht anlegen

Dieses Attribut steuert, ob diese Eigenschaft beim Erzeugen eines neuen Objekts erzeugt werden soll, falls das entsprechende Eingabefeld der Spalte einen Wert enthält. Standardmäßig werden neue Eigenschaften erzeugt.

Nicht suchen

Hier kann eingestellt werden, dass die konfigurierte Eigenschaft nicht in die Suche übernommen wird. D.h. eingegebene Suchwerte werden nicht über diese Eigenschaft gesucht.

Achtung: Wenn alle Spaltenelemente einer Spalte auf "Nicht suchen" geschaltet werden, hat dies denselben Effekt wie "Nicht anzeigen"!

Hervorhebung Hier können für das Anzeigen von Werten Formatierungsvorgaben gemacht werden, zur Wahl steht derzeit nur Unterstreichen.
Hits verwenden Standardmäßig werden Objekte erzeugt. Möchte man allerdings in dem Skript cellValues die Hits weiterverarbeiten, muss Hits verwenden eingeschaltet werden.

Derzeit steht nur die Alternative Drop down zur Verfügung. Wird diese ausgewählt, so werden die möglichen Werte, die sich für die Filterung in der Tabelle für diese Spalte eintragen lassen, aus den möglichen Relationszielen gemäß Schema als Dropdown-Liste zusammengestellt, so dass ein möglicher Wert schnell spezifiziert werden kann. Dies empfiehlt sich für überschaubare Mengen an möglichen Relationszielen.

Anmerkung: Dieser Parameter steht nur zur Verfügung, wenn eine Eigenschaft vom Typ Relation gewählt wurde.

Es ist möglich für eine Spaltenkonfiguration mehrere Spaltenelemente zu definieren. Das ist z.B. dann sinnvoll, wenn mehrere Attribute in der Suche berücksichtigt werden sollen wie beispielsweise das Attribut Name und Synonym, aber nur eines davon angezeigt werden soll.


Im ersten Spaltenelement der Spaltenkonfiguration Name wurde das Attribut Name hinterlegt.

Auf der zweiten Spalte wurde im Spaltenelement die Beziehung ist Thema von hinterlegt.

Auf der dritten Spalte wurde im Spaltenelement der Strukturabfrage-Baustein transitive Beziehungskette vom Thema nach oben hinterlegt.

Hinterlegte Struktur-Abfrage

Um Werte aus dem Eingabefeld der Spalte übernehmen zu können, muss die hinterlegte Strukturabfrage konfigurierte Parameter haben. Es können mehrere Parameter angebracht werden, diese sind beim Auswerten der Strukturabfrage alle mit demselben Wert belegt.

Vorsicht: Hier liegt ein Unterschied zu sonstigen Fällen, in denen die Strukturabfrage verwendet wird. Normalerweise bestimmt das Ausgangsobjekt (in diesem Fall wäre dies "Thema") die Ergebnisse, hier sind es jedoch die Objekte oder Eigenschaften, an denen der Parameter angebracht ist (in diesem Fall das Namensattribut).

Der in der Spalte gezeigte Wert ist, wenn keine weiteren Anpassungen vorgenommen werden, der Wert des zum Filtern verwendeten Attributes. Wenn sich der angezeigte Wert nicht aus dem zur Filterung verwendeten Attribut ergibt, so gibt es zwei Möglichkeiten:

  • der Bezeichner "renderTarget" kann an Relationszielen angebracht werden. Die hiermit markierten Objekte werden als Spaltenwert in der Tabelle angezeigt.
    "renderTarget" bewirkt außerdem, dass bei einer Ausgabe über die JavaScript API die Eigenschaften zur Darstellung als Link mit ausgegeben werden.
  • der Bezeichner "renderProperty" kann an Attributen angebracht werden. Die hiermit markierte Eigenschaften werden als Spaltenwerte in der Tabellenspalte angezeigt.

Wird der Suchbaustein nicht zur Filterung verwendet, so muss das anzuzeigende Element mittels renderTarget oder renderProperty bestimmt werden!

Die Strukturabfragen, die in den Baustein des Spaltenelements eingefügt werden, können aus einer Liste bereits registrierter Strukturabfragen ausgewählt werden, sie können aber auch für genau diesen Baustein neu angelegt werden, was auch die Vergabe eines Registrierungsschlüssels mit sich bringt. Die Eigenschaft Nicht anlegen hat auf Spalten, die mit einem Strukturabfrage-Baustein belegt sind, keine Wirkung.

Auf die vierte Spalte wurde ein Script-Baustein abgebildet

Es sollen die Verantwortlichen für die Objekte, mit denen das in der Tabelle gelistete Thema mit ist Thema von verknüpft ist, angezeigt werden. Wie bei der Strukturabfrage kann das zugeordnete Skript aus einer Liste von bereits registrierten Skripten ausgewählt oder aber im Dialog neu angelegt (und registriert) werden. Der Skript-Editor öffnet sich nach Klicken auf den Skript-Baustein-Namen.

 * Returns matching elements for colum search value "objectListArgument"
*  Note: "elements" may be undefined if no partial query result is available. 
 * Return undefined if the script cannot provide any partial result itself.
function filter(elements, queryParameters, objectListArgument) {
    return elements;

// Returns cell values for the given element
function cellValues(element, queryParameters) {
    var result = new Array();
    var firstTargets = element.relationTargets("istThemaVon") ;
    if ( firstTargets.length == 0 ) { return result ;
    else {
        for (var i = 0; i < firstTargets.length; i++) {
        var secondTargets = firstTargets[i].relationTargets("hatVerantwortlichen");
        for (var j = 0; j < secondTargets.length; j++) {
    return result.join(', ');

In diesem Fall ist die Sprache des Skriptbausteins JavaScript. Hier müssen zwei Teile gepflegt werden, der obere Teil dient der Filterung aller Elemente der Tabelle anhand des in der Spalte eingetragenen Wertes objectListArgument, der zweite Teil gibt an, wie für ein Element ein auszugebender Wert berechnet wird. Der erste Teil ist im Moment nicht ausgeführt. Zu beiden Teilen wird ein Code-Muster beim Erzeugen eingefügt, auf das beim Erstellen aufgebaut werden kann.

Wenn KScript als Sprache im Skript-Baustein gewählt wurde, um die Ausgabe einer Spalte zu steuern, dann muss das ausgewählte (registrierte) Skript zu jedem Objekt, das eine Zeile bildet, einen Rückgabewert für die Spalte liefern.

Da in KScript im Prinzip nur eine Ausgabe vorgesehen ist, wurde für die Filterung folgende Konvention getroffen:

Wenn es in dem ausgewählten Skript eine Funktion mit Namen objectListScriptResults und einem deklarierten Parameter gibt, so wird diese Funktion mit dem Argument der zugehörigen Sucheingabe aufgerufen, um die Menge der passenden Objekte zurückzuliefern. Die Funktion wird auf dem Wurzelbegriff oder der bisherigen Treffermenge als Ausgangsobjekt aufgerufen - je nach dem, wie die Suche am besten gelöst werden kann. Damit diese Variante wirklich effizient wird, ist es empfehlenswert, die Sucheingabe entsprechend auszuwerten und mit dem Ergebnis eine registrierte Strukturabfrage aufzurufen, um deren Ergebnis an die Objektliste weiterzuleiten.

7.2.3 Action

Mit Hilfe von Aktionen lassen sich Zusatzfunktionalitäten an Detail- und Tabellenansichten anbringen.

Im Knowledge-Builder werden die vollständig konfigurierten Aktionen als zusätzliche Schaltflächen angezeigt. Bei einer Selektion wird das enthaltene Skript ausgeführt.

Bei einer Kommunikation mit einer andern Applikation über JSON wird eine Beschreibung der möglichen Aktion herausgeschrieben. Die Gegenstelle hat dann die Möglichkeit über einen passenden Request diese Aktion auszuführen zu lassen.

Aktion an einer Objektliste

Die Beschriftung wird als Tooltip im Knowledge-Builder angezeigt. Das ausgewählte Symbol (eine beliebige Bilddatei) wird auf Buttongröße skaliert.
Achtung: Ist kein Symbol angegeben, wird kein Button angezeigt. Scripts of an Action

Aktuell lassen sich die vier folgenden Skript-Typen ausführen.

Die drei letzten Skript-Typen finden bisher nur bei der Ausgabe über JSON Verwendung. Attribut Script

Dieses Skript wird ausgeführt, wenn der benutzerdefinierte Knopf gedrückt oder ein Action-Request gesendet wird.

"Verweis auf Skript"-Attribut Skript

function onAction(element, context)
	return element;


Das Skript einer Aktion kann auf folgende vordefinierten Variablen, in context enthalten, zugreifen.




selectedTopic Ausgewähltes Objekt oder ausgewählter Typ
concept Objekttyp. Falls das Element ein Typ ist, wird der Typ selbst verwendet




selectedTopic Ausgewähltes Objekt oder ausgewählter Typ. nil, falls kein oder mehrere Elemente ausgewählt wurden.
selectedTopics Ausgewählte Elemente
topics Alle Elemente der Objektliste
concept Typ der Objektliste Attribute Script (ActionResponse)

"Verweis auf Skript"-Attribut Skript (ActionResponse)

function actionResponse(element, context, actionResult)
	var actionResponse = new $k.ActionResponse();


	return actionResponse;

Die ActionResponse kann um Werte für Followup und Nofication erweitert werden. Diese Werte können von anderen Anwendungen wie z.B. dem ViewConfigMapper ausgewertet werden. Attribute Script (visible)

"Verweis auf Skript"-Attribut Skript (visible)

function actionVisible(element, context)
	return true;

Das Skript darf nur einen booleschen Wert zurückliefern. Anhand des Wertes wird entschieden, ob der Knopf angezeigt werden soll oder nicht. Bei der Ausgabe über JSON wird die Aktion nicht weiter betrachtet und somit auch nicht ausgegeben. Attributs Script (enabled)

"Verweis auf Skript"-Attribut Skript (enabled)

function actionEnabled(element, context)
	return true;

Das Skript darf nur einen booleschen Wert zurückliefern. Anhand des Wertes wird entschieden, ob der Knopf aktiv ist oder nicht. Bei der Ausgabe über JSON wird der Marker enabled auf false gesetzt. UI-spezific Functions

UI-spezifische Funktionen
Das die Aktion realisierende Skript kann auf UI-spezifische Funktionen zurückgreifen. Wegen dieser Möglichkeit wird das Skript nicht innerhalb einer einzigen Transaktion ausgeführt. Werden Transaktionen aufgrund von Schreibzugriffen benötigt, dann müssen diese im Skript aufgerufen werden. UI-specific functions in Javascript
$k.UI.alert(message, windowTitle)

Zeigt eine Meldung an.


$k.UI.requestString(message, windowTitle)

Benutzer kann eine Zeichenkette eingeben.


$k.UI.confirm(message, windowTitle)

Öffnet einen Abbrechen-Dialog.


$k.UI.choose(objects, message, windowTitle, stringFunction)

Objekt aus einer Menge auswählen lassen.



Standardeditor für das Objekt öffnen.


$k.UI.notificationDialog(notificationFunction, parameters, windowTitle)

Es wird ein Warte- bzw. Benachrichtigungsdialog geöffnet. Dieser kann, je nachdem wie er konfiguriert ist, abgebrochen werden.

Mögliche Parameter:

Parameter Beschreibung Standardwert
autoExpand Ist der Anzeigebereich des Dialogs initial geöffnet. true
canCancel Kann der Dialog abgebrochen werden. true
stayOpen Bleibt der Dialog nach Beendigung geöffnet. true


ui.notificationDialog(function() {
    ui.alert("Hello world");
    return undefined;
    }, { "canCancel" : false }, "Ein Wartedialog");

Mit der folgenden Function raiseNotification können Meldungen auf dem Anzeigebereich ausgegeben werden.



Diese Benachrichtigung wird nur von der Function notificationDialog gefangen und die Nachricht wird nur dort im Anzeigebereich ausgegeben. UI-specific functions in KScript
<UIWarn message="${name() + ' lebt'}"/>

Zeigt eine Meldung an


<UIRequestString message="'Name'"/>

Benutzer kann eine Zeichenkette eingeben


<UIConfirm message="'Sind Sie versichert?'"/>

Öffnet einen Abbrechen-Dialog


<UIChooseObject message="'Person'" objects="//Person/instances()"/>

Objekt aus einer Menge auswählen lassen



Standardeditor für das Objekt öffnen



Objektliste: Ein neuer Topic samt Eigenschaften für die Suchfeldeingaben wird angelegt. Editor: Keine Wirkung, liefert null.


<UIOpenTopicList title="Personen" objects="//Person/instances()"/>

Öffnet ein Objektlistenfenster mit den durch das Argument objects festgelegten Wissensnetzelementen.


7.2.4 Graph-Editor

Die Graph-Editor-Konfiguration ermöglicht es nur bestimmte Typen und Relationen im Graphen anzuzeigen. So kann verhindert werden, dass unerwünschte Typen und Relationen im Graphen zu sehen sind. Die Graph-Editor-Konfiguration kann ebenfalls über JavaScript-Funktionen angefragt werden. Sie findet beispielsweise Verwendung im Net-Navigator. The default graph-configuration

Sollte keine Graph-Editor-Konfiguration angelegt sein, wird auf eine Fallback-Graph-Editor-Konfiguration zurückgegriffen.

Diese unterscheidet sich für Administratoren und Anwender um einen sinnvollen Standard zu bieten.  

Konfigurierte Typen:

AdministratorenAlle Typen und Individuen
AnwenderAlle Typen und Individuen ohne Technik

Konfigurierte Relationen:

    Alle Benutzerrelationen außer:

  • abstrakte Relationen
  • inverse Einweg Relationen


  • erweitert Objekte von
  • Objekte sind Domäne von
  • Inverser Relationstyp
  • ist Objekt von
  • ist Untertyp von
  • ist Obertyp von
  • An Attributen: ist Eigenschaft von graphconfiguration

Der Graph-Editor wird im Technik-Bereich unter View-Konfiguration >> Objekttypen >> Konfigurationselement >> Graph-Editor-Konfiguration konfiguriert. Graph-Editor-Configuration

Eine Graph-Editor-Konfiguration besteht aus einem Graph-Editor-Konfigurations-Objekt. An diesem können Beschriftung und die Anwendung, in welcher diese Graph-Editor-Konfiguration gilt (Bsp. Net-Navigator), konfiguriert werden. nodecategory

Über den Button "Knotenkategorie neu anlegen" kann eine Knotenkategorie neu angelegt werden. Eine Knotenkategorie definiert ein oder mehrere Typen bzw. dessen Objekte, welche im Graphen angezeigt werden sollen. Diese Typen können über die Relation "anwenden auf" im Reiter Verwendung festgelegt werden. Die Option "anwenden auf Untertypen" bewirkt dabei, dass der Typ und nicht seine Objekte angezeigt werden. Möchte man sowohl den Typ als auch dessen Objekte angezeigt bekommen, legt man zwei Relationen "anwenden auf" mit selbem Ziel an, wobei sich nur "anwenden auf Untertypen" unterscheidet.
Ein Knoten wird im Graphen angezeigt, wenn wenigstens eine Knotenkategorie diesen Typen konfiguriert. Dabei wird auch Vererbung berücksichtigt. Sollte ein Knoten keiner direkten Knotenkategorie angehören, gehört er der Knotenkategorie an, die den ersten Obertypen konfiguriert.
Die Option "an konkreten Typ anpassen" bildet automatisch Knotenkategorien für alle Untertypen der konfigurierten Typen. Dies wird in JavaScript-Funktionen berücksichtigt (siehe Kapitel Graph-Editor Konfiguration in JavaScript), findet im Knowledge-Builder jedoch keine Verwendung. linkconfiguration

Eine Knotenkategorie kann Verknüpfungskonfigurationen haben. Diese definieren, welche Relationen an der Knotenkategorie erwünscht sind. Dies beeinflusst das Ausklappen von Relationen, sowie das Anlegen von Relation im Graphen. Eine neue Verknüpfungskonfiguration kann über den Button "neues Anlegen" >> "Verknüpfungskonfiguration" angelegt werden. Konfigurierte Relationen können entweder über das Feld "Relation" direkt angegeben, oder durch ein Skript bzw. eine Strukturabfrage ermittelt werden. Auch konfigurierte Relationen vererben die Konfiguration an ihre Untertypen.

Eine Relation kann angezeigt, ausgeklappt und erstellt werden, falls sowohl Domain als auch Inversedomain des Relationstyps eine Knotenkategorie haben, und der Relationstyp an der Knotenkategorie des Topics konfiguriert ist. graphconfiguration in JavaScript

 Man kann einen konfigurierten Graphen auch über JavaScript-Funktionen anfragen. Dazu gibt es einige Funktionen die im Folgenden näher beschrieben werden.

Beispiel Beschreibung
Liefert ein Graph-Editor-Konfigurationsobjekt für einen optionalen Kontext.
Liefert die Graph-Editor-Konfiguration welche durch das configurationTopic definiert wird.
Liefert das KonfigurationsTopic der Graph-Editor-Konfiguration.
 graph.addElements([node1, node2]);
Fügt dem Graphen ein Array von Topics hinzu.
 graph.expand([node1, node2], 2);
Fügt dem Graphen alle Nachbarn bis zu einer Tiefe 2 der angegebenen Knoten hinzu.
Fügt dem Graphen alle Nachbarn bis zu einer Tiefe 2 aller Knoten hinzu.
 graph.collapse([node1, node2]);
Entfernt die Nachbarn der angegebenen Knoten aus dem Graphen.
Liefert alle Knotenkategorien als JSON.
Liefert die erstellbaren Relationstypen von einem Knoten node1 zu allen anderen Knoten sortiert nach Zielknoten als JSON.
Liefert den Graphen als JSON. Die angegebenen Filter werden nicht gerendert.
Liefert alle Knoten im Graphen.
7.3 Configuration of the Knowledge-Builder

Die hier beschriebenen View-Konfigurationen betreffen ausschließlich den Knowledge-Builder. Weitere View-Konfigurationen, die den Knowledge-Builder betreffen, finden sich auch an anderen Stellen in Kapitel 7, können dann aber auch zusätzlich jeweils die Ausgabe in JSON betreffen.

7.3.1 Folder structure

Der linke Teil des Hauptfensters im Knowledge-Builder dient der Navigation durch das semantische Modell. Dazu wird dort eine hierarchische Ordnerstruktur angezeigt. Diese lässt sich in mehrere Hauptbereiche gliedern, die dann als Balken angezeigt werden. Klickt man einen solchen Balken an, dann klappt die darunter liegende Ordnerstruktur auf, über die man Inhalte (Elemente, Abfragen, Import/Export-Abbildungen usw.) erreichen kann. Die Inhalte werden auf der rechten Seite aufgelistet und können dort bearbeitet werden. The Standard Folder Structure

Die Konfiguration der Standard-Ordnerstruktur stellt Ordner zur Verfügung, so dass im semantischen Modell navigiert und Inhalte abgelegt werden können. Für Administratoren werden drei Hauptbereiche zur Verfügung gestellt.

Der obere Hauptbereich "Ordner" stellt Ordner für die Anlage weiterer Ordner und das Verwalten von Inhalten zur Verfügung. Das sind der Arbeitsordner, der Privatordner, der Ordner "Zuletzt verwendete Objekte" und der Ordner "Suchergebnisse".

Der zweite Hauptbereich "Wissensnetz" ermöglicht die Navigation zu den Elementen über die Hierarchie der Typen. Die hier zu erreichenden Elemente sind Typen, Objekte und auch Attribute und Relationen. Dafür enthält der Bereich drei Ordner:

  • Objekttypen für die Hierarchie der Objekttypen und ihrer konkreten Objekte
  • Relationstypen für die Hierarchie der Relationen
  • Attributtypen für die Hierarchie der Attribute

Der dritte Hauptbereich "Technik" ermöglicht es Administratoren Änderungen, Einstellungen und Konfigurationen verschiedenster Art im sem. Netz vorzunehmen. Dazu gehören u.a. Registrierte Objekt, das Rechtesystem und Trigger


Die Konfiguration dieser Standard-Ordnerstruktur kann im Technik-Bereich >> View-Konfiguration überprüft, verändert und den Bedürfnissen der Anwender angepasst werden.

Anmerkung: Für Administratoren wird immer die Standard-Ordnerstruktur angezeigt. Konfiguriert man eine View-Konfiguration für Ordner, so werden diese nur für Nicht-Administratoren angezeigt. Möchte man als Administrator auch die konfigurierte Sicht der Ordnerstruktur angezeigt bekommen, so kann das in den persönlichen Einstellungen des Knowledge-Builder auswählt werden: Unter "Einstellungen" > "Persönlich" > "View-Konfiguration" die Auswahl "Konfiguriert" wählen. Configuration Of The Folder Structure

Die Ordnerstruktur wird im Technik-Bereich unter View-Konfiguration >> Objekttypen >> Knowledge-Builder-Konfiguration >> Ordnerstruktur konfiguriert. Einen schnellen Zugriff auf die Konfigurationen erhält der Admin, wenn er im Technik-Ast den Knoten View-Konfiguration selektiert und im rechten Teilfenster auf dem Reiter Ordnerstruktur das Objekt Organizer auswählt.

In der Konfiguration werden Ordnerstrukturelemente hierarchisch miteinander verknüpft. Der Wurzelknoten dieser Hierarchie ist ein Objekt des Typs Ordnerstruktur. Initial ist eine Ordnerstruktur mit Namen Organizer enthalten. Alle Unterknoten und deren Unterknoten sind vom Typ Ordnerstrukturelemente. Die Hierarchie in der Konfiguration zeigt direkt die im Hauptfenster dargestellte Hierarchie. Die direkten Unterknoten des Wurzelknotens werden im Hauptfenster als Balken dargestellt, so dass sich eine optische Abgrenzung der verschiedenen Ordnerhierarchien voneinander ergibt.

Beschriftung ist ein Parameter, den alle Konfigurationstypen gemein haben. Ein Knoten, der durch eine Konfiguration beschrieben wird, wird mit diesem Wert beschriftet. Was im rechten Teil des Hauptfensters angezeigt wird, wenn man einen Knoten selektiert, hängt von den Parametern des Ordnerstrukturelements ab. Dazu muss der Parameter Ordnertyp belegt werden, für den eine Auswahl an Typen zur Verfügung steht. Diese Ordnertypen und deren zusätzliche Parameter werden in der folgenden Tabelle aufgeführt.

Ordnertyp (obligatorisch) Parameter Beschreibung
Attributtypen Typ Der angegebene Attributtyp und alle seine Untertypen werden in einem hierarchischen Baum angezeigt.
Privatordner  - Anzeige des Ordners, den nur der Benutzer selbst sehen darf und der für jeden Benutzer unterschiedlich ist.
Relationstypen Typ Der angegebene Attributtyp und alle seine Untertypen werden in einem hierarchischen Baum angezeigt.
Strukturordner Strukturordner Ein beliebiger Strukturordner kann hier eingehängt werden.
Suchergebnisordner  - Jeder Benutzer hat einen eigenen Suchergebnisordner, der die letzten Suchergebnisse des Benutzers speichert.
Typbasierte Ordnerstruktur Ansicht "Ohne Vererbung", Typ

Der angegebene Typ und seine Untertypen werden tabellarisch aufgelistet. Ist der Parameter Ansicht "Ohne Vererbung" gesetzt, wird nur der angegebene Typ angezeigt.

Anmerkung: Zur Steuerung welche Tabellenkonfigurationen auf der rechten Seite Anwendung finden, muss dort die Relation anwenden in mit diesem Ordnerstrukturelement verknüpft werden.

Virtueller Ordner  - Ein Ordner, der zur Strukturierung der Ordner dient.
Zuletzt verwendete Objekte  - Jeder Benutzer hat einen eigenen Ordner, in dem die zuletzt verwendeten Objekte für einen schnelleren Zugriff gespeichert werden.

Nur der Konfigurationstyp Virtueller Ordner kann weitere Unterkonfigurationen enthalten bzw. nur beim ihm machen Unterkonfigurationen Sinn.

Anmerkung: Bei dem Ordnertyp Attributtypen, Relationstypen und Typenbasierte Ordnerstruktur dient der Parameter Typ zur Angebe des Attribut-, Relations- oder Objekttyp der und dessen Untertypen in dem Ordner angezeigt werden sollen.

7.3.2 Relation target search

Die Konfiguration der Relationszielsuche ermöglicht es, auf die Strategie einzuwirken, mit der mögliche Relationsziele gesucht werden. Enthält ein semantisches Modell keine Relationszielsuche, dann wird auf eine Eingabe von "Egon" immer nach einem Objekt mit Namen "Egon" gesucht (d.h. das jeweilig definierte Namensattribut wird verwendet). Durch Angabe einer zuvor definierten Abfrage kann dieses Verhalten verändert werden. Beispielsweise könnte man für die Suche nach Personen eine Abfrage definieren, die sowohl den Vornamen als auch den Nachnamen durchsucht. Sucht man dann nach einem Ziel für eine Relation, deren Zieldomäne Person ist, dann werden die Nachnamen und Vornamen von Personen nach der Eingabe von "Egon" durchsucht. Sinnvoll ist eine angepasste Relationszielsuche auch, wenn man gleichzeitig Namen und Synonyme von Objekten durchsuchen möchte, sodass beispielsweise das Objekt "Architektur" auch gefunden wird, wenn der Anwender "Baukunst" eingibt.

Relationszielsuche konfiguriert für die Suche nach Personen

Wie bei allen Konfigurationen muss der Kontext angegeben werden, in dem die Relationszielsuche verwendet werden soll. Zusätzlich kann die Verwendung auf einen Typ von Relationszielen oder auch auf einen speziellen Relationstyp eingeschränkt werden. Diese Angaben sind jedoch optional.

7.3.3 Start view

Mit der Konfiguration Startansicht lässt sich definieren, welches Hintergrundbild und welche Aktionen im Knowledge-Builder auf der rechten Seite angezeigt werden sollen. Die Anzeige lässt sich jederzeit durch Deselektion (Strg-Taste auf bestehende Selektion im linken Navigationsbaum) hervorrufen.


Name Wert
Hintergrundbild Ein Bild
Farbwert für Schriftart einer Aktion Je nach ausgewähltem Bild muss eine andere Farbe für die Beschriftung der Aktionen gewählt werden, um den Text lesen zu können.

Darüber hinaus lassen sich Aktionen definieren. Siehe dazu Kapitel Aktion. Zusätzlich kann eine Aktionsart festgelegt werden. Hier stehen folgende Einträge zur Verfügung:

Aktionsart Aktion
Handbuch (spezialisierter Web-Link) Web-Handbuch wird im Browser geöffnet
Homepage (spezialisierter Web-Link) Die Homepage wird im Browser geöffnet.
Support-E-Mail (spezialisierter Web-Link) Ein Fenster für eine neue E-Mail wird mit der Support-E-Mail-Adresse geöffnet.
Web-Link Frei definierbarer Web-Link
<keine Aktionsart> Konfigurierte Aktion (mit Skript) ausführen

Ein Web-Link muss vollständig konfiguriert sein, sonst wird er nicht angezeigt.

Abweichend dazu muss dies bei den drei oberen Aktionsarten (spezialisierte Web-Links) nicht so sein. Diese verwenden, falls eine Eigenschaft fehlt, ihre Standardwerte. Es besteht die Möglichkeit die Standardwerte zu überschreiben.

Konfigurationsmöglichkeit Web-Link

Name Wert
Beschriftung Anzeigename hinter dem Icon
Symbol Icon, welches vor der Beschriftung angezeigt wird
URL URL die geöffnet werden soll

7.3.4 Search field

Das Schnellsuchfeld findet sich in der linken oberen Ecke des Hauptfensters. Dieses Feld ermöglicht den schnellen Zugriff auf Abfragen. Diese werden vom Administrator zur Verfügung gestellt oder auch vom Anwender hinzugefügt. Alle Abfragen, die hier verwendet werden, dürfen nur eine Suchzeichenkette oder keine Sucheingabe erwarten.

Keine Sucheingabe macht bei solchen Abfragen Sinn, deren Ergebnis sich von Zeit zu Zeit ändert. Das Ausführen einer solchen Suche im Schnellsuchfeld zeigt dann das aktuelle Ergebnis, ohne dass man die entsprechende Abfrage jedes Mal beispielsweise in einem Ordner aufsuchen muss. Beispielsweise könnte es eine Suchabfrage geben, die alle Lieder anzeigt, die der aktive Anwender schon gehört hat. Search field configuration for administrators

Die "Suchfeld"-Konfiguration legt fest, welche Abfragen vom Administrator im Schnellsuchfeld des Knowledge-Builders zur Verfügung gestellt werden.

Neu angelegte Netze verfügen über eine Suchfeld-Konfiguration, die für alle Nutzer gleich ist. Der Administrator kann diese Suchfeld-Konfiguration erweitern, um allen Nutzern weitere Abfragen zugänglich zu machen. Zusätzlich kann jeder Nutzer seinem Schnellsuchfeld weitere Abfragen hinzufügen, die dann aber nur für ihn persönlich sichtbar sind.

Eine Suchfeld-Konfiguration besteht aus "Schnellsuchelementen", die eine Referenz auf eine Abfrage enthalten müssen und optional mit einer Beschriftung versehen werden können. Die Reihenfolge der Schnellsuchelemente bestimmt die Reihenfolge der Menüeinträge am Schnellsuchfeld. Search field configuration for user

Der Anwender kann Abfragen durch ziehen einer existierenden Abfrage auf das Schnellsuchfeld hinzufügen.

Das Hinzufügen kann ebenfalls über die Einstellungen erfolgen. Auf dem Reiter Persönlich befindet sich der Punkt Suchfeld. Im rechten Bereich im Abschnitt Benutzerdefiniert steht neben dem Hinzufügen auch die Operationen Entfernen und die Möglichkeit die Reihenfolge zu ändern zur Verfügung.

7.4 Style

Aufgabe der View-Konfiguration ist die strukturelle Aufbereitung von Elementen des semantischen Modells für die Anzeige. Geht es darüber hinaus um die Festlegung rein optischer Eigenschaften bzw. kontextloser Informationen, wird das sogenannte "Style"-Element verwendet.

7.4.1 Style properties in applications

Es gibt eine Reihe von Style-Elementen, die bereits in k-infinity definiert sind. Um welche Elemente es sich handelt und wie diese Style-Elemente im Knowledge-Builder angelegt werden, sodass sie dann mit einzelnen Elementen der View-Konfiguration einer Anwendung verknüpft werden können, wird im Folgenden erläutert.

Zunächst muss das Element der View-Konfiguration ausgewählt werden, mit dem wir ein oder mehrere Style-Elemente verknüpfen wollen. Je nach Typ des View-Konfiguration-Elements stehen verschiedene Reiter zur Konfiguration der Styles zur Verfügung ("Aktionen und Styles" -> "Styles" oder direkt "Styles"). Diesen Reiter wählen wir aus und können dann entweder ein neues Style-Element definieren  oder ein bereits vorhandenes Style-Element verknüpfen . Wenn wir ein neues Style-Element definieren, müssen wir diesem zuerst einen Konfigurationsnamen geben. Auf der rechten Seite des Editors kann daraufhin die Konfiguration vorgenommen werden.

Im Folgenden werden die einzelnen Konfigurationsmöglichkeiten für ein Style-Element erläutert:

Name Attributtyp StylePropertyKey Konfigurations- typ Beschreibung
actionConfirmation Verweis auf Skript actionConfirmation    
actionConfirmation Zeichenkette actionConfirmation    
actionConfirmationTitle Zeichenkette actionConfirmationTitle    
actionType Zeichenkette actionType    
class Zeichenkette class    
class (skript) Verweis auf Skript class    
collapsed Boolean collapsed    
Datumsformat Zeichenkette DatumFormat    
Do not print Boolean doNotPrint    
Download request Zeichenkette downloadRequest    
Element ID Zeichenkette elementId    
extra Zeichenkette downloadRequest    
group column grid Zeichenkette groupColumnGrid Gruppe Als Eingabe wird ein String mit Zahlen erwartet, die durch ein Leerzeichen oder ein Komma getrennt werden. Jede Zahl definiert die Anzahl der Spalten, wenn das Maximum 12 Spalten beträgt.
hide filters Boolean hideFilters    
hierarchyDetached Boolean hierarchyDetached    
href Zeichenkette href    
Label anzeigen Boolean hideLabel    
Panel Zeichenkette panel    
render-Mode Auswahl renderMode    
render-Mode Zeichenkette renderMode    
schreibgeschützt Boolean readOnly Eigenschaften Die Eigenschaften des View-Konfiguration-Elements können in der Anwendung nur gelesen und nicht bearbeitet werden. Auch ein "Bearbeiten-Button" wird darum nicht angezeigt.
vcmStateContext Auswahl vcmStateContext    global, none or page
vcmStateContext Zeichenkette vcmStateContext    
vcmTruncate Ganzzahl vcmTruncate    
Zahlenformat Zeichenkette numberFormat    
Zeichenkette für Konfigurationswert Zeichenkette style    
Skript für Konfigurationswert Verweis auf Skript style    
Zeilen markieren Boolean vcmMarkRowClick    
Ziel Zeichenkette class    
Zusätzliche Datumsformate Zeichenkette extraDatumFormats    


Falls wir ein neues Style-Element definiert haben, muss noch ein letzter Schritt vorgenommen werden. Damit die vorgenommene Konfiguration auch in die JSON-Ausgabe geschrieben wird, muss bei dem entsprechenden Konfigurationselement im Schema noch eine Ergänzung vorgenommen werden. Zum Schema gelangt man, indem man im Menü  des entsprechenden Konfigurationselements auf "Schema" klickt. Im Schema muss man dann unter "Details" -> "Typ" das Attribut "StylePropertyKey" hinzufügen und dort den Namen des Konfigurationselements eingeben.

In der JSON-Ausgabe werden dann die Schlüssel-Wert-Paare (StylePropertyKey -> Style-Eigenschaft) als Array unter dem Schlüssel additionalConfig rausgeschrieben.

Auch ganz eigene Style-Eigenschaften können so definiert werden.


Konfiguration des Typs Zeichenkette für Style-Wert

Konfiguration des Typs Noch eine Zeichenkette für Style-Wert

Konfiguration des Typs Banner anzeigen Attribut

Konfiguration des Objektes Eine Style-Konfiguration vom Typ Style


"properties": [{
    "values": [{ ... }],
    "label": "Vorname",
    "additionalConfig": {
        "jsonKey1": ["jsonValue1"],
        "jsonKey2": ["jsonValue2"],
        "Banner anzeigen": ["true"]
    "viewId": "ID34304_461524079",
    "schema": { ... }


7.4.2 Style properties in Knowledge-Builder

Im Knowledge-Builder bestimmen die Eigenschaften eines Styles über die Darstellung einiger Benutzungsoberflächenelemente. Nicht alle möglichen Eigenschaften eines Styles ergeben für alle Konfigurationen Sinn. Die folgende Tabelle zeigt, welche Eigenschaften von welcher Konfiguration unterstützt werden und was der Effekt ist.

Style-Eigenschaft Konfigurationstyp Effekt
Banner anzeigen Objektkonfiguration

Banner mit Namen des Objekts und Schaltflächen zur Bearbeitung anzeigen. Standard ist nein.

Baumansicht Gruppe Elemente der Gruppe als Baum darstellen. Standard ist nein, d.h. die Gruppenelemente werden nebeneinander oder untereinander angezeigt.
Editorbreite (Pixel) Eigenschaft Breite in Pixeln einer Eigenschaft
Vertikale Anordnung Gruppe Elemente der Gruppe nebeneinander darstellen. Standard ist untereinander anzeigen.
Höhe Gruppe Höhe eines Gruppenelements in Pixeln bei nebeneinander dargestellten Gruppenelementen.
Höhe Eigenschaft Höhe in Zeilen bei Zeichenkettenattributen
Meta-Eigenschaften im Kontextmenü einblenden (Meta-) Eigenschaft(en)

Metaeigenschaften werden im Kontextmenü der Eigenschaft eingeblendet. Somit kann man entweder einzelne Meta-Eigenschaften oder alle Meta-Eigenschaften einer Meta-Eigenschaftenkonfiguration einblenden. (Anmerkung: Der Menüpunkt Metaeigenschaften hinzufügen bleibt dabei unverändert).

Vorschau anzeigen Tabelle Steuert, ob unterhalb der Tabelle ein Editor angezeigt wird.


7.5 Detector System

Mit Hilfe des Detektorsystems können View-Konfigurationen an Bedingungen geknüpft werden. Das Detektorsystem bestimmt wann welche Konfiguration angezeigt werden soll. Im Folgenden wird die Funktionsweise des Detektorsystems und das Zusammenspiel mit View-Konfigurationen an einem Beispiel erläutert.

Für Objekte eines Objekttyps können, über Einstellungen in der View-Konfiguration, mehrere Anzeigen erstellt werden. Mit Hilfe des Detektorsystems können diese an Bedingungen geknüpft werden - wie beispielsweise an einen bestimmten Benutzer. Für das hier beschriebene Beispiel wurden für die Objekte eines beliebigen Typs mit Hilfe der View-Konfiguration zwei Ansichten konfiguriert.

Benutzer, die Mitglied in der Band sind, auf die sie zugreifen wollen, sollen die "Band-Ansicht für Mitglieder" sehen. Alle Benutzer, die nicht Mitglied in der Band sind, auf die sie zugreifen wollen, sollen die "Band-Ansicht" sehen. Die Bedingungen, nach denen die Ansichten benutzt werden sollen, werden im Detektorsystem definiert.


Erstellung einer View-Konfigurations-Ermittlung

Das Detektorsystem befindet sich in der linken Ordnerhierarchie unter dem Abschnitt "Technik" und ist mit der Bezeichnung "Ermittlung der View-Konfiguration" unter "View-Konfiguration" versehen.

Im erste Schritt muss, über das Anlegen eines neuen Suchfilters (siehe Kapitel Suchfilter), der Ausgangspunkt definiert werden - das heißt, es muss definiert werden, wofür die noch folgenden Einstellungen gelten sollen. In diesem Beispiel ist unser Ausgangspunkt daher eine View-Konfiguration (hier: "Band-Ansicht für Mitglieder"), für die gleich eine Bedingung angelegt wird. Als Operationsparameter muss "View-Konfiguration" aus der Liste ausgewählt und eingetragen werden. Der Suchfilter sieht dann folgendermaßen aus:

Unter dem Suchfilter, der nach der View-Konfiguration "Band-Ansicht für Mitglieder" sucht, muss nun ein neuer Suchfilter angelegt werden, der die Bedingung für diese View-Konfiguration beschreibt: Die View-Konfiguration "Band-Ansicht für Mitglieder" soll nur für Benutzer sichtbar sein, die Mitglieder der Band sind, die sie sich gerade ansehen. Der zweite Suchfilter prüft also, ob der aktive Benutzer ein Mitglied der Band ist. Über einen Klick auf  wird der Menge der Suchergebnisse dann erlaubt, die Konfiguration "Band-Ansicht für Mitglieder" einzusehen. Die folgende Abbildung zeigt, den Suchfilter nach Benutzern, die Mitglied der Band sind, die sie sich gerade ansehen und die Ordnerhierarchie, die auf der linken Seite bisher aufgebaut wurde.

Die View-Konfiguration "Band-Ansicht" wird automatisch für diejenigen Nutzer verwendet, die nicht Mitglied der Band sind, die sie sich gerade ansehen.


Gewichtung der Konfigurationen im Detektorsystem

Die Konfigurationen im Detektorsystem "Ermittlung der View-Konfiguration" werden in der Anwendung von oben nach unten gewichtet. Das heißt, Zugangseinstellungen die weiter oben vorgenommen wurden, wiegen mehr als jene weiter unten. Um diese Standardeinstellung zu umgehen, können den Berechtigungen bzw. Verweigerungen Prioritäten gegeben werden.

Dabei ist Priorität 1 die höchste Priorität. Gibt es bei den Bedingungsanweisungen Überschneidungen, so wird die Berechtigungs- bzw. Verweigerungsbedingung mit der höchsten Priorität durchgesetzt. Sind keine Prioritätsangaben gemacht oder haben alle Prioritätszahlen den gleichen Wert, so wird die frühere Bedingungen im Detektorbaum durchgesetzt.

8 JavaScript API
8.1 Introduction

The JavaScript-API is a server-side API for accessing a semantic net. The API is used in triggers, REST services, reports etc.

8.1.1 API reference

The API reference is available here:


8.1.2 The namespace $k

Most objects are defined in the namespace $k. The namespace object itself has a few useful functions, e.g.


which returns the root type of the semantic network, or


which returns the current user.

8.1.3 Registry

Another important object is the Registry object $k.Registry. It allows to access objects by their registered key (folder elements) / internal name (types).



returns the type with the internal name "Article".


returns the query with the registered key "rest.articles".

The Registry object is a singleton, similar to JavaScript's Math object.

8.1.4 Working with semantic elements

Semantic elements are usually retrieved from the registry or by a query.

// Get the person type by its internal name
var personType = $k.Registry.type("Person");
// Perform the query named "articles", 
// with the query parameter "tag" set to "Sailing"
var sailingArticles = $k.Registry.query("articles").findElements({tag: "Sailing"});

The properties of an element can be accessed by specifying the internal name of the property type.

// Get the value of the attribute "familyName"
var familyName = person.attributeValue("familyName");
// Get the target of the relation "bornIn"
var birthplace = person.relationTarget("bornIn");

A shortcut to access the value of the name attribute is the function name()

var name = birthplace.name();

If an attribute is translated, the desired language can be specified, either as 2-letter or 3-letter ISO 639 language code. The current language of the environment is used if no language is specified.

var englishTitle = book.attributeValue("title", "en");
var swedishTitle = book.attributeValue("title", "swe");
var currentTitle = book.attributeValue("title");
8.1.5 Transactions

Transactions are required to create, modify or delete elements. If transactions are controlled by the script, a block can be wrapped in a transaction:

$k.transaction(function() {
	return $k.Registry.type("Article").createInstance();

It is possible to configure if the script controls transactions or if the entire script should be run in a transaction. The only exception are trigger scripts, which are always run as part of a writing transaction.

A transaction may be rejected due to concurrency conflicts. An optional function can be passed to $k.transaction() that is evaluated in such cases:

	function() { return $k.Registry.type("Article").createInstance() },
	function() { throw "The transaction was rejected" }



8.1.6 Modifying elements Creating elements
// Create a new instance
var person = $k.Registry.type("Person").createInstance();
// Create a new type
var blogType = $k.Registry.type("CommunicationChannel").createSubtype();
blogType.setName("Blog"); Creating and modifying attributes

Attribute values can be set with setAttributeValue(), which implies that a single attribute is either already present or created. Existing attribute values are overwritten. An exception is thrown when more than one attribute of a type is present.

person.setAttributeValue("familyName", "Sinatra");
person.setAttributeValue("firstName", "Frank");
// Overwrite the value "Frank" with "Francis""
person.setAttributeValue("firstName", "Francis");

createAttribute() allows to create more than one attribute of a type.

// Create two attributes
person.createAttribute("nickName", "Ol' Blue Eyes");
person.createAttribute("nickName", "The Voice"); Creating relations

A relation between two elements can be created with createRelation():

var places = $k.Registry.query("places").findElements({name: "Hoboken"});
if (places.length == 1)
	person.createRelation("bornIn", places[0]); Deleting elements

Any element can be deleted with the remove() function:


This also deletes all properties of the element.

8.2 Examples
8.2.1 Queries

Search for elements:

// Perform the query "articles" with parameter tag = "Soccer"
var topics = $k.Registry.query("articles").findElements({tag: "Soccer"});
for (var t in topics)
    $k.out.print(topics[t].name() + "\n");

Return hits. A hit wraps an element and adds a quality value (between 0 and 1) and additional metadata.

// Perform the query "mainSearch" with the search string "Baseball"
var hits = $k.Registry.query("mainSearch").findHits("Baseball");
hits.forEach(function(hit) {
    $k.out.print(hit.element().name() + " (" + (Math.round(hit.quality() * 100))+ "%)\n");

Convert query results to JSON:

var topics = $k.Registry.query("articles").findElements({tag: "Snooker"});
var jsonTopics = topics.map(function(topic) {
    return {
        name: topic.name(),
        id: topic.idNumber(),
        type: topic.type().name()
$k.out.print(JSON.stringify(jsonTopics, undefined, "\t"));


8.2.2 Creating and modifying elements

Create a person

// Get the person type by its internal name
var personType = $k.Registry.type("Person");
// Create a new instance
var person = personType.createInstance();
// Set attribute values
person.setAttributeValue("familyName", "Norris");
person.setAttributeValue("firstName", "Chuck");

Set the full name of a person

var familyName = person.attributeValue("familyName");
var firstName = person.attributeValue("firstName");
if (familyName && firstName)
    var fullName = familyName + ", " + firstName;
    person.setAttributeValue("fullName", fullName);

Set the value of an attribute

// Boolean attribute
topic.setAttributeValue("hasKeycard", true);

// Choice attribute
// - internal name
topic.setAttributeValue("status", "confirmed");
// - choice object
var choiceRange = $k.Registry.attributeType("status").valueRange();
var choice = choiceRange.choiceInternalNamed("confirmed");
topic.setAttributeValue("status", choice);

// Color attribute
topic.setAttributeValue("hairColor", "723F10");

// Date / Time / DateAndTime attribute
topic.setAttributeValue("dateOfBirth", new Date(1984, 5, 4));
topic.setAttributeValue("lastModification", new Date());
topic.setAttributeValue("teatime", new Date(0, 0, 0, 15, 30, 0));

// FlexTime attribute
// - $k.FlexTime (allows imprecise values)
topic.setAttributeValue("start", new $k.FlexTime(1984, 6));
// - Date (missing values are set to default values)
topic.setAttributeValue("start", new Date(1984, 5, 3));

// Number (integer / float) attribute
topic.setAttributeValue("weight", 73);

// Interval
topic.setAttributeValue("interval", new $k.Interval(2, 4));

// String attribute
// - untranslated
topic.setAttributeValue("familyName", "Norris");
// - translated (language is an ISO 639-1 or 639-2b code)
topic.setAttributeValue("welcomeMessage", "Welcome", "en");
topic.setAttributeValue("welcomeMessage", "Bienvenue", "fre");

Create a new attribute

person.createAttribute("nickName", "Ground Chuck");	

Create a new relation

var places = $k.Registry.query("places").findElements({name: "Oklahoma"});
if (places.length == 1)
    person.createRelation("bornIn", places[0]);

Delete an element, including its properties


Convert a string to an attribute valu. The ValueRange of an attribute type knows the valid values of the attribute and can parse a string. It throws an exception if the string is not valid.

var statusRange = $k.Registry.type("status").valueRange();
var statusConfirmed = statusRange.parse("Confirmed", "eng"); 		

Set change metadata

topic.setAttributeValue("lastChangeDate", new Date());
var userInstance = $k.user().instance();
// Ensure that a single relation to the user instance exists
if (topic.relationTarget("lastChangedBy") !== userInstance)
    var relations = topic.relations("lastChangedBy"); 
    for (var r in relations)
    topic.createRelation("lastChangedBy", userInstance);
8.2.3 REST

A REST script must define a respond() function that receives the HTTP request, the parsed request parameters and an empty HTTP response. The script then fills header fields and the contents of the response.

function respond(request, parameters, response)
    response.setText("REST example");

Restlet that returns a blob

function respond(request, parameters, response)
    var name = parameters["name"];
    if (name)
        var images = $k.Registry.query("rest.image").findElements({"name": name});
        if (images.length == 1)
            // Set the contents and content type (if known) from the image blob. 
            // Show the image instead of asking to download the file
            response.setText(images.length + " images found");
        response.setText("Name not specified");

Restlet that creates an instance with an uploaded blob

function respond(request, parameters, response)
    var formData = request.formData();
    var name = formData.name;
    var picture = formData.picture;
    if (name && picture)
        var city = $k.Registry.type("City").createInstance();
        city.setAttributeValue("image", picture);
        response.setText("Created city " + name);
        response.setText("Parameters missing");

8.2.4 XML

Transforms query results into XML elements

function respond(request, parameters, response)
	var name = parameters["name"];
	if (name)
		// Find points of interest
		var topics = $k.Registry.query("rest.poi").findElements({name: name});
		// Write XML
		var document = new $k.TextDocument();
		var writer = document.xmlWriter();
		for (var t in topics)
			writer.attribute("name", topics[t].name());
		response.setContents("Name not specified");

XML output

	<poi name="Plaza Mayor"/>
	<poi name="Plaza de la Villa"/>
	<poi name="Puerta de Europa"/>

Use qualified names

var document = new $k.TextDocument();
var writer = $k.out.xmlWriter();
writer.setPrefix("k", "http://www.i-views.de/kinfinity");
writer.startElement("root", "k");
writer.attribute("hidden", "true", "k");

XML output

<k:root xmlns:k="http://www.i-views.de/kinfinity" k:hidden="true">

Define a default namespace

var document = new $k.TextDocument();
var writer = $k.out.xmlWriter();


<root xmlns="http://www.i-views.de/kinfinity">
8.2.5 HTTP client

Load a picture via HTTP and store it as a blob

var http = new $k.HttpConnection();
var imageUrl = "http://upload.wikimedia.org/wikipedia/commons/e/e7/2007-07-06_GreatBriain_Portree.jpg";
var imageResponse = http.getResponse(new $k.HttpRequest(imageUrl));
if (imageResponse && imageResponse.code() == $K.HttpResponse.OK )
	var portree = $k.Registry.type("City").createInstance();
	portree.setAttributeValue("image", imageResponse);

Update the weather report of all cities

var instances = $k.Registry.type("City").instances();
var http = new $k.HttpConnection();
for (var i in instances)
	var city = instances[i];
	var weatherUrl = "http://api.openweathermap.org/data/2.5/weather";
	var weatherRequest = new $k.HttpRequest(weatherUrl);
	weatherRequest.setQueryData({q: city.name()});
	try {
		var weatherResponse = http.getResponse(weatherRequest);
		if (weatherResponse.code() == $k.HttpResponse.OK)
			var json = JSON.parse(weatherResponse.text());
			var weather = json.weather[0].description;
			city.setAttributeValue("weather", weather);
	} catch (e) {

JSON-Strukturen können auch anhand der View-Konfiguration generiert werden, sowohl für einzelne Objekte als auch Objektlisten.

Im einfachsten Fall wird ein Objekt anhand der Standard-Konfiguration ohne weiteren Kontext in JSON umgewandelt:

var data = element.renderJSON();

Es werden dann alle durch die Konfiguration definierten Strukturen in JSON umgesetzt:

    "viewType" : "fieldSet",
    "label" : "Bern",
    "elementType" : "instance",
    "modNum" : 26,
    "elementId" : "ID17361_141538476",
    "type" : {
        "elementType" : "instance",
        "typeId" : "ID10336_319205877",
        "internalName" : "City",
        "typeName" : "Stadt"
    "properties" : [{
            "values" : [{
                    "value" : "Bern",
                    "propertyId" : "ID17361_137824032"
            "schema" : {
                "label" : "Name",
                "elementType" : "attribute",
                "internalName" : "name",
                "maxOccurrences" : 1,
                "attributeType" : "string",
                "viewId" : "ID20838_426818557",
                "typeId" : "ID4900_317193164",
                "minOccurrences" : 0
        }, {
            "values" : [{
                    "typeId" : "ID4900_79689320"
            "schema" : {
                "label" : "Alternativname/Synonym",
                "elementType" : "attribute",
                "internalName" : "alternativeName",
                "attributeType" : "string",
                "rdf-id" : "alternativeName",
                "viewId" : "ID20839_64952366",
                "typeId" : "ID4900_79689320",
                "minOccurrences" : 0
        }, {
            "values" : [{
                    "target" : {
                        "typeId" : "ID10336_493550611",
                        "label" : "Kunstmuseum Bern",
                        "elementId" : "ID17362_205182965"
                    "propertyId" : "ID17361_395925739"
                }, {
                    "target" : {
                        "typeId" : "ID10336_493550611",
                        "label" : "Schweizerische Nationalbibliothek",
                        "elementId" : "ID20401_126870015"
                    "propertyId" : "ID17361_9264966"
            "schema" : {
                "targetDomains" : [{
                        "elementType" : "instance",
                        "typeId" : "ID10336_493550611",
                        "internalName" : "point_of_interest",
                        "typeName" : "Sehenswürdigkeit"
                "label" : "beherbergt Sehenswürdigkeit",
                "elementType" : "relation",
                "internalName" : "contains_poi",
                "viewId" : "ID20840_182208894",
                "typeId" : "ID2052_332207092",
                "minOccurrences" : 0

Zusätzlich kann ein Kontext in Form eines Anwendungs- oder Konfigurationsobjekts angegeben werden. Es wird dann ein zu diesem Kontext passende Konfiguration gewählt. Im folgenden Beispiel wird die Anwendung "Android" vorgegeben:

var application =  $k.Registry.elementAtValue("viewconfig.configurationName", "Android");
var data = element.renderJSON(application);

Es ist aber auch möglich, eine Konfiguration vorzugeben und diese das Element umwandeln zu lassen. Dazu erzeugt man eine $k.ViewConfiguration aus dem Konfigurationsobjekt.

var configurationElement = $k.Registry.elementAtValue("viewconfig.configurationName", "Android Article Configuration");
var data = $k.ViewConfiguration.from(configurationElement).renderJSON(element);

Da die JSON-Struktur recht umfangreich ist, kann man auch bestimmte Properties bei der Umwandlung weglassen, indem man die Schlüssel als zusätzlichen Parameter angibt:

var application =  $k.Registry.elementAtValue("viewconfig.configurationName", "Android");
var data = element.renderJSON(application, ["rdf-id", "viewId", "typeId", "propertyId", "modNum", "minOccurrences", "maxOccurrences"]);
    "viewType": "fieldSet",
    "label": "Bern",
    "elementType": "instance",
    "elementId": "ID17361_141538476",
    "type": {
        "elementType": "instance",
        "internalName": "City",
        "typeName": "Stadt"
    "properties": [
            "values": [
                    "value": "Bern"
            "schema": {
                "elementType": "attribute",
                "label": "Name",
                "internalName": "name",
                "attributeType": "string",
                "maxOccurrences": 1
            "schema": {
                "elementType": "attribute",
                "label": "Alternativname/Synonym",
                "internalName": "alternativeName",
                "attributeType": "string"
            "values": [
                    "target": {
                        "label": "Kunstmuseum Bern",
                        "elementId": "ID17362_205182965"
                    "target": {
                        "label": "Schweizerische Nationalbibliothek",
                        "elementId": "ID20401_126870015"
            "schema": {
                "elementType": "relation",
                "targetDomains": [
                        "elementType": "instance",
                        "internalName": "point_of_interest",
                        "typeName": "Sehenswürdigkeit"
                "label": "beherbergt Sehenswürdigkeit",
                "internalName": "contains_poi"


8.2.7 Mustache templates

The following restlet function renders a document using the Mustache template library. It expects the following schema of a template document:

  • a string attribute (internal name "template.id") to identify a template
  • a document blob (internal name "template.file") containing the template, e.g. an HTML document
  • a relation to a media type(internal name "template.contentType")

A query ("rest.articles") returns the elements that should be rendered. The Mustache library is registered as "mustache.js".

function respond(request, parameters, response)
	// Include Mustache library

	// Get template
	var templateId = parameters["templateId"];
	var templateTopic = $k.Registry.elementAtValue("template.id", templateId);
	var templateText = templateTopic.attributeValue("template.file").text("utf-8");

	// Find elements
	var topics = $k.Registry.query("rest.articles").findElements(parameters);

	// Prepare template parameters
	var topicsData = topics.map(function(topic) {
				   return {
				      name: topic.name(),
				      id: topic.idNumber(),
				      type: topic.type().name()
	var templateParameters = {
		topics: topicsData
	// Render with Mustache
	var output = Mustache.render(templateText, templateParameters);

	// Return the rendered document


8.2.8 Java Native Interface

Java can be accessed via JNI (Java Native Interface).

Caution: JNI is an experimental feature and has several restrictions:

  • JNI cannot be used in triggers
  • It is not possible to define classes (e.g. for callbacks)
  • Generics are not supported
  • JNI allows accessing system resources (files etc.), so take care when using JNI in REST services
  • JNI has to be enabled and configured in the configuration file of each application. The classpath cannot be changed during runtime.
    libraryPath=C:\Program Files\Java\jre7\bin\server\jvm.dll

Basic example

// Import the StringBuilder class, without namespace
$jni.use(["java.lang.StringBuilder"], false);
// Create a new instance
var builder = new StringBuilder();
// Javascript primitives and Strings are automatically converted
builder.append("Welcome to ");
// toJS() converts Java objects to Javascript objects

Text/metadata extraction with Apache Tika

	], false);
// Get a blob
var blob = $k.Registry.elementAtValue("uuid", "f36db9ef-35b1-48c1-9f23-1e10288fddf6").attributeValue("ebook");
// Blobs have to be explicitely converted to Java byte arrays
var bufferedInputStream = new BufferedInputStream(new ByteArrayInputStream($jni.toJava(blob)));
// Parse the blob
try {
	var parser = new AutoDetectParser();
	var writer = new StringWriter();
	var metaData = new Metadata();
	parser.parse(bufferedInputStream, new BodyContentHandler(writer), metaData, new ParseContext());
	var string = writer.toString().toJS();
	// Print extracted metadata
	var metaNames = metaData.names().toJS().sort(
		function(a,b) { return a.localeCompare(b) });
	for (n in metaNames)
		$k.out.print(metaNames[n] + " = " + metaData.get(metaNames[n])).cr();
	// Print extracted text (first 100 chars)
	$k.out.cr().cr().print(string.substring(1, 100) + " [...]\n\n(" + string.length + " chars)");
catch (e)  {
	$k.out.print("Extraction failed: " + e.toString());	
} finally {
8.3 Modules
8.3.1 Defining modules

A module is defined with the define() function. The argument is either a module object or a function that returns an module object. A module should contain only a single definition.

Example: Define a module with a function jsonify())

	 * Create a JSON object array for the topics
	jsonify: function(topics) {
		return topics.map(function(topic) {
			return {
				name: topic.name(),
				id: topic.idString(),
				type: topic.type().name()

 define() allows to specify dependencies from other modules. The following script defines a module that uses another module.

$k.define(["rest.common"], function(common) {
	return {
		stringify: function(topics) {
			return JSON.stringify(common.jsonify(topics), undefined, "\t")
8.3.2 Using modules

A module can be used either with require() or module().

require() expects an array of module names and a callback function. The arguments of the callback function are the module ojects. require() returns the return value of the callback function

var topics = $k.Registry.query("rest.poi").findElements({name: "Madrid"});
var json = $k.require(["rest.common"], function(common) {
	 return common.jsonify(topics); 
$k.out.print(JSON.stringify(json, undefined, "\t"));

module() expects the name of a module and returns the module object.

var json = $k.module("rest.common").renderTopics(topics); 
$k.out.print(JSON.stringify(json, undefined, "\t"));

module() can also be used to include scripts that doe not define a module at all. The script is evaluated and all declared functions are instantiated.

8.3.3 AMD

Um JavaScript-Bibliotheken einzubinden, die den AMD-Standard unterstützen, muss man vorher define() und require() global definieren:

this.define = $k.define;
this.define.amd = {};
this.require = $k.require;
8.4 Debugger
This text section is currently empty.
8.4.1 Debugging in the Knowledge Builder

The following wrapper script is an example for testing a restlet in the Knowledge Builder. It can be defined in the script editor on the "Execute Script" tab as "Additional test script".

// Prepare request and response
var testRequest = new $k.HttpRequest("http://localhost");
var testResponse = new $k.HttpResponse();
// Call the restlet function respond() with the testbench parameters,
// which are available as a property named $k.testbenchParameters
respond(testRequest, $k.testbenchParameters, testResponse);
// Print the response header and contents

Breakpoints can be set on the tab "Debug".

8.4.2 Remote debugger

Restlet scripts can be also be debugged with a remote debugger.


  1. Enable a debug port in the REST bridge .ini file
  2. Install Eclipse and JavaScript Development Tools
  3. Create a JavaScript debug configuration in Eclipse with a Mozilla Rhino connector

  4. Start debugging
  5. Enable "Show all scripts" to see all Javascripts of the bridge

  6. Select "Open source" to view the source of a script (double click does not seem to work)
  7. Set  breakpoints in the source code


8.5 Extending the API
8.5.1 Additional functions

The API can be extended by adding functions to the prototypes. The following example extends schema prototype objects to print schema information.

// Print the schema of the instances and subtypes of a type
$k.Type.prototype.printSchema = function() {
	this.typesDomain().printSchema("Type schema of \"" + this.name() + "\"");
	this.instancesDomain().printSchema("Instance schema of \"" + this.name() + "\"");
	this.subtypes().forEach(function(subtype) {

// Print information about a property type
$k.PropertyType.prototype.logPropertySchema = function() {
	$k.out.print("\t" + this.name() + "\n");

// Attribute types print their type
$k.AttributeType.prototype.logPropertySchema = function() {
	$k.out.print("\t" + this.name() + " (Attribute of type " + this.valueRange().type() + ")\n");

// Relation types print their target domains
$k.RelationType.prototype.logPropertySchema = function() {
	$k.out.print("\t" + this.name());
	var inverse = this.inverseRelationType();
	if (inverse) 
	{	var inverseDomains = inverse.domains();
		if (inverseDomains.length > 0 )
			$k.out.print(" (Relation to ");
			var separate = false;
			inverseDomains.forEach(function(inverseDomain) {
				if (separate)
					$k.out.print(", ");
					separate = true;
				$k.out.print("\"" + inverseDomain.type().name() + "\"");

// Print all properties defined for a domain
$k.Domain.prototype.printSchema = function(label) {
	var definedProperties = this.definedProperties();
	if (definedProperties.length > 0)
		$k.out.print(label + "\n");
		definedProperties.sort(function(p1, p2) { return p1.name().localeCompare(p2.name()) });
		definedProperties.forEach(function(propertyType) {

// Print the entire schema
8.5.2 Defining custom prototypes

The prototype of a semantic element is usually one of the built-in prototypes (Instance, Relation etc.). It is possible to assign custom prototypes to instances of specific types with the function mapInstances(internalName, protoype).

Example: A basket prototype

// Define a Basket prototype with a function totalPrice() 
function Basket() { }

Basket.prototype.totalPrice = function() {
	return this.relationTargets("contains").reduce(
		function(sum, item) {
			return sum + item.attributeValue("price");

// Set the prototype of instances of the basket type 
$k.mapInstances("Basket", Basket);

// Print the total price of all baskets
var baskets =  $k.Registry.type("Basket").instances();
for (var b in baskets)
	$k.out.print(baskets[b].totalPrice() + "\n");
9 REST services

9.1 Configuration

Im Wissensnetz muss die REST-Komponente hinzugefügt werden. Diese definiert das notwendige Schema, das man im Knowledge-Builder im Bereich "Technik "-> "REST" findet. 

Die REST-Schnittstelle wird normalerweise vom Bridge-Dienst bereitgestellt. Diese beantwortet HTTP-Anfragen anhand der REST-Konfiguration im Netz. In der Tryout-Variante des Knowledge-Builders ist die Schnittstelle bereits enhalten, man benötigt keinen Bridge-Dienst.

Konfigurationsänderungen im Wissensnetz wirken sich nicht automatisch auf bereits laufende Schnittstellen aus. Dies passiert, wenn man im Hauptmenü des Knowledge-Builders den Menüpunkt "Administrator -> REST-Schnittstelle aktualisieren" ausführt.

Der Bridge-Dienst benötigt eine passende Konfigurationsdatei (bridge.ini). In diese trägt man die Namen des Servers (host), des Wissensnetzes (volume) und der REST-Service-IDs ein.


9.1.1 Services

Services fassen mehrere Ressourcen zusammen. Ressourcen können in mehreren Services enthalten sein. 

Der Services-Editor im Knowledge-Builder zeigt in seiner Strukturansicht die Ressourcen an. Mit "Neues verknüpfen" wird eine neue Ressource angelegt und zum Service hinzugefügt. Mit "Bestehendes verknüpfen" wird eine bereits definierte Ressource zum Service hinzugefügt.

9.1.2 Resources

Ressourcen beschreiben das Verhalten bei einer HTTP-Anfrage an die Schnittstelle. Es gibt folgende Arten von Ressourcen:

Script ResourceDurche Skripte definierbare Ressource
Built-In ResourceVordefinierte Ressource, deren Verhalten vom System definiert ist. Diese Ressourcen werden von der Komponente angelegt.
Static File ResourceLiefert Dateien aus dem Dateisystem aus

Eine Ressource hat folgende konfigurierbare Eigenschaften:

Path pattern

Definiert die URL der Ressource relativ zur Adresse des Services. Der Pfad kann parameterisiert werden, indem man Parameter in geschweiften Klammern hinzufügt:


Es können mehrere Parameter angegeben werden. Jeder Parameter muss aber ein kompletter durch "/" getrennter Teil sein:


ist nicht gültig,



Part of service Services, die diese Ressource verwenden
Description Beschreibung zu Dokumentationszwecken
Requires authentication Für den Zugriff auf die Ressource ist eine Authentifizierung notwendig Methods

Eine Ressource wird mit einer oder mehreren Methoden verknüpft. Diese definiert das Verhalten sowie die unterstützten Ein- und Ausgabetypen (Content-Type). Anhand der Methoden und Typen der HTTP-Anfrage wird eine passende konfigurierte Methode ausgewählt.

In der Strukturansicht werden Methoden als Unterelemente von Ressourcen angezeigt und können dort angelegt/gelöscht werden.

HTTP Method Unterstützte HTTP-Methoden (GET, POST, PUT, DELETE). Mehrfachangaben sind möglich.
Input media type Nur POST/PUT: Erwarteter Content-Type des Inhalts der Anfrage.
Output media type Content-Type der Antwort. Falls die Anfrage per "Accept" erwartete Content-Typen vorgibt, muss der Output media type dazu passen.

Registriertes Skript zur Definition des Verhaltens (nur bei Script-Ressourcen relevant)


Transaktionssteuerung (nur bei Script-Ressourcen relevant)

Die Transaktionssteuerung ist für schreibenden Zugriffe auf das Wissensnetz relevant, da diese nur innerhalb einer Transaktion möglich sind.


Bei GET nur lesender Zugriff, bei POST/PUT/DELETE wird das Skript in einer Transaktion ausgeführt.
Dies ist die Standardeinstellung.

Controlled by script Keine Transaktion, das Skript muss diese selbst steuern.
Read Nur lesender Zugriff, das Skript kann keine Transaktion starten.
Write Das Skript wird in einer Transaktion ausgeführt. Parameter

Unterhalb von Methoden kann man die Parameter der Ressource definieren. Dies ist nicht zwingend erforderlich, hat aber einige Vorteile:

  • Durch Typangaben kann man Parameter prüfen und konvertieren (z.B. in Zahlen oder Objekte)
  • Dokumentation für Kunden

Folgende Parameter-Eigenschaften können konfiguriert werden:

Parameter name Name des Parameters

Art des Parameters

  • path (Teil des Pfads der URL)
  • query (Query-Parameter der URL)
  • header (HTTP-Header)
Type Datentyp des Parameters. Parameter werden validiert und umgewandelt an das Skript übergeben.

Parameter darf mehrfach vorkommen.

Wenn aktiviert wird immer eine Array von Werten an das Skript übergeben, selbst wenn nur ein Parameterwert in der Anfrage vorhanden ist.

Required Parameter muss angegeben werden
Fixed value Standardwert, falls kein Parameter angegeben wurde.