1 Knowledge Builder
1.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.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.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.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.1.4 Graph editor 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. Operations on objects within the graph editor

änkt.Die Voreinstellung Administrator ist lediglich ein Vorschlag. Dieses Feld darf nicht leer bleiben.


Der Name kann im Admin-Tool oder im Knowledge-Builder nachträglich geändert werden. Der hierüber angelegte Nutzer besitzt aumaItmi sGcrha pAhd-mEidnitistorra tkorrechte.önnen ber das Kontextmenü mit Rechtsklick auf das Objekt weitere Operationen ausgeführt werden. Größtenteils bietet dieses Kontextmenü dieselben Funktionen wie der Formular-Editor, enthältr zusätzlich weitere Graph-Editor-spezifische Komponenten.

In diesem Kontext-Menü stehen folgende Graph-Editor-spezifische Funktionen zur Auswahl:

  • Knoten ausblenden: Hier kann der Knoten ausgeblendet werden.
  • Navigation - Erweiterungen: Öffnet die Erweiterungen zu einem Objekt.
  • Navigation - Berechnete Relationen: Öffnet die berechneten Relationen zu einem Objekt.
  • Navigation - Fixieren: Fixiert die Position eines Knotens im Graph-Editor, so dass er auch bei einem Neuaufbau des Layouts nicht verschoben wird. Die Fixierung kann mit der Option Lösen wieder aufgehoben werden
  • Navigation - K 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. 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.

1.2 Schematic definition / model
1.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.  

1.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)
1.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.

1.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.

1.2.5 Meta model and advanced modelling options 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. 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. 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. 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.

1.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


1.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. 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 i-views, 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. 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": 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).

1.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. 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. 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. 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.

1.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. 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%. 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.

1.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.

1.3.5 Special cases 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. 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. 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.

1.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.

1.5 Import und Export

Mit den Abbildungen von Datenquellen können wir Daten aus strukturierten Quellen in i-views 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".

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.

1.5.1 Mappings of Data Sources

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 i-views 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 i-views 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 i-views, die in ihren Werten mit denen der Import-Tabelle übereinstimmen, sondern darüber hinaus alle Elemente des gleichen Typs in i-views. Wenn man eine Import-Tabelle mit i-views synchronisiert, bedeutet das prinzipiell, dass das Ergebnis in i-views 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 i-views vorkommen, werden neu angelegt.

Beispiel: Wir wollen die Musikmessen in i-views (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. 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. 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.

Datenbank-System Angabe der Datenbank
PostgreSQL hostname:port_datenbank
Oracle //hostname:[port][/datenbankService]
ODBC Name der konfigurierten Datenquelle

Getrennte Konfiguration von Datenbank und Hostname 

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. 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 i-views.

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. 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:

1.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 i-views ein bestimmtes Format verwendet (z.B. Datum), müssen die Einträge der zu importierenden Spalte in einer Form vorliegen, die von i-views 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 i-views 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.

1.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.
1.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 i-views-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.

1.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 i-views 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.

1.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 i-views 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]". 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 i-views 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. 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 i-views 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. 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. 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: Negativ-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 i-views 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. 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.
1.6.2 trigger

Trigger sind automatische Operationen, die in i-views 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. 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 i-views 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. 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 i-views. 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.



Strukturordner Strukturordner 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 i-views aussehen: 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. 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 i-views 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.

Der Funktionsrumpf für Skript-Trigger wird automatisch angelegt.

Das Skript hat drei Parameter:

parameter $k.SemanticElement / $k.Folder Der ausgewählte Parameter
access object Objekt mit Daten der Änderung (neuer Attribuwert usw.)
user $k.User Der Benutzer der die Änderung ausgelöst hat

Folgendes Beispiel setzt die Attribute mit den internen Namen "geaendertAm" / "geaendertVon". Als Parameter sollte hier "Primäres Kernobjekt"  ausgewählt werden.

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

function trigger(parameter, access, user)
	parameter.setAttributeValue("geaendertAm", new Date());
	var userName = $k.user().name();
	if (userName)
		parameter.setAttributeValue("geaendertVon", userName);
		parameter.attributes("geaendertVon").forEach(function(old) { old.remove });

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.

1.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. 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. 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. 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. *

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).

1.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.

Operationsparameter Beschreibung

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.

Benutzer Der Benutzer ist das Objekt des Benutzers, der die Operation ausführt.
Eigenschaft Die 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 Relation Falls 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.

Ordner Der 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 Relationsziel Das 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.

Relationsziel Falls 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 Element Das Ü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.
Zugriffselement Das Zugriffselement ist das von der Operation betroffene Element. 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. 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.

Zugriffselement Benutzer
Objekt, Typ, Erweiterung oder Eigenschaft Objekt des aktuell angemeldeten Nutzers 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.

Zugriffselement (Ober)typ
Objekt oder Erweiterung Der Typ des Objektes oder der Erweiterung
Typ Der Obertyp
Eigenschaft Der Typ der Eigenschaft Semantic Element

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

Zugriffselement Übergeordnetes Element
Objekt, Typ oder Erweiterung Das Zugriffselement selbst
Eigenschaft Objekt, Typ oder Erweiterung an dem oder der die Eigenschaft gespeichert ist
Metaeigenschaft Eigenschaft, an der die Metaeigenschaft gespeichert ist 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.

Zugriffselement Eigenschaft

Attribute oder Relation

Das Zugriffselement selbst
Objekt, Typ oder Erweiterung Leer 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.

Zugriffselement Inverse Relation
Relationshälfte Die inverse Relationshälfte
Objekt, Typ, Erweiterung oder Attribut Leer Inverse Relation Type

Der inverse Relationstyp ist der Typ der inversen Relation.

Zugriffselement Inverser Relationstyp
Relationshälfte Typ der inversen Relationshälfte
Objekt, Typ, Erweiterung oder Attribut Leer 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.

Zugriffselement Relationsziel
Relationshälfte Das Relationsziel ist die Relationsquelle der inversen Relation
Objekt, Typ, Erweiterung oder Attribut Leer 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.

Zugriffselement Primärelement
Objekt, Typ oder Erweiterung Das Zugriffselement selbst
Eigenschaft Objekt, Typ oder Erweiterung an dem oder der die Eigenschaft gespeichert ist
Metaeigenschaft Objekt, Typ oder Erweiterung an dem oder der die Eigenschaft gespeichert ist, an der wiederum die Metaeigenschaft gespeichert ist (transitiv) 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.

Zugriffselement Primäres Relationsziel
Relationshälfte Das 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 ist Das Primärelement des Relationsziels (Objekt, Typ oder Erweiterung der Metaeigenschaft oder Eigenschaft an der die inverse Relationshälfte gespeichert ist)
Objekt, Typ, Erweiterung oder Attribut Leer 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.

Zugriffselement Kernobjekt
Objekt, Typ oder Eigenschaft Das Zugriffselement selbst
Erweiterung Das Objekt an dem die Erweiterung gespeichert ist 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. 

Zugriffselement Primäres Kernobjekt
Erweiterung Das Objekt an dem die Erweiterung gespeichert ist
Objekt oder Typ Das Zugriffselement selbst

Eigenschaft oder Metaeigenschaft einer Erweiterung

Das Objekt an dem die Erweiterung gespeichert ist
Eigenschaft oder Metaeigenschaft eines Objektes oder Typs Primärelement - Objekt oder der Typ an dem die Eigenschaft gespeichert ist (transitiv) 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.

Zugriffselement Primäreigenschaft
Eigenschaft Das Zugriffselement selbst
Metaeigenschaft (oder Metaeigenschaft einer Metaeigenschaft) Die Eigenschaft, die dem Objekt, Typ oder der Erweiterung am nächsten ist
Objekt, Typ oder Erweiterung Leer Folder

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

Zugriffselement Ordner
Ordner Das Zugriffselement selbst
Objekt, Typ, Erweiterung oder Eigenschaft Leer 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.

1.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.


Operation Operationsparameter
Abfrage In Strukturabfrage verwenden Zugriffselement
Anzeigen von Objekten im Grapheditor anzeigen Zugriffselement
Bearbeiten Attributwert validieren Zugriffselement, Eigenschaft, übergeordnetes Element, (zu prüfender Parameter: Attributwert)
Benutzerdefinierte Operation    
Erzeugen Attribut erzeugen (Ober)typ, übergeordnetes Element
Erweiterung erzeugen (Ober)typ, übergeordnetes Element, Kernobjekt
Objekt erzeugen (Ober)typ
Ordner erzeugen Ordner
Relation erzeugen (Ober)typ, übergeordnetes Element, Relationsziel, inverser Relationstyp
Relationshälfte erzeugen (Ober)typ, übergeordnetes Element, Relationsziel
Typ erzeugen (Ober)typ
Übersetzung hinzufügen Zugriffselement, Eigenschaft, übergeordnetes Element
Lesen Alle Objekte/Eigenschaften des Typs lesen (Ober)typ
Attribut lesen Zugriffselement, Eigenschaft, übergeordnetes Element
Objekt lesen Zugriffselement, übergeordnetes Element
Relation lesen Zugriffselement, übergeordnetes Element, Eigenschaft, inverse Relation, Relationsziel, inverses Relationsziel
Typ lesen Zugriffselement, übergeordnetes Element
Löschen Attribut löschen Zugriffselement, übergeordnetes Element
Erweiterung löschen Zugriffselement, Eigenschaft, übergeordnetes Element
Objekt löschen Zugriffselement, übergeordnetes Element
Ordner löschen Ordner
Relationshälfte löschen Zugriffselement, inverse Relation, Eigenschaft, übergeordnetes Element, Relationsziel, inverses Relationsziel
Typ löschen Zugriffselement, übergeordnetes Element
Übersetzung entfernen Zugriffselement, Eigenschaft, übergeordnetes Element
Arttributwert modifizieren Zugriffselement, Eigenschaft, übergeordnetes Element
Ordner modifizieren


Schema modifizieren Zugriffselement, übergeordnetes Element
Typ wechseln Zugriffselement, übergeordnetes Element
Werkzeuge verwenden Export  
Script 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.

Alle Objekte/Eigenschaften des Typs lesen
Diese Operation steuert speziell die Leserechtprüfung bei der Abarbeitung einer Struktursuche. Standardmäßig prüft eine Struktursuche alle Zwischenergebnisse. Eine Suche nach allen Mitarbeitern mit Gehalt größer 10.000€ würde also keine Treffer liefern, wenn das Gehalt nicht lesbar ist, auch wenn die entsprechenden Mitarbeiter-Objekte lesbar wären. Dieses Verhalten ist oft erwünscht, aber selten performant. Speziell bei einem umfangreich konfigurierten Rechtesystem, dessen Abarbeitung signifikant viel Rechenleistung erfordert, empfiehlt sich die Steuerung, welche Zwischenergebnisse einer Struktursuche nicht geprüft werden müssen, weil eine Prüfung der Endergebnisse ausreichend ist. In den meisten Wissensnetzen kann für alle Eigenschaftstypen ("Top-Level-Typ für Eigenschaften") eine Erlaubnis erteilt werden.

Zur Überprüfung, welche Zwischenergebnisse geprüft werden, kann man diese Information in einer Struktursuche einblenden lassen. Dies geschieht über "Einstellungen->Persönlich->Strukturabfrage->Leserechtprüfungen anzeigen".

In Strukturabfrage verwenden (veraltet) 
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.
  • Vergleiche den zu setzenden Wert mit dem Ergebnis eines Skripts:
    Hierbei wird zunächst ein Vergleichswert mittels eines Skriptes ermittelt.

    Das Skript wird mit einem Parameter-Objekt aufgerufen, welches folgende Eigenschaften enthält:
  • Eigenschaft Wert
    attributeValue zu setzender Wert
    property zu ändernde Eigenschaft (Attribut)
    topic Element der Eigenschaft
    user Nutzer, der den Wert setzt

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). *

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.

1.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. 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. 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. 

1.7 View configuration

Die View-Konfiguration ermöglicht es verschiedene Sichten auf die Daten von i-views 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.

1.7.1 Concept

Das Konzept von i-views besteht darin, dass intern Wissensnetzelemente zur Konfiguration verwendet werden. Die Ansichten im Knowledge-Builder werden mithilfe einer voreingestellten View-Konfiguration generiert.


Die View-Konfiguration ist dazu vorgesehen, die Daten des Wissensnetzes für die Anwendungen so aufzubereiten, dass sie entweder im Knowledge-Builder oder mithilfe der Bridge in Form einer Anwendung im Web-Frontend dargestellt werden können.

Im Wissensnetz lassen sich daher spezielle "View-Konfigurationen" sowohl für die Verwendung im Knowledge-Builder als auch für Anwendungen wie dem Viewconfiguration-Mapper erstellen.

Damit Änderungen an in der View-Konfiguration für die Anwendung übernommen werden, muss im Knowledge-Builder die View-Konfiguration durch Klick auf den Button "View-Konfiguration Aktualisieren"  aktualisiert werden. Dieser Button befindet sich jeweils in der Menüleiste einer View-Konfiguration.

Die View-Konfiguration im Knowledge-Builder enthält folgende Kategorien:

  • Anwendungen
  • Graph-Konfiguration
  • Konfiguration der KB-Ordner-Struktur
  • Panel
  • Relationszielsuche
  • Startansicht (KB)
  • Suchfeld (KB)

Näheres ist hierzu im Kapitel "Die Verwendung von View-Konfigurationen" beschrieben.


Der Viewkonfiguration-Mapper dient dazu, die vorkonfigurierten Ansichten der View-Konfiguration auf das Web-Frontend des Browsers abzubilden, also zu "mappen".

Die Struktur des Viewkonfiguration-Mappers ist grundsätzlich hierarchisch aufgebaut und enthält die Panels zum Aufbau des Layouts (= Inhaltsanordnung) des Web-Frontends. Zum Anzeigen der Inhalte benötigt ein Panel eine Sub-Konfiguration, die sogenannte "View" (= aufbereiteter Inhalt).

Konkret enthält der Viewkonfiguration-Mapper ein Hauptfensterpanel und beliebig viele Dialog-Panel. Das Hauptfensterpanel spiegelt den gesamten Darstellungsbereich der Webseite im Web-Frontend wider und enthält beispielsweise folgende Panels:

  • Fenstertitelpanel
  • Panel mit festgelegter Ansicht
  • Panel mit flexibler Ansicht
  • Panel mit linearem Layout
  • Panel mit wechselndem Layout

Zu beachten ist, dass der Viewkonfiguration-Mapper eine Single-Page-Applikation ist, d. h. es wird nicht die Sichtbarkeit von Panels über mehrere Seiten hinweg gesteuert, sondern die Sichtbarkeit der in fest vorhandenen Panels enthaltenen Elemente.

Menüreiter "Kontext"

Die Verwendung von Elementen in der View-Konfiguration wird im Eigenschaften-Editor unter dem Menü-Reiter "Kontext" angezeigt. Diese Information ist von Bedeutung, um Funktionszusammenhänge in der View-Konfiguration nachvollziehen zu können. Je nach Hierarchiestufe oder Art des Panels sind dabei unterschiedliche Konstellationen des Kontextes möglich, welche nur die Verwendung auflisten oder zusätzlich den weitergehenden Kontext:


"Kontext" bezieht sich auf die Anwendung einer View-Konfiguration auf bestimmte Wissensnetz-Elemente oder auf die Verwendung innerhalb einer anderen Anwendung der View-Konfiguration:

  • "anwenden auf": Wird bei Anwendungen verwendet, um mit einem Anwendungselement die Objekte eines bestimmte Objekttyps des Wissensnetzes darzustellen;
    Beispiel: Knoten-Kategorie des Net-Navigators stellt Objekte eines bestimmten Objekttyps aus dem Wissensnetz dar
  • "anwenden auf Untertypen": Wird gewählt, um auch die Objekte der Untertypen des obigen Objekttyps mit der Anwendung darzustellen
  • "anwenden in" spezifiziert, dass eine Konfiguration innerhalb des Kontextes einer anderen Anwendung (meistens: Viewkonfiguration-Mapper) oder einer Konfiguration angewendet wird


"Verwendungen" bezieht sich auf die Wieder- und Weiterverwendung einer View-Konfiguration innerhalb einer anderen View-Konfiguration:

  • "ist enthalten in Panel": Zeigt an, welche übergeordneten Panels in der Viewkonfigurations-Hierarchie vorhanden sind
  • "beinhaltet Panel": Zeigt an, welche Panels in untergeordneten Hierarchiestufen vorhanden sind
  • "Reihenfolge": Bestimmt die Reihenfolge des Panels, wenn das übergeordnete Panel ein lineares Layout (horizontal oder vertikal) hat
  • "Sub-Konfiguration": Bezieht sich auf eine untergeordnete Konfiguration, welche die View (= konkrete Darstellung des Inhalts) enthält
  • "Aktionen aktivieren aus Panel": Zeigt an, dass eine Aktion in diesem Panel durch die Aktion in einem anderen Panel beeinflusst wird (Bsp.: Anzeige des Suchergebnisses in einem Panel wird durch die Sucheingabe in einem anderen Panel beeinflusst)
  • "Ergebnis anzeigen aus Aktion": Bestimmt, dass durch die Aktion eines anderen Panels in diesem Panel ein Ergebnis in bestimmter Form angezeigt wird (Bsp.: Net-Navigator zeigt die Elemente zu dem Objekt an, das im Suchergebnis-Feld eines anderen Panels angeklickt wurde)


1.7.2 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. 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. 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. 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 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.

1.7.3 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. Style properties in applications

Es gibt eine Reihe von Style-Elementen, die bereits in i-views 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": { ... }
} Style-Eigenschaften im 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.
1.7.4 Actions

Die Aktionen von i-views sind in vorkonfigurierte Aktionsarten unterteilt. Diese Aktionsarten sind wie folgt kategorisiert:

  • Universelle Aktionen (anwendbar in Knowledge und Viewconfiguration-Mapper)
  • Knowledge-Builder spezifische Aktionen
  • Viewconfiguration-Mapper spezifische Aktionen
  • Interne Aktionen (nur für administrativen Gebrauch)

Je nach Aktionsart und Anwendungsfall sind zusätzliche Konfigurationen erforderlich, wie beispielsweise das Anlegen zusätzlicher Panels zur Anzeige der Ergebnisse einer Aktion. General

Mit Hilfe von Aktionen lassen sich Zusatzfunktionalitäten an View-Konfigurationen 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 anderen 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. Neben dem Konfigurations-Element Menü bieten auch manche anderen Elemente das Hinzufügen von Aktionen an.

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 im Knowledge-Builder kein Button angezeigt.

In einer anderen Applikation sind Schaltflächen mit einer Beschriftung und/oder einer Symbolgrafik möglich. Zusätzlich kann ein Tooltip konfiguriert werden.

Wichtige Anmerkung: Aktionen jeglicher Art lassen sich an verschiedensten Stellen anbringen. In den meisten Fällen werden diese auch angezeigt. Ob diese Aktion, in dem Kontext in dem sie gerade eingesetzt wird, ausführbar ist, ist nicht immer gegeben.


Name Wert
Aktionsart Die Art der Aktion. Die verschiedenen Arten werden weiter unten erklärt. Ist keine Aktionsart ausgewählt wird lediglich das Skript ausgeführt.
ausführen in View View in der die Aktion ausgeführt werden soll.
Benachrichtigung Text der in einer Banchrichtigung angezeigt wird, die nach der Aktion eingeblendet wird.
Beschriftung Hier lässt sich eine Beschriftung für die Schaltfläche der Aktion festlegen.
Ergebnis anzeigen in Panel Ein Panel in dem das Ergebnis der Aktion angezeigt werden soll.
Skript für Zielobjekt .
Frage vor der Ausführung Hier lässt sich ein Text angeben, der dem Nutzer vor dem Ausführen der Aktion in einem Dialogfenster angezeigt werden soll. Der Dialog bietet die Möglichkeit die Aktion abzubrechen oder fortzusetzen.
Kontext von .
Nachricht .
Panel schließen Legt fest ob das Panel nach der Aktion geschlossen werden soll.
Skript Das Skript das bei dieser Aktion ausgeführt werden soll. Nicht bei allen Aktionsarten verfügbar.
Skript (ActionResponse) Ein hier angegebenes Skript führt eine sog. ActionResponse nach der Aktion aus. Nicht bei allen Aktionsarten verfügbar.
Skript (enabled) Hier kann über ein Skript ermittelt werden, ob die Schaltfläche der Aktion aktiviert und damit ausführbar sein soll.
Skript (visible) Hier kann über ein Skript ermittelt werden, ob die Schaltfläche der Aktion angezeigt werden soll.
Skript für Benachrichtigung Der Inhalt der Benachrichtigung kann hier über ein Skript ermittelt werden.
Skript für Beschriftung Die Beschriftung kann hier über ein Skript festgelegt werden.
Skript für Frage vor der Ausführung Der Text des Bestätigungs-Dialogs für die Aktion kann hier über ein Skript ermittelt werden. Wird eine leere Zeichenkette zurückgegeben, erscheint der Dialog nicht.
Skript für Nachricht .
Skript für Tooltip Hier kann über ein Skript der Inhalt des Tooltips der Aktion bestimmt werden, anstatt den Text der Beschriftung zu verwenden.
Start-Wissensnetzelement von .
Symbol Hier lässt sich ein Symbol auswählen, daß auf der Schaltfläche der Aktion angezeigt werden soll.
Tooltip Hier kann der Inhalt des Tooltips der Aktion festgelegt werden, anstatt den Text der Beschriftung zu verwenden.
Transaktion (ActionRequest) Art der Transaktion die für die Aktion verwendet werden soll. Zur Auswahl stehen Automatisch, Durch Skript gesteuert, Lesen und Schreiben.
Ursprüngliche Position verwenden . Universell anwendbare Aktionen Graphisch-Darstellen-Aktion

Die Aktion "Graphisch darstellen" wird in einer Frontend-Konfiguration dazu verwendet, um Objekttypen, Relationen und Objekte graphisch im Net-Navigator darzustellen. Die Konfiguration sieht dabei folgendermaßen aus:

Hierfür muss unter "Ergebnis anzeigen in Panel" ein Panel angegeben werden, das als Sub-Konfiguration ein Graph-Objekt enthält. Das Graph-Objekt wiederum muss für die Definition der darzustellenden Elemente eine Graph-Konfiguration enthalten: Löschen-Aktion

Diese Aktion Löscht das jeweilige Element. Im Web-Frontend ist diese Aktion unpraktikabel, weil danach das gelöschte Element angezeigt wird - also nichts mehr zu sehen ist. Löschen wird daher im FrontEnd fast immer durch eine Aktion mit Skript realisiert. Suchen-Aktion

Diese Aktion löst die Suche aus. Im KB ist diese Funktion als Button in der Menüleiste von Objektlisten integriert (Shortcut Strg + S):

Bei Verwendung für die Konfiguration des Web-Frontends wird die Aktion mittels Dropdown-Auswahl unter dem Eintrag "Aktionsart" einer Aktion zugewiesen:

Tipp: Wird eine Such-Funktion mit Zeichenketten-Eingabe (Stichwortsuche) benötigt, so kann alternativ hierzu die Suchfeld-Ansicht in der Viewkonfiguration verwendet werden. Hier sind Eingabezeile und Suche-Button bereits vorkonfiguriert; das Suchergebnis kann in Kombination mit der Suchergebnis-Ansicht angezeigt werden. Aktionen fĂĽr den Knowledge-Builder Aktualisieren-Aktion

Im KB wird mit dieser Aktion der sichtbare Inhalt von Tabellenzellen neu berechnet. Verfügbar ist diese Option in der Menüleiste von Objektlisten unter dem Button "Aktualisieren" (Shortcut F5). Drucken-Aktion

Diese Aktion findet in der Menüleiste von Listenansichten Verwendung.  Mit der voreingestellten Konfiguration können Objektlisten ausgedruckt oder in Form einer Excel-Tabelle ausgegeben werden, ohne dass dafür ein Export-Mapping angelegt werden muss.

Die Aktion "Drucken" öffnet den Drucken-Dialog im Knowledge-Builder:


Die Drucken-Aktion ist des Weiteren in den Ergebnislisten von Strukturabfragen verfügbar. Für die Konfiguration individueller Ansichten im Knowledge-Builder ist die Aktion für die jeweilige View oder das Konfigurationselement hinzuzufügen:

Voraussetzung für die Anwendbarkeit der Aktionsart "Drucken" ist das Vorhandensein der Drucken-Komponente, welche bei Bedarf mithilfe des Admin-Tools nachinstalliert werden kann. Handbuch-Aktion

Die Aktionsart "Handbuch" ist für die Startansicht des KB verwendbar.

Bei dieser Aktion wird ein Web-Handbuch im Browser geöffnet.


Name Wert
URL Weblink zum Handbuch. Homepage-Aktion

Diese Aktionsart ist für die Startansicht des KB verwendbar. Die Homepage wird im Browser geöffnet.


Name Wert
URL Link zu einer Webseite. Im-Baum-Anzeigen-Aktion

Mithilfe der Im-Baum-Anzeigen-Aktion kann die Verortung eines Elementes aus dem Semantischen Netz angezeigt werden. Das Ausführen der Aktion führt dazu, dass zum gewählten Element (bspw. Eintrag einer Listenansicht) die entsprechende Stelle im Strukturbaum des Organizers (linke Spalte des KB) markiert wird und sich die Detailansicht des Elements öffnet. Suchergebnis-Speichern-Aktion

Werden im Knowledge-Builder Suchen mittels einer Strukturabfrage ausgeführt, so können die Ergebnisse per Klick auf den Button in der Menüleiste abgespeichert werden:

Diese Aktion speichert das Suchergebnis in einem wählbaren Ordner:

Hinweis: Die abgespeicherte Suche ist eine Objektliste, welche auf der Konfiguration einer Strukturabfrage zu aktuell vorhandenen Wissensnetzelementen basiert. Werden nach der Speicherung des Suchergebnisses Veränderungen an den entsprechenden Elementen vorgenommen, so wirkt sich dies auch auf die abgespeicherten Ergebnisse aus: Bei einer Löschung des jeweiligen Elementes ist dieses auch im abgespeicherten Suchergebnis nicht mehr vorhanden. Support-Email-Aktion

Diese Aktionsart ist für die Startansicht des KB verwendbar. Die daring enthaltene Aktion öffnet einen Dialog, in dem man eine e-mail an die konfigurierte Adresse senden kann.



Name Wert
URL Email-Link. Zuletzt-Verwendete-Objekte-Aktion

Zeigt die zuletzt verwendeten Objekt (Wissensnetzelemente) in der jeweiligen Tabelle an. Je nach Definition der Tabelle werden die Objekte ggf. gefiltert.

Diese Aktion ist im KB für Listenansichten vorkonfiguriert und kann mittels Tastenkürzel Strg-R aufgerufen werden. Aktionen fĂĽr den Viewconfiguration-Mapper Anzeigen-Aktion

Diese Aktion initiiert eine Neu-Berechnung einer geeigneten View für das semantische Objekt, welches Ziel der Aktion ist. Typischerweise verwendet man diese Aktion, wenn man einen Wechsel der Ansicht bewirken möchte. Ergebnis der Aktion ist eine neue View. Auswahl-Aktion

Diese Aktion entspricht der "Anzeigen"-Aktion mit dem einzigen Unterschied, dass die Aktion auf dem Parameter "selectionElement" - also auf einem ausgewählten Element ausgeführt wird. Achtung: Dieser Effekt gilt auch für ein ggf. vorhandenes Skript.

Die Aktion "Auswahl" wird ausschließlich (aber nicht zwingend) verwendet, um bei Klick auf einen Tabelleneintrag oder auf einen Listeneintrag aus einem Suchergebnis in einem anderen Panel eine Anzeige hervorzurufen. Eine häufiger Anwendungsfall ist das Anzeigen von Detailinformationen zu einem bestimmten semantischen Element.

Zu beachten ist, dass in der jeweiligen "Auswahl"-Aktion selbst angegeben ist, auf welches Panel sich die Aktion auswirken soll. Dies wird unter "Ergebnis anzeigen in Panel" angegeben. Update-Aktion

Die Update-Aktion speichert die Formulardaten aus dem Web-Frontend im Wissensnetz. Das Web-Frontend erkennt die Aktionsart automatisch und schickt sie an die konfigurierte View. Ist keine View als Empfänger der Aktion konfiguriert, versucht das Web-Frontend eine passende View in einem benachbarten Panel zu finden.

Hierzu wird der Aktion in einem Menü die Aktionsart "Speichern" zugewiesen:

Die Update-Aktion kann beipielsweise dazu verwendet werden, um die einzelnen Speichern-Buttons mehrerer Edit-Felder in einem Dialog durch einen individualisierten Speichern-Button zu ersetzen. NN-Expand

Bei NN-Expand handelt es sich um eine Aktionsart, die das Aufklappen eines Graph-Knoten im Net-Navigator ermöglicht. D.h. es werden alle Knoten eingeblendet, die über eine Relation mit diesem Knoten verbunden sind und durch die Graph-Konfiguration zugelassen werden. Die betroffenen Relationen zwischen den Knoten werden ebenfalls angezeigt. Knoten, die bereits im Net-Navigator angezeigt wurden, zeigen nur zusätzlich die relevanten Relationen an. 

Die Darstellung mit einem Plus-Symbol wie im Bild unten ist bereits voreingestellt. Ebenfalls bereits konfiguriert ist das Dialog-Fenster, dass sich nach Klick auf den Plus-Button öffnet, wenn zu viele Relationen davon betroffen sind. In diesem Dialog kann eine Auswahl getroffen werden, welche Knoten angezeigt werden sollen.



Die Aktion wird in der Graph-Konfiguration an allen Knotenkategorien angebracht, die sie besitzen sollen. Im Reiter "Knoten" wird ein Menü erstellt, das alle NN-Aktionen enthalten kann. In der Aktion selbst muss nur die Aktionsart "NN-Expand" ausgewählt werden, andere Angaben sind optional. Die Aktionsart wird möglicherweise nicht im Dropdown-Menü angeboten, weitere Aktionsarten sind über den "..."-Button daneben abrufbar. NN-Hide

Mit der Konfiguration dieser Aktionsart wird an den Graph-Knoten ein Menü-Button bereitgestellt, der den ausgewählten Graph-Knoten und dessen angezeigte Relationen einmalig ausblendet (s. durchgestrichenes Auge im Bild). Der Knoten kann beispielsweise mit dem Ausklappen eines anderen verbundenen Knotens wieder angezeigt werden.

Die NN-Hide-Aktion wird wie die NN-Expand-Aktion konfiguriert, als Aktionsart wird statt "NN-Expand" allerdings "NN-Hide" ausgewählt. Um mehr als eine Aktionsart an einem Knoten zu konfigurieren, müssen mehrere Aktionen an einem Menü angelegt werden. NN-Pin-Aktion

Über die NN-Pin-Aktion wird ein Menü-Button konfiguriert, der das Festpinnen eines Knotens im Net-Navigator ermöglicht. Wenn der Graph sich automatisch neu ordnet, beispielsweise beim Ausklappen eines anderen Knotens, bleibt der festgepinnte Knoten an seiner Position. Der Knoten kann trotzdem manuell verschoben werden und der Pin löst sich wieder beim Neuladen des Graphen. Erneutes klicken auf den Pin löst diesen ebenfalls wieder. Der "gepinnt"-Status wird durch eine veränderte Grafik angezeigt (der Pin zeigt nach unten statt schräg zu liegen). 

Die Konfiguration der Aktionsart erfolgt wie in der "NN-Expand-Aktion" beschrieben. Scripts of actions


Dieses Skript wird ausgeführt, wenn die Aktion ausgeführt wird. Der Rückgabewert wird an das optionale ActionResponse-Skript weitergereicht.

function onAction(element, context)
	return element;


element Das semantische Element, in dessen Kontext die Aktion ausgeführt wird
context Weitere vordefinierte Variablen, die den Kontext der Aktion näher beschreiben

Das Skript einer Aktion kann auf folgende vordefinierte Variablen, in context enthalten, zugreifen:




selectedElement Ausgewähltes Objekt oder ausgewählter Typ
type Objekttyp. Falls das Element ein Typ ist, wird der Typ selbst verwendet




selectedElement Ausgewähltes Objekt oder ausgewählter Typ. Undefined, falls kein Element oder mehrere Elemente ausgewählt wurden.
selectedElements Ausgewählte Elemente
elements Alle Elemente der Objektliste
type Typ der Objektliste


Bei schreibenden Änderungen ist eine Transaktion erforderlich. Bei Ausführung über den ViewConfigMapper kann man über die Eigenschaft "Transaktion" steuern, ob und welche Art von Transaktion verwendet werden soll. Standardmäßig ist eine schreibende Transaktion aktiv.

Im Knowledge-Builder ist grundsätzlich keine Transaktion aktiv. Das Skript muss Transaktionen selber steuern.


Im Knowledge-Builder steht ein weitere Variable zur Interaktion mit dem Benutzer zur Verfügung:

ui Objekt $k.UIObject

Beispielsweise kann eine Meldung anzeigen:

ui.alert("Aktuelles Element: " + element.name());


Skript (ActionResponse)

Dieses Skript wird nach der Ausführung der Aktion ausgeführt. Hauptaufgabe ist es, das Ergebnis der Aktion für den ViewConfigMapper (oder andere Frontends) aufzubereiten. Das Skript muss ein Objekt vom Typ $k.ActionResponse liefern.

function actionResponse(element, context, actionResult)
	var actionResponse = new $k.ActionResponse();


	return actionResponse;


element Das semantische Element, in dessen Kontext die Aktion ausgeführt wird
context Weitere vordefinierte Variablen, die den Kontext der Aktion näher beschreiben (siehe vorherigen Abschnitt)
actionResult Der Rückgabewert des onAction-Skripts bzw. falls nicht definiert der Rückgabewert der konfigurierten Aktionsart.


Die ActionResponse kann um Werte für Followup / Data und Notification erweitert werden. Diese Werte können von anderen Anwendungen wie z.B. dem ViewConfigMapper ausgewertet werden.

Im Knowledge-Builder sind folgende Werte von Followup in Tabellen möglich:

refresh Rendert die aktuelle Tabelle neu, ohne die Liste neu zu berechnen
update Berechnet die Tabelle neu
show-element Selektiert das Element in data in der Tabelle an. Alternativ kann in data ein Objekt {"element": actionResult, "viewMode": "edit" } das Ergebnis in einem neuen Detaileditor geöffnet werden

In Detail-Editoren wird Followup nicht ausgewertet.

Skript (visible)

function actionVisible(element, context) 
	return true;

Anhand des Rückgabewertes wird entschieden, ob der Knopf angezeigt werden soll oder nicht.

In Tabellen wird bei Aktionen auf den Elementen folgende Funktion aufgerufen, die einen Array von Elementen übergibt und einen Array von boolschen Werten erwartet. Dies kann dazu verwendet werden, die Sichtbarkeit für die Elemente effizienter am Stück zu berechnen.

function actionsEnabled(elements, contexts)
    return elements.map(function (element, index) {
        return actionEnabled(element, contexts[index]);

Skript (enabled)

function actionEnabled(element, context)
	return true;

Anhand des Rückgabewertes wird entschieden, ob der Knopf aktiv ist.

In Tabellen wird bei Aktionen auf den Elementen folgende Funktion aufgerufen, die einen Array von Elementen übergibt und einen Array von boolschen Werten erwartet:

function actionsVisible(elements, contexts)
	return elements.map(function (element, index) {
		return actionVisible(element, contexts[index]);

UI-spezifische Funktionen

Das die Aktion realisierende Skript kann im Knowledge-Builder über context.ui auf UI-spezifische Funktionen zurückgreifen.

UI-Funktionen sollten nach Möglichkeit nicht innerhalb von Transaktionen ausgeführt werden, da sich die Anzeige innerhalb der Transaktion nicht aktualisiert.

context.ui.alert(message, windowTitle)

Zeigt eine Meldung an.

context.ui.requestString(message, windowTitle)

Benutzer kann eine Zeichenkette eingeben.

context.ui.confirm(message, windowTitle)

Öffnet einen Abbrechen-Dialog. 

context.ui.choose(objects, message, windowTitle, stringFunction)

Objekt aus einer Menge auswählen lassen. 


Standardeditor für das Objekt öffnen. 

context.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 der Funktion geöffnet. true


    function() {
        for (var i = 0; i < 10; i ++)
            ui.raiseNotification("" + i + "*" + i + "=" + (i*i));
        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. Interne Aktionen

Der Gebrauch interner Aktionen setzt fachspezifisches Wissen voraus.
Bei Unklarheiten hierzu wenden Sie sich an den Support von i-views: support@i-views.com.

Die in diesem Kapitel aufgeführten Aktionen sind lediglich aus Gründen der Vollständigkeit aufgeführt. Hierzu zählen Aktionen wie:

  • Einblenden-Aktion
  • Sortierung-Aktion
  • Springen-Aktion
  • Ziel anlegen-Aktion



Dieser Aktionstyp hat keine Auswirkung. Das Vorhandensein eines Skriptes an einer Aktion bewirkt automatisch dessen Ausführung, überschreibt also die eingebaute Funktion der jeweiligen Aktionsart.

1.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.

1.7.6 Panels

Panels sind Konfigurationselemente, welche die Anwendungsoberfläche in Bereiche aufteilen. Mit ihnen wird das grundsätzliche Layout einer Anwendung aufgebaut.

Panels beinhalten weitere Panels oder View-Konfigurationen und können ineinander verschachtelt werden. Sie können sich gegenseitig beeinflussen.

Panels erhalten immer genau ein Startelement (ein Objekt oder einen Typ) bei ihrer Aktivierung, welches sie an ihre Unterkonfigurationen weiter geben.

Panels selbst haben ansonsten keinerlei Funktion. Diese werden erst mit Hilfe von Aktionen und View-Konfigurationen festgelegt.

Es gibt verschiedene Arten von Panels:

  • Hauptfensterpanel
  • Dialogpanel
  • Fenstertitelpanel
  • Fußzeilenpanel
  • Normale Panel

Für jede Anwendung muss genau ein sogenanntes Hauptfensterpanel existieren, welches durch untergeordnete Panels aufgeteilt werden kann. Zusätzlich kann ihm ein Fenstertitelpanel zugeordnet werden, welches den Titel und das Logo (Favicon) der Anwendung festlegt.

Weiterhin können einer Anwendung weitere Dialogpanel zugewiesen werden, die als Pop-Up über dem Hauptfenster angezeigt werden können. Diese können neben weiteren Panels auch Fenstertitel- und Fußzeilenpanel enthalten.

Für jedes Panel  muss ein bestimmter Paneltyp ausgewählt werden.

  • Layout-Panels (enthalten weitere Panels):
    • Lineares Layout (alle untergeordnete Panels werden horizontal oder vertikal angeordnet dargestellt)
    • Wechselndes Layout (nur eines der untergeordneten Panels wird zur gleichen Zeit angezeigt)
  • Ansicht-Panels (enhalten View-Konfiguration(en)):
    • Festgelegte Ansicht (enthält ein einziges festgelegtes Konfigurationselement)
    • Flexible Ansicht (mehrere Ansichten je nach Typ des Startelements möglich)


Name Wert
Aktionen aktivieren in Panel Alle Aktionen, die im Quell-Panel aktiviert werden, führen dazu, dass das Ziel-Panel mit dem jeweilig übergebenen Objekt angezeigt werden (Beispiel: Jeder Klick im Panel Objektliste führt dazu, dass im Panel Detailansicht das Ergebnis angezeigt wird).
beeinflusst Hier kann ein Panel festgelegt werden, dass vom aktuellen Panel beeinflusst wird (Beispiel: Je nachdem welche Objekte bei Suchergebnis angezeigt werden, beeinflusst das welche Facetten dazu angezeigt werden).
Skript für Zielobjekt Mithilfe von Skripten können hier nicht einfach nur Panels, sondern auch Bedingungen angegeben werden unter denen bestimmte Panels durch das aktuelle Panel beeinflusst werden.

Einstellungsmöglichkeiten Layout

Name Wert

CSS-Klassen für das Panel (wird nur für Web-Anwendungen bzw. im ViewConfig-Mapper berücksichtigt) 

Breite / Höhe

Die exakten Maße des Panels können hier jeweils entweder prozentual oder pixelgenau gesetzt werden.

Maximale Breite / Höhe

Alternativ lassen sich hier die Höchstmaße des Panels angeben. Das Panel nimmt sich so viel Platz wie es benötigt, ohne diese Werte zu überschreiten.

Flex-grow / -shrink

Hier lassen sich die Werte für die jeweilige CSS-Eigenschaft für den Wachstums- bzw. Schrumpffaktor des Panels angeben. Ein Element mit einem Wert von 2 für flex-grow zum Beispiel, erhält doppelt so viel Platz wie ein Element mit Wert 1.

overflow-x / -y (Scrollbar)

Hierüber lässt sich die Darstellung von Scrollbars in der Applikation festlegen, wenn der Inhalt des Panels nicht in seine horizontale (x) und vertikale (y) Abmessungen passt. Zur Auswahl stehen auto, scroll und hidden.


CSS-Styling-Regeln für das Panel (wird nur in Web-Anwendungen bzw. im ViewConfig-Mapper berücksichtigt) Aktivierung von Panels

Panels kennen zwei grundsätzliche Zustände: "aktiv" und "inaktiv". Ein Panel ist sichtbar, wenn es aktiv ist.

Die Aktivierung von Panels funktioniert über folgende Mechanismen:

A. Zum Start einer Anwendung ist immer das Haupfenster-Panel der Anwendung aktiv

B. Beim Ausführen einer Aktion bestimmt der Ausführungsort, welches Panel aktiv wird

Ausgehend von A/B gibt es Folge-Aktivierungen nach diesen Regeln:

  1. Beeinflusste Panels werden aktiviert
  2. Panels mit einer spezialisierten Funktion  (z.B. Fenstertitel) werden aktiviert - und zwar von allen Panels in der entsprechenden Hierarchie aus
  3. Unterpanels werden aktiviert
  4. Im Falle eines Panels mit wechselndem Layout: Geschwister-Panels des aktiven Unterpanels werden deaktiviert
  5. Fortfahren bei 1. bis keine weiteren Panels mehr aktiviert werden können (eine eingebaute Zyklenprüfung verhindert Endlosschleifen)

Folge-Aktivierungen transportieren jeweils das angezeigte Modell. Wenn also beispielsweise Panel A das Objekt "Herr Meier" anzeigt, dann zeigt das aktivierte Unterpanel B ebenso "Herr Meier" an.

Zuletzt wird sichergestellt, dass alle Panels oberhalb der aktivierten Panels ebenso aktiv sind. Dabei wird deren Inhalt aber nicht neu berechnet.

Fortgeschrittene Aktivierungsmechanismen (ab Version 5.2):

In Schritt A (Aktionsaktivierung) sowie in Schritt 1 (Beeinflussung) kann über den sogenannten "Aktivierungsmodus" die Berechnung der Panel-Inhalte optimiert werden.

Auf diese Weise kann vermieden werden, dass Panel-Inhalte neu berechnet werden, die aktuell nicht angezeigt werden, weil sie trotz Aktivierung nicht im Sichtbarkeitsbereich liegen (z.B. ein Warenkorb). Für diesen Fall gibt es die Option "Lazy".

Analog dazu kann mit der Option "Aktualisierung" eine Auslösung der Aktivierungskette vermieden werden. Hier wird nur der Inhalt des Panels neu berechnet.

Die Option "Anzeige" ist der Standard, wenn keine der beiden obigen Optionen gewählt wurde. Layout-Panels

Mit Layout-Panels wird die Anwendung in verschiedene Bereiche unterteilt. Lineare Layouts ordnen untergeordnete Panels entweder nebeneinander oder untereinander an. Wechselnde Layouts erlauben alternative Darstellungen auf der gleichen Visualisierungsfläche, bei denen nur eines der untergeordneten Panels gleichzeitig angezeigt wird.

Einstellungsmöglichkeiten Konfiguration

Name Wert
Standardmäßig erstes aktivieren (nur bei wechselndes Layout)

Wird hier der Haken gesetzt, heißt das, dass das erste untergeordnete Panel standardmäßig aktiviert ist (im Beispiel unten ist das die Startseite) View-Panels

Ansicht-Panels dienen als Container für einzelne Ansichten. Sie können dafür keine weiteren Panels enthalten.


Name Wert

Hier kann ein konkretes Objekt oder ein konkreter Typ angegeben werden, der als Ausgangselement dient, von dem aus weitere Wege durch das Netz gegangen werden können.

Start-Wissensnetzelement nicht überschreiben

Wenn diese Option aktiviert ist, wird immer das konfigurierte Start-Wissensnetzelement verwendet. Die Beeinflussung durch andere Panels hat dann keine Auswirkung auf das Startelement.

Falls kein Kontextelement konfugiert ist, bleibt das Kontextelement leer.

Skript für Start-Wissensnetzelement

Das Skript bestimmt das Startelement. Als Argument wird das äußere Kontextelement übergeben.

Die Option "Start-Wissensnetzelement nicht überschreiben" hat keinen Einfluss, das Skript wird immer ausgeführt.

Sub-Konfiguration (nur bei festgelegte Ansicht)

Hier kann die eine View-Konfiguration angegeben werden, die für die festgelegte Ansicht genutzt wird. Dialog-Panels

Dialog-Panels sind spezielle Anzeigebereiche, deren Inhalte in einem Dialogfenster angezeigt werden. Die Dialogfenster werden automatisch sichtbar, wenn das entsprechende Dialog-Panel aktiviert wird. Die Aktivierung kann so wie bei anderen Panels auch gezielt über bestimmte Aktionen erfolgen (siehe Relation "Ergebnis anzeigen in Panel" in Aktionskonfigurationen) oder generell bei Aktivierung bzw. Aktualisierung anderer Panels (siehe Relationen "Aktionen aktivieren in Panel" und "beeinflusst" in anderen Panel-Konfigurationen).

Zum Ausblenden ("Schließen") von Dialogfenstern müssen ebenfalls Aktionen verwendet werden. Ist in einer Aktionskonfiguration das Attribut "Panel schließen" angehakt, so führt die Ausführung dieser Aktion in einem Dialogfenster dazu, dass das Fenster ausgeblendet wird. Die Aktion muss dau also mit einem Menü verknüpft sein, welches im Dialog-Panel selbst oder einem seiner untergeordneten Panels angezeigt wird.

Dialogfenster werden inhaltlich in die folgenden drei Bereiche unterteilt:

  • Fenstertitel
  • Inhaltsbereich
  • Fußzeile

Die Inhalte und das Layout innerhalb der drei Bereiche können jeweils über eine eigene Panel-Konfiguration festgelegt werden. Das Dialog-Panel selbst steht dabei stellvertretend für den Inhaltsbereich. Zur Konfiguration von Fenstertitel und Fußzeile muss am Dialog-Panel eine Unterkonfiguration vom Typ Fenstertitel- oder Fußzeilen-Panel angelegt werden (siehe Beispiel unten).

Über das Attribut "Paneltyp" am Dialog-Panel selbst sowie an dessen Fenstertitel- und Fußzeilen-Panels kann bestimmt werden, ob das jeweilige Panel Layout- oder Ansichtsfunktionalitäten bereitstellt. Details zu den verschiedenen Paneltypen sind in den vorangehenden Kapiteln beschrieben. 

Dialog-Panels können im Knowledge-Builder folgendermaßen angelegt werden:

  1. Melden Sie sich mit einem Benutzerkonto im Knowledge-Builder an, das über Administrator-Berechtigungen verfügt
  2. Öffnen Sie im Navigationsbereich auf der linken Seite die Rubrik "Technik" und wählen Sie den Unterpunkt "View-Konfiguration" aus.

  3. Wählen Sie den Reiter "Anwendung" auf der rechten Seite aus.

  4. Wählen Sie in der Liste darunter die Anwendung, zu der Sie das Dialog-Panel hinzufügen möchten (Normalerweise "Viewkonfiguration-Mapper").

  5. Wählen Sie das oberste Element im Panel-Baum unten aus und Klicken Sie auf das Anlegen-Symbol

  6. Das neu angelegte Dialog-Panel wird im Panel-Baum automatisch ausgewählt und die Detailansicht rechts nebem dem Panel-Baum angezeigt

Zum Anlegen eines Fenstertitel- oder Fußzeilen-Panels muss das Dialog-Panel im Panel-Baum ausgewählt und das Symbol zum Anlegen von Unterkonfigurationen angeklickt werden. Es erscheint daraufhin ein Auswahlfenster, in dem der Eintrag "Fenstertitel" oder "Fußzeile" ausgewählt werden kann. Je nach Paneltyp des Dialog-Panels können auf diesem Weg auch noch andere Unterelemente angelegt werden, die sich dann jedoch auf den Inhaltsbereich des Dialogfensters beziehen.

1.7.7 Basics of View-Configurations Useage of View-Configurations

Auf dem Reiter Verwendung einer View-Konfiguration muss angegeben werden, in welcher Anwendung und für welchen Objekttyp die View-Konfiguration angezeigt werden soll.

Im Feld anwenden in auf dem Reiter Verwendungen wird die Anwendung eingetragen.

Ist keine Anwendung als Verwendung der View-Konfiguration eingetragen, so wird die View-Konfiguration nicht angezeigt. View-Konfigurationen werden als Baumstruktur definiert, in der das Prinzip der Vererbung gilt. Aus diesem Grund muss die Anwendung bei Unterkonfigurationen nicht extra angegeben werden. Sie werden als Teil der Oberkonfiguration mit angezeigt. Zum Beispiel wird eine Eigenschaftskonfiguration angezeigt, wenn diese Teil einer Gruppe ist, deren Verwendung angegeben wurde.

Anwendungen der View-Konfiguration festlegen

Die folgenden Anwendungen stehen von Anfang an zur Verfügung:

  • Graph-Editor: Die Konfigurationen haben Einfluss auf die Darstellung im Graph-Editor. Der Graph-Editor dient zur Visualisierung der semantischen Elemente und deren Zusammenhängen.
  • Knowledge-Builder: Die View-Konfigurationen werden im Knowledge-Builder selbst angewendet. Hier stehen neben den Detailkonfigurationen auch die Objektlisten-Konfigurationen zur Verfügung.
  • Knowledge-Portal: Das Knowledge-Portal ist eine Komponente von i-views, die als Frontend eingesetzt werden kann. Es stellt die Objekte des semantischen Netzes auf Detailseiten und in Kontextboxen basierend auf deren semantischen Kontext dar.
  • Net-Navigator: Er dient zur Visualisierung von semantischen Elementen. Er kann im Gegensatz zum Graph-Editor der Teil des Knowledge-Builders ist, in den Anwendungen Knowledge-Portal und Viewkonfigurations-Mapper eingesetzt werden. 
  • Topic-Chooser: Er ermöglicht die Auswahl von Relationszielen in einem Fenster.
  • Viewkonfiguration-Mapper: Der Viewkonfigurations-Mapper ist ein intelligentes Frontend, das im Gegensatz zum Knowledge-Portal die View-Konfigurationen verwendet. Mit ihm können einfach und schnell Sichten auf die Daten erstellt werden. 

Darüber hinaus können auch eigene beliebige Anwendungen definiert werden, die an dieser Stelle mit der View-Konfiguration verknüpft werden können. 

Objekttyp der View-Konfiguration festlegen

Im Feld anwenden auf wird der Objekttyp automatisch eingetragen, wenn die View-Konfiguration am Objekttyp definiert wird. Hier können nach Bedarf weitere Objekttypen angegeben werden. Je nach dem wo man die View-Konfiguration angelegt hat, entweder unter Objekt oder unter Typ, wird die View für Objekte des ausgewählten Typs oder den Typ einschließlich seiner Untertypen angezeigt. Durch das Setzen oder Wegnehmen des Häkchens des Attributs anwenden auf Untertypen kann diese Auswahl (gültig für Objekte oder Typen) auch nach der Definition der View-Konfiguration geändert werden. 

Wiederverwendung von View-Konfigurationen

View-Konfigurationen können in anderen View-Konfigurationen wieder verwendet werden. So kann man beispielsweise eine Tabelle konfigurieren, die für die Anzeige von mehreren View-Konfigurationen vom Typ Suche eingesetzt wird. Falls die View-Konfiguration Baustein einer anderen View-Konfiguration ist, wird dies unter [inverse] anwenden in angezeigt. Validity of View-Configurations

Im Kapitel Die Verwendung von View-Konfigurationen wurde bereits beschrieben, dass die Angabe über die Verwendung von View-Konfigurationen ausschlaggebend ist ob, in welcher Anwendung und für welche Objekte bzw. Typen die View angezeigt wird. Trotzdem ist es möglich, dass die View-Konfiguration nicht in der ausgewählten Anwendung angezeigt wird. Hier stellt sich die Frage: Wann ist eine View-Konfiguration gültig? Und für welche Objekt bzw. Typen ist die View-Konfiguration gültig?

Vererbung von View-Konfigurationen

View-Konfigurationen verhalten sich in Bezug auf die Vererbung wie Eigenschaften. View-Konfigurationen werden auf die Untertypen bzw. die Objekte der Untertypen vererbt.

Anwendung der konkretesten View-Konfiguration

Die Untertypen verwenden nach dem Prinzip der Vererbung die View-Konfiguration der Obertypen solange sie keine eigenen View-Konfigurationen besitzen. Es wird immer die konkreteste View-Konfiguration angewendet: Das ist die Konfiguration, die direkt am Typ definiert ist. Ist das nicht der Fall, so wird geprüft ob es am Obertyp eine View-Konfiguration gibt. Ist das ebenfalls nicht der Fall so wird in der Typenhierarchie jeweils eine Ebene nach oben gegangen und geprüft ob eine View-Konfiguration definiert ist. Es wird dann diejenige View-Konfiguration angewendet, die dem Objekttyp am nächsten steht. Wird keine View-Konfiguration an den Obertypen gefunden, wird für Administratoren die Default-Konfiguration verwendet.

Was passiert wenn zwei gleichwertige View-Konfigurationen existieren?

Gibt es zwei gleichwertige View-Konfigurationen, so wird keine View-Konfiguration angezeigt. Wurde bei einer View-Konfiguration die Anwendung oder der Objekttyp nicht definiert, zählt diese nicht zu den aktiven View-Konfigurationen. In diesem Fall wird die andere View-Konfiguration verwendet. Möchte man für unterschiedliche Benutzer jeweils andere Views anzeigen, kann im Detektorsystem eine Regel definiert werden. In diesem Fall wird dann die View-Konfiguration entsprechend der definierten Regel angewendet, solange die Regel abhängig von Nutzer nur eine gültige View-Konfiguration liefert.

1.8 JavaScript API
1.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. API reference

The API reference is available here:

www.k-infinity.de/api/4.0/index.html 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. 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. 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"); 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" }
); 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.

1.8.2 Examples 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")); Queries created at runtime

Die Javascript-API erlaubt es auch, Abfragen dynamisch zu generieren. Hier einige Beispiele aus einem Filmnetz:

Suche nach Filmen mit Jahr + Name

var query = new $k.StructuredQuery("imdb_film");
query.addAttributeValue("imdb_film_year", "year");
query.addAttributeValue("name", "name");
query.findElements({year: "1958", name: "Vert*"});

Dem Constructor wird die Domain übergeben. Bei internen Namen wird automatisch nach Objekten dieses Types gesucht. Mehr Möglichkeiten bietet die Funktion setDomains()

Jahr + Anzahl Regisseure >= 3

var query = new $k.StructuredQuery("imdb_film");
query.addAttributeValue("imdb_film_year", "year");
query.addCardinality("imdb_film_regisseur", 3, ">=");
query.findElements({year: "1958"});

Jahr + Name des Regisseurs

var query = new $k.StructuredQuery("imdb_film");
query.addAttributeValue("imdb_film_year", "year", ">=");
var directorQuery = query.addRelationTarget("imdb_film_regisseur").targetQuery();
directorQuery.addAttributeValue("name", "director");
query.findElements({year: "1950", director: "Hitchcock, Alfred"});

Alternativen (Oder-Bedingungen)

var query = new $k.StructuredQuery("imdb_film");
query.addAttributeValue("imdb_film_year", "year");
var alternatives = query.addAlternativeGroup();
alternatives.addAlternative().addAttributeValue("name", "name");
alternatives.addAlternative().addAttributeValue("imdb_film_alternativeTitel", "name");
query.findElements({year: "1958", name: "Vert*"}); 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);

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");

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">
</root> 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) {
} Sending eMails

E-Mails können mit dem MailMessage-Objekt verschickt werden. Dazu muss im Netz ein SMTP-Server konfiguriert werden (Einstellungen -> System -> SMTP).

var mail = new $k.MailMessage();
mail.setSubject("Hello from " + $k.volume());
mail.setText("This is a test mail");

Das Benutzerkonto "kinf" wird für die Authentifizierung verwendet. Das Passwort wird in den SMTP-Einstellungen hinterlegt. Views

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"
} 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
} 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 {
1.8.3 Modules 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")
	}}); 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. 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;

Falls eine Bibliothek ein Modul mit einer bestimmten ID definiert und man diese Bibliothek unter einem anderen Namen registrieren möchte, kann man Module-IDs auf Registratur-IDs abbilden:

 $k.mapModule("underscore", "lib.underscore");

Nun kann man underscore.js als "lib.underscore" registrieren und das fort definierte Modul "underscore" verwenden.

1.8.4 Debugger 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". 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


1.8.5 Extending the API 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
$k.rootType().printSchema(); 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");
1.9 REST services

Über die REST-Schnittstelle kann lesend und schreibend auf das Wissensnetz zugegriffen werden. Dazu definiert man im Wissensnetz Ressourcen (beschreiben das Verhalten der Schnittstelle beim Zugriff auf eine Ressource) und Services (fassen mehrere Ressourcen zusammen).

Das Verhalten einer Ressource wird über Skripte gesteuert. Zusätzlich können auch vordefinierte Ressourcen verwendet werden.

Der Zugriff erfolgt über HTTP-Requests, die nach dem Muster


aufgebaut sind.

1.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 enthalten, 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. Die Zeile mit "services" kann auch komplett weggelassen werden, dann werden die Ressourcen aller vorhandenen Service-Objekte automatisch aktiviert.


1.9.2 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.

1.9.3 Resources

Ressourcen beschreiben das Verhalten bei einer HTTP-Anfrage an die Schnittstelle. Es gibt folgende Arten von Ressourcen:

Script ResourceDurch 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:

Eigenschaft Beschreibung
Path pattern

Definiert die URL der Ressource relativ zur Adresse des Services. Der Pfad kann parametrisiert 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.

Methode Beschreibung
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.

Transaktionssteuerung Beschreibung

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. Script-Ressource

Durch ein Skript wird bei einer Methode einer Script-Ressource die Antwort auf eine HTTP-Anfrage definiert. Von der Schnittstelle wird dazu die Funktion respond(request, parameters, response) aufgerufen, die im Skript definiert werden muss.

request$k.HttpRequestAnfrage (URL, Header, usw.)
parametersObjectAus dem Request extrahierte Parameter

Die Funktion füllt dann Header und Inhalt der Antwort. Einen Rückgabewert gibt es nicht.

Wenn für einen Parameter ein Typ definiert wurde (z.B. xsd:integer), wird der konvertierte Wert übergeben, ansonsten eine Zeichenkette. Bei Parametern, die laut Definition mehrfach vorkommen können, werden diese immer als Array übergeben.

Wenn in der Methode ein Output Content-Type für die Antwort definiert wurde, wird dieser automatisch gesetzt. Alternativ kann der Content-Type auch im Skript definiert werden.

Das folgende Skript sucht Alben und wandelt diese in JSON-Objekte um. Die Parameter der Ressource werden an als Suchparameter an die Abfrage weitergereicht.

function respond(request, parameters, response)
    var albums = $k.Registry.query("albums").findElements(parameters);
    var albumData = albums.map(function(album) {
        return {
            name: album.name(),
            id: album.idString(),
    response.setText(JSON.stringify(albumData, undefined, "\t"));

 Dieses Skript könnte man z.B. mit bei einer Ressource


verwenden und in der Abfrage "albums" die Suchparameter "genre" und "year" als Suchbedingungen verwenden. Built-In Resources

Built-In Resourcen sind vordefinierte Ressourcen, deren Verhalten vom System vorgegeben ist. Jedes vordefinierte Verhalten kann durch einen zugeordneten Wert des Zeichenketten-Attributes Rest resource ID zugeordnet werden.

Rest resource ID


BlobResource GET

Gibt den binären Inhalt eines bestehenden Blob-Attributes zurück.

Das Blob-Attribut wird über den Query-Parameter "blobLocator" identifiziert.

BlobResource POST, PUT

Ändert den binären Inhalt eines Blob-Attributes.

Das Blob-Attribut wird über den Query-Parameter "blobLocator" identifiziert. Je nach Typ des blobLocators wird ein neues Attribut angelegt oder ein bestehendes verändert.



Ausgeben und Einlesen einer XML-Repräsentation eines semantischen Elementes.
ObjectListResource GET Gibt eine Tabelle von Instanzen oder Untertypen von dem angegebenen Typ zurück. Optional kann gefiltert, sortiert oder direkt die Menge der Objekte definiert werden.
ObjectListPrintTemplateResource GET Gibt eine Tabelle von Instanzen oder Untertypen in gedruckter Form zurück. Das Drucktemplate muss angegeben sein.
ObjectListPrintTemplateResourceWithFilename GET Gibt eine Tabelle von Instanzen oder Untertypen in gedruckter Form zurück. Das Drucktemplate muss angegeben sein. Der Parameter {filename} wird nicht ausgewertet und dient allein der besseren Handhabung im Browser.
TopicIconResource GET Gibt das Icon oder Bild des angegebenen semantischen Elementes zurück.

Ab i-views 4.1 kann noch ein Java-Script (rest.preprocessScript) an die Ressource angebracht werden. Die darin enthaltene Funktion preprocessParameters ( parameters, request ) kann die Parameter ergänzen. Aus den übergebenen Parametern kann so etwa der noch fehlende blobLocator (bzw. das zugehörige Blobattribut) ermittelt werden, was sonst einen zusätzlichen Script-Ressource-Aufruf benötigen würde.


Diese eingebaute Resource ermöglicht das Laden und Speichern der Inhalte von Datei-Attributen.


Über die Methode "GET" kann man den binären Inhalt eines bestehenden Datei-Attributes herunterladen. Das Datei-Attribut wird über den Query-Parameter "blobLocator" identifiziert.


Beim Upload identifiziert der Parameter "blobLocator" entweder ein existierendes Datei-Attribut oder ein potentielles (d.h. neu anzulegendes) Datei-Attribut. Die Syntax für ein potentielles Attribut hat die Form: "PP~ID1_115537458~ID36518_344319903", wobei die erste ID das Wissensnetzelement und die zweite ID den Attribut-Prototyp repräsentiert.

Die Binärdaten können wahlweise als Multi- oder Singlepart übertragen werden. Bei Multipart können potentiell mehrere Dateien gleichzeitig hochgeladen werden, was natürlich nur Sinn macht, wenn jede Datei in ein neu anzulegendes Datei-Attribut geschrieben wird. In jedem Fall ist zu jeder übertragenden Datei der Dateiname zu setzen.

Der optionale Parameter "binaryKey" definiert den form-key, unter dem die Binärdaten im MultiPart übertragen werden.

Setzt man den optionalen booleschen Parameter "uploadOnly" auf "true", dann werden nur die Binärdaten hochgeladen jedoch nicht ins Datei-Attribut geschrieben. Dieser Modus wird im Zusammenspiel mit dem ViewConfig-Mapper verwendet. Rückgabe ist in diesem Fall der JSON-Wert (fileName, fileSize, binaryContainerId), der dann in einem zweiten Schritt über den Mapper in das Attribut geschrieben werden kann. Der Content-Type der Rückgabe des JSON-Werts ist normalerweise "application/json", kann aber über den Parameter "overrideContentType" auf einen anderen Wert gesetzt werden, falls der Browser (z.B. IE) Probleme damit hat.

Topic Icon

Über den folgenden Pfad kann man die Bilddatei zu einem gegebenen Topic laden. Wenn ein Individuum keine eigene Bilddatei hat, wird auf die Bilddatei des Typs zurückgegriffen, welche wiederum vererbbar ist. Über den optionalen Parameter "size" kann man die Bilddatei mit der am ehesten passenden Größe selektieren, vorausgesetzt im Wissensnetz sind mehrere Bildgrößen hinterlegt.




Über den folgenden Pfad kann eine Objektliste im JSON-Format angefordert werden: 


Der Typ der Objektliste wird über den Parameter "conceptLocator" referenziert, dem Format für Topic-Referenzen in der Rest-URL folgt. (siehe Verknüpfung)

Alternativ kann der "conceptLocator" auch den einen Prototyp (Individuum oder Typ) des zu verwendenden Typs referenzieren.

Der optionale Parameter "name" bestimmt die Objektliste, die für die Ausgabe verwendet werden soll.


Über den optionalen und mehrwertigen Query-Parameter "filter" kann die Objektliste gefiltert werden. Ein Filter hat zwei mögliche Formen:

  1. <Spalten-Name/Spalten-Nr.> ~ <Operator> ~ <Wert>
  2. <Spalten-Name/Spalten-Nr.> ~ <Wert>

Mögliche Operatoren sind: equal, notEqual, greater, less, greaterOrEqual, lessOrEqual, equalCardinality, containsPhrase, covers, isCoveredBy, distance, fulltext, equalGeo, equalPresentTime, greaterOverlaps, greaterPresentTime, lessOverlaps, lessPresentTime, equalMaxCardinality, equalMinCardinality, overlaps, unmodifiedEqual.


Über den optionalen und mehrwertigen Query-Parameter "sort" kann die Objektliste sortiert werden. Die Reihenfolge der Sortierparameter bestimmt die Sortierpriorität. Die Angabe der Sortierung hat zwei mögliche Formen:

  1. <Spalten-Name>
  2. {-}<Spalten-Nr.>

Stellt man in Variante 2 ein Minus vor, wird absteigend sortiert, sonst aufsteigend.

Startmenge der Liste setzen

Über den optionalen QueryParameter "elements" kann eine Komma-separierte Liste von Topic-Referenzen übergeben werden, die als Listenelemente verwendet werden sollen.

Da die Liste der Element ggf. sehr lang ist, kann der Request auch als POST geschickt und die Parameter als Form-Parameter übergeben werden.

Startmenge der Liste über KPath setzen

Über die optionalen Query-Parameter "elementsPath" und "startTopic" können die initialen Elemente der Liste berechnet werden. Sind diese Parameter nicht gegeben, besteht die Ausgangsmenge aus allen Individuen bzw. allen Untertypen (im Falle einer Typ-Objektliste) des per "conceptLocator" festgelegten Typs.

Dabei ist "elementsPath" ein KPath-Ausdruck und "startTopic" eine Referenz auf das Topic, mit dem die Auswertung des KPath gestartet werden soll. Die Form des Parameters "startTopic" entspricht der des "conceptLocator".


Über den optionalen Query-Parameter "disableInheritance" kann die Vererbung unterdrückt werden. Der Paramater macht nur Sinn, wenn kein "elementsPath" gesetzt ist.

 JSON-Ausgabeformat (Beispiel)

 rows: [{
  topicID: "ID123_987654321",
  row: ["MM",
  "Projekt A, Projekt B"]
  topicID: "ID987_123456789",
  row: ["MF",
  "Projekt X, Projekt Y, Projekt Z"]
 columnDescriptions: [{
  label: "Login",
  type: "string",
  columnId: "1"
  label: "Nachname",
  type: "string",
  columnId: "2"
  label: "Vorname",
  type: "string",
  columnId: "3"
  label: "Telefondurchwahl",
  type: "string",
  columnId: "4"
  label: "Email",
  type: "string",
  columnId: "5"
  label: "Verfügbarkeit",
  type: "number",
  columnId: "6"
  label: "Aufwand",
  type: "string",
  columnId: "7"
  label: "erstellt am",
  type: "dateTime",
  columnId: "8"
  label: "Projekt",
  type: "string",
  columnId: "9"


Über den folgenden Pfad kann eine Objektliste in eine 'Druckvorlage für Liste' gefüllt und das Resultat heruntergeladen werden:



Der Service funktioniert genau wie der Abruf einer Objektliste, trägt aber als zuätzlichen Parameter eine Referenz auf das Individuum des Typs 'Druckvorlage für Liste' im Wissensnetz.

"templateLocator" muss eines der unter "Allgemeines" beschriebenen Formate haben

Der optionale Pfad-Parameter "filename" wird nicht ausgewertet und dient dem besseren Browser-Handling.

Über das Header-Field "Accept" wird gesteuert, in welches Ausgabeformat konvertiert werden soll. Fehlt das Header-Field oder ist der Wert "*/*", findet keine Konvertierung statt. Mehrwertige Accept werden nicht unterstützt und resultieren in einer Fehlermeldung.

Über den optionalen Query-Parameter "targetMimeType" kann der Wert des "Accept" Header-Fields überschrieben werden. Dies ist notwendig, wenn man den Request aus einem Browser aufrufen möchte und dort keinen Einfluss auf die Header-Fields hat.

 Topic drucken 

Über den folgenden Pfad kann ein Topic in ein Drucklistentemplate gefüllt und das Resultat heruntergeladen werden: 



"templateLocator" muss eines der unter "Allgemeines" beschriebenen Formate haben

Der optionale Pfad-Parameter "filename" wird nicht ausgewertet und dient dem besseren Browser-Handling.

Über das Header-Field "Accept" wird gesteuert, in welches Ausgabeformat konvertiert werden soll. Fehlt das Header-Field oder ist der Wert "*/*", findet keine Konvertierung statt. Mehrwertige Accept werden nicht unterstützt und resultieren in einer Fehlermeldung.

Über den optionalen Query-Parameter "targetMimeType" kann der Wert des "Accept" Header-Fields überschrieben werden. Dies ist notwendig, wenn man den Request aus einem Browser aufrufen möchte und dort keinen Einfluss auf die Header-Fields hat.


  Über den folgenden Pfad kann ein Dokument in ein anderes Format umgewandelt werden (z.B. odt in pdf):


Der Service bildet den JOD-Konverter (siehe http://sourceforge.net/projects/jodconverter/) ab und dient der Abwärtskompatibilität für Installationen, die bisher mit dem JOD-Konverter betrieben wurden.

Damit der Service funktioniert muss Open/LibreOffice (ab Version 4.0) installiert sein und die Konfigurationsdatei "bridge.ini" muss einen Eintrag enthalten, der auf die Datei "soffice" verweist:

[file-format-conversion] sofficePath="C:\Program Files (x86)\LibreOffice 4.0\program\soffice.exe" Static File Resource

Liefert Dateien aus dem Dateisystem aus.

Bei dieser Art von Ressource legt man lediglich per Path pattern das Verzeichnis fest, unterhalb dessen Dateien ausgeliefert werden. Die Adressierung des Verzeichnisses erfolgt relativ zum Installationsverzeichnis der REST-Bridge.


Gegeben sei ein Verzeichnis icons mit der Datei bullet.png. Das Path-Pattern der Ressource lautet icons, der dazugehörige Service hat die Service ID test. Der Zugriff auf die Datei bullet.png lautet dann:

http://localhost:8815/test/icons/bullet.png 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.
1.9.4 CORS

Bei OPTIONS-Requests antwortet die REST-Schnittstelle standardmäßig mit

Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, X-Requested-With,Content-Type, Accept 

In der Konfigurationsdatei (bridge.ini) können diese Header konfiguriert werden:

accessControlAllowHeaders=Origin, X-Requested-With,Content-Type, Accept


1.10 Reports and Printing

Mit Hilfe der Druckkomponente kann man Dokumentvorlagen (ODT/DOCX/XLSX/RTF-Dateien) mit KPath-Ausdrücken auf Objekten oder Objektlisten anwenden und daraus eine angepasste Ausgabe-Datei generieren, die entweder gedruckt oder gespeichert werden kann.

Das Hinzufügen der Druckkomponente über das Admin-Tool legt im Wissensnetz Konfigurationsschema für Objekte ("Druckvorlage") und Listen ("Druckvorlage für Listen") an. Die Existenz dieser Komponente ist Voraussetzung dafür, dass die Druckfunktionalität im Knowledge-Builder bzw. über die REST-Schnittstelle zur Verfügung steht.

1.10.1 Configuring of print templates

Druckvorlagen werden im Knowledge-Builder im Bereich "TECHNIK/Druckkomponente" angelegt. Jedes Druckvorlagen-Objekt enthält ein Druckvorlagen-Dokument (ODT,DOCX,RTF) und eine Relation, die angibt auf welche Objekte die Druckvorlage angewendet werden soll.

Das folgende Beispiel zeigt eine ODT-Druckvorlage für Objekte des Typs "Task".

Die folgenden Kapitel erläutern das Erstellen der Druckvorlagen-Dokumente. Creation of RTF templates

Die RTF-Vorlagedateien können auswertbare KPath-Ausdrücke mit den Schlüssel­worten KPATH_EXPAND und KPATH_ROWS sowie Aufrufe registrierter KSkripte mit den Schlüsselworten KSCRIPT_EXPAND und KSCRIPT_ROWS enthalten. Die Pfadausdrücke bzw. der Name des aufzurufenden Skriptes stehen immer zwischen spitzen Klammern und nach dem Schlüsselwort durch ein Leerzeichen getrennt.


Der KPath-Ausdruck nach diesem Schlüsselwort sollte ein einzelnes semantisches Objekt oder einen einfachen Wert (Datum, Zeichenkette etc.) zurückliefern. Bei der Auswertung wird der ursprüngliche Ausdruck durch das Ergebnis ersetzt. Die Formatierung des Ausdrucks bleibt erhalten, Umbrüche des Wertes werden in Zeilenumbrüche umgesetzt.

Die Vorlage sei:

<KPATH_EXPAND @$adresse$/rawValue()>

Nach Auswertung steht in der Ausgabedatei:

intelligent views gmbh
Julius-Reiber-Str. 17
64293 Darmstadt


Alternativ zum Pfadausdruck kann mit KSCRIPT_EXPAND ein registriertes KSkript aufgerufen werden. Die Ausgabe dieses Skriptes (Skriptelemente mit <Output>) wird in das Dokument übernommen. Die Registrierung von Skripten erfolgt im Knowledge-Builder im Ordner TECHNIK/Registrierte Objekte/Skri.

Die Vorlage sei:

<KSCRIPT_EXPAND einSkriptDas1bis9Ausgibt>

Nach Auswertung steht in der Ausgabedatei:



Dieser Ausdruck muss in einer Tabelle stehen. Der KPath-Ausdruck nach diesem Schlüsselwort muss eine Liste semantischer Objekte liefern. Bei der Auswertung wird die Tabellenzeile des KPATH_ROWS Ausdrucks für jedes Ergebnis des KPath-Ausdrucks einmal ausgewertet. Somit können Tabellen dynamisch ergänzt werden. Es spielt übrigens keine Rolle, in welcher Spalte der KPATH_ROWS Ausdruck steht.

Die Vorlage sei:

Teile (<KPATH_EXPAND topic()/~$hatTeile$/size()> Stück) Bemerkung
<KPATH_EXPAND topic()><KPATH_ROWS topic()/~$hatTeil$/target()/sort(@$name$, true)> <KPATH_EXPAND topic()/@$bemerkung$>

Nach Auswertung in der Ausgabedatei:

Teile (3 Stück) Bemerkung
ODT-Druck Ersetzt den RTF-Druck
Konvertierungsservice Optionaler Dienst


Bei KSCRIPT_ROWS werden die Objekte für die Tabellenzeilen durch ein registriertes KSkript ermittelt. Der Name des registrierten Skriptes wird direkt hinter KSCRIPT_ROWS angegeben. Das Skript muss vom Typ KSkript sein und die auszugebenden Objekte zurückgeben.

Die Vorlage sei:

Spalte1 Spalte2
<KSCRIPT_ROWS allePersonen><KPATH_EXPAND @$nachname$> <KPATH_EXPAND @$Vorname$>

Nach Auswertung in der Ausgabedatei:

Spalte1 Spalte2
Meier Peter
Schulze Helmut Creating ODT (OpenOffice) documents

Der Druck über das ODT-Format (Open Document Text, offener Standard) hat viele Vorteile gegenüber dem RTF-Format:

  • Die eingebetteten Skript-Anweisungen sind nicht Teil des Textes sondern werden in speziellen Script-Elementen abgelegt. Somit macht man sich seine Formatierung nicht durch längliche Skripte kaputt.
  • Das ODT-Format unterstützt eine große Menge an Formatanweisungen (vergleichbar mit MS-Word), die RTF nicht kennt.
  • RTF hat als Format keine einheitliche Normierung (MS-Word kann z.B. "mehr" RTF als der Standard).
  • Die Bearbeitung der RTF-Vorlagen ist sehr fragil. Vor allem MS-Word neigt dazu, die Vorlagen mit Steuerelementen (wie z.B. die aktuelle Cursorposition bei der letzen Bearbeitung) zu ‚ergänzen’, sodass die Skripte nicht mehr verlässlich erkannt werden können.

ODT-Vorlagen können mit OpenOffice oder LibreOffice erstellt werden. Die Erstellung erfolgt analog zu der Erstellung von RTF-Vorlagen mit dem Unterschied, dass die Path-/Script-Anweisungen in Script-Elementen abgelegt werden, wie in der folgenden Abbildung gezeigt.


In LibreOffice 5 lässt sich das Skriptfeld nicht länger einbinden. Als Alternative hierzu kann das Feld "Eingabefeld" benutzt werden:

    Einfügen > Feldbefehl > Weitere Feldbefehle (alternativ Tastenkombination Strg+F2)

Dort findet sich im Reiter "Funktionen" das Eingabefeld. 

"Hinweis" entspricht dem vorherigen "Script-Typ"; nach einem Klick auf Einfügen öffnet sich ein weiteres Fenster, in das das Skript eingetragen werden kann.


Verfügbare Skript-Typen

Als Skript-Typen gibt es:

  • KPath : analog zu KPATH_EXPAND
  • KScript : analog zu KSCRIPT_EXPAND
  • KPathRows : analog  zu KPATH_ROWS
  • KPathImage : zur Einbettung von Bildern
  • ScriptFunction: Aufruf einer Funktion eines registrierten Scripts. Als Text wird eine Zeichenkette mit folgendem Format erwartet:
    Der Funktionsaufruf wird automatisch um zwei Argumente erweitert: das semantisch Elemente und die durch die Umgebung vorgegebenen Variablen

    Ein Beispiel für ein aufgerufenes Skript:
    function headerLabel(element, variables) 
       return element.name().toLocaleUpperCase();
  • ScriptRowsFunction: Analog zu ScriptFunction. Für die zurückgegebenen Objekte werden analog zu KPathRows Tabellenzeilen erzeugt.
  • ScriptImageFunction: zum Einfügen von Bitmap-Images
  • ScriptSVGImageFunction: zum Einfügen von SVG-Zeichnungen
  • DataPath: An der Druckvorlage muss das "Skript zur Erzeugung von JSON-Inhalten" gesetzt sein. Auf die Werte des JSON-Objekts kann nun über den entsprechenden Schlüssel zugegriffen werden.

    Beispiel zum Erzeugen des JSON-Objekts:

    function templateData(element)
        return { 
                name: element.name(), 
                idNumber: element.idNumber(),
                someData: { idString: element.idString() }

    Um zum Beispiel auf den Wert idString zuzugreifen, muss als Text

    gesetzt sein.
  • DataRowsPath: Analog zu DataPath. Als Text wird ein Schlüssel erwartet, dessen Wert im JSON ein Array von Objekten ist. Nachfolgende DataPath-Felder beziehen sich auf die Objekte in diesem Array.

Zur Einbettung von Bildern können Datei-Attribute oder URLs verwendet werden. Bei der Verwendung von URLs wird versucht, ein Bild von der angegebenen Adresse zu laden.

Eingebettete Bilder werden immer auf ihre Originalgröße (bei 96d dpi) gezogen. Möchte man im Ausdruck eine andere Größe erhalten, muss man einen Rahmen mit den gewünschten Ausmaßen (unbedingt absolute Maße in cm verwenden!) um das Skript-Element bauen. Das resultierende eingebettete Bild wird dann so in den Rahmen eingepasst, dass das Rahmenmaß unter Beibehaltung der Bild-Seitenverhältnisse nicht überschritten wird. Creating DOCX documents (Microsoft Word)

DOCX-Vorlagen können mit Microsoft Word 2007 oder neuer erstellt werden.

Die Erstellung erfolgt analog zu der Erstellung von RTF-Vorlagen mit dem Unterschied, dass die Path-/Skript-Anweisungen in Text-Inhaltssteuerelementen abgelegt werden.

Zum Einfügen der Steuerelement müssen in Word zuerst die Entwicklertools aktiviert werden. Dazu im Office-Menü die Word-Optionen öffnen und in der Kategorie Häufig verwendet die Option Entwicklerregisterkarte in der Multifunktionsleiste anzeigen aktivieren. Nun aktiviert man auf der Registerkarte Entwicklertools den Entwurfsmodus.

Um KSkript/KPath-Ausdrücke einzufügen, fügt man ein Nur-Text-Inhaltssteuerelement ein. Der Text des Steuerelements wird durch den berechneten Text ersetzt. Bei den Eigenschaften des Steuerelements (erreichbar über das Kontextmenü auf der schließenden Klammer) gibt man bei Titel das KSkript bzw. den KPath an. Falls man den Titel leer lässt, wird stattdessen der Text des Steuerelements verwendet. Als Tag gibt man den Skript-Typ an. Als Skript-Typen gibt es alle Typen, die bei ODT zur Verfügung stehen, mit Ausnahme von KPathImage.


1.10.2 Konfiguring list templates

Druckvorlagen für Listen werden im Knowledge-Builder im Bereich "TECHNIK/Druckkomponente" angelegt. Jedes "Druckvorlagen für Listen"-Objekt enthält ein Druckvorlagen-Dokument (XSLX) und eine Relation, die angibt auf welche Objekte die Druckvorlage angewendet werden soll. Optional kann eine Objektliste angegeben werden, die zur Generierung der Ausgabe verwendet werden soll. Auf diese Weise kann man bewirken, dass sich das Format der Liste, die der Anwender am Bildschirm sieht und das der ausgegebenen Liste unterscheiden.

Wenn man das Attribut "Dokument (Druckvorlage)" nicht angelegt hat, so wird bei der Dokumentgenerierung eine Excel-Datei erzeugt, die ein Arbeitsblatt mit den Daten der Objektliste und den Spaltenüberschriften aus der Objektlistenkonfiguration enthält, d.h. man muss nicht zwangsläufig eine Excel-Datei als Druckvorlage angeben.

Das folgende Beispiel zeigt eine Druckvorlage für Listen mit Objekten des Typs "Task".


XLSX-Vorlagen können mit Microsoft Excel 2007 oder neuer erstellt werden. Diese Vorlagen funktionieren nur mit Objektlisten.

Erstellen der Excel-Datei

Als Vorlage dient eine gewöhnliche Excel-Datei, die ein zusätzliches Arbeitsblatt namens "data" enthalten muss. Die Objektlistendaten werden später dann in dieses Arbeitsblatt gefüllt und zwar ohne Überschriften und beginnend mit der Zelle A1.


Die anderen Arbeitsblätter können Daten aus dem Blatt "data" in Formeln referenzieren. i-views sorgt dafür, dass alle Formeln neu berechnet werden, sobald die ausgefüllte Excel-Datei das nächste Mal mit Excel geöffnet wird.

1.10.3 File Format Conversion using Open/LibreOffice

Das Ausgabeformat des Druckvorgangs entspricht dem des verwendeten Templates. Möchte man ein anderes Ausgabeformat erhalten, muss man einen Konverter einrichten.

Dazu benötigt man eine Installation von Libre- oder OpenOffice ab Version 4.0 auf dem Rechner, der die Konvertierung durchführen soll - gewöhnlich dort, wo die Bridge oder der Jobclient läuft, der auch den Druckvorgang durchführt.

Zusätzlich muss in der Konfigurationsdatei (bridge.ini, jobclient.ini, etc.) der Pfad zum "soffice"-Programm angegeben werden, welches Teil der Libre/OpenOffice-Installation ist und sich dort im Unterverzeichnis "program" befindet. Diese Angabe muss als absoluter Pfad erfolgen, relative Pfade (..\LibreOffice\etc.) sind hier nicht möglich.

sofficePath="C:\Program Files (x86)\LibreOffice 4.0\program\soffice.exe"


Möchte oder kann man nicht an allen Arbeitsplätzen bzw. Serverinstallationen, von denen aus die Formatkonvertierung durchgeführt werden soll, eine Libre/Office-Installation vorhalten, kann eine entsprechend konfigurierte REST-Bridge die Konvertierung durchführen.

Das .ini-File der REST-Bridge muss dazu folgendes Format aufweisen:



sofficePath="C:\Program Files (x86)\LibreOffice 4.0\program\soffice.exe"

Im Admin-Tool trägt man unter Systemkonfiguration/Komponenten/Konvertierungsservice ein, über welche Adresse der Konvertierungsservice erreichbar ist.




Damit die Ausgabeformate verfügbar sind, müssen entsprechend konfigurierte Objekte vom Typ "Konverter-Dokumentformat" im Netz vorhanden sein.

Wichtig ist, dass nicht alle Formate ineinander Konvertiert werden können. Die wichtigsten sind:

Name Extension Mime-Type
Portable Document Format pdf application/pdf
OpenDocument Text odt application/vnd.oasis.opendocument.text
Microsoft Word doc application/msword


2 Admin-Tool

Mit dem Admin-Tool können neue Wissensnetze angelegt, alle Wissensnetze eines Mediators verwaltet und einzelne Wissensnetze konfiguriert werden.

2.1 Startfenster

Nach dem Start des Admin-Tools (Windows: admin.exe, Mac OS: admin, Linux: admin-64.im) erscheint das Startfenster.


2.1.1 Server

Im Freitextfeld Server wird die URL des Servers eingegeben. (Falls kein Protokoll angegeben wird, wird das Protokoll cnp:// verwendet). Gültige URLs verwenden eines der Protokolle [cnp://,cnps://,http:// oder https://] gefolgt von [Rechnername oder IP-Adresse]:[Portnummer]. Dieses Format entspricht der interface einstellung am Mediator.

Läuft der Mediator, über den Wissensnetze administriert werden sollen, auf dem gleichen Rechner wie das Admin-Tool, kann er auch über den Rechnernamen localhost angesprochen werden.

Bleibt das Feld leer, wird auf die Wissensnetze zugegriffen, die relativ zur Position des Admin-Tools im direkten Unterordner volumes liegen. Für diese Art des Zugriffes ist kein Mediator notwendig.

Einmal eingegebene Einträge im Freitextfeld werden gespeichert. Über die Schaltfläche ... können sie in einem separaten Fenster aus einer Liste ausgewählt werden.

Mit der Schaltfläche Verwalten gelangt man zur Serververwaltung, bei der eine Authentifizierung mit dem Serverpassword benötigt wird.

2.1.2 Wissensnetz

Im Freitextfeld Wissensnetz wird das Wissensnetz angegeben, das administriert werden soll.

Einmal eingegebene Einträge im Freitextfeld werden gespeichert. Über die Schaltfläche ... können sie in einem separaten Fenster aus einer Liste ausgewählt werden. Zur Anzeige aller Wissensnetze wird man gegebenenfalls aufgefordert, das Serverpasswort einzugeben.

2.1.3 Info

Über die Schaltfläche Info lassen sich in einem eigenen Fenster versionsspezifische Informationen über das Admin-Tool abrufen.

Konkret handelt es sich dabei um

  • die Versionsnummer des Admin-Tools (Build),
  • den Veröffentlichungsstatus des Admin-Tools (Release State),
  • die vom Admin-Tool maximal nutzbare Menge an Systemarbeitsspeicher in Byte (Speicherbegrenzung),
  • die Versionsnummer und der digitale Fingerabdruck der vom Admin-Tool verwendeten Ausführungsumgebung (VM Version),
  • die im Betriebssystem aktive Spracheinstellung (Locale),
  • die im Admin-Tool verwendeten, mitgelieferten Schriftarten (Fonts),
  • die mit dem Admin-Tool ausgelieferten Wissensnetzkomponenten inklusive Versionsnummer (Softwarekomponenten) und
  • die im Admin-Tool verwendeten Smalltalk-Pakete inklusive Versionsnummer (Pakete).

Die Angaben zur Netzversion und zur Volume-Information sind hierbei nicht einschlägig.

Die Informationen werden in einem unsichtbaren Textfeld ausgegeben, welches über ein Kontextmenü verfügt, das per Rechtsklick aktiviert werden kann:

  • Select All markiert den gesamten Text. Alternativ kann mit dem Mauszeiger ein beliebiger Textausschnitt markiert werden.
  • Copy kopiert den gewählten Textbereich in die Zwischenablage des Betriebssystems.
  • Find Again sucht nach dem gewählten Textbereich und findet sein nächstes Auftreten gemäß der Leserichtung.
  • Find erlaubt die Eingabe einer zu suchenden Zeichenkette in einem separaten Fenster und findet ihr nächstes Auftreten gemäß der Leserichtung relativ zur Position der per Mausklick setzbaren Schreibmarke. Bei der Suche wird Groß- und Kleinschreibung unterschieden.

Über die Schaltfläche Kopieren werden alle Informationen in die Zwischenablage des Betriebssystems kopiert.

Die Schaltfläche RSA-Key kopieren kopiert den für jedes kompilierte Admin-Tool einzigartigen Schlüssel in die Zwischenablage des Betriebssystems. Dieser Schlüssel kann in die Initialisierungsdatei eines Mediators (Standarddateiname mediator.ini) eingetragen werden und beschränkt dadurch den Zugang zu diesem Mediator über ein Admin-Tool auf Admin-Tools mit genau diesem Schlüssel.

Die Schaltfläche Ok ermöglicht eine Rückkehr zum Startfenster.

2.1.4 Verwalten, Neu und Weiter

Neu leitet weiter zur Wissensnetzerzeugung.

Verwalten leitet weiter zur Serververwaltung.

Weiter leitet weiter zur Einzelnetzverwaltung. Hierfür werden die Einträge Benutzername und Passwort zur Anmeldung mit einem Administratorkonto verwendet.

2.1.5 Ende

Die Schaltfläche Ende schließt das Admin-Tool.

2.2 Wissensnetzerzeugung

Das Anlegen eines neuen Wissensnetzes erfolgt über ein eigenes Netzerzeugungsfenster. Es kann über die Schaltfläche Neu im Startfenster erreicht werden. Etwaige Eingaben in den Freitextfeldern Server und Wissensnetz werden ignoriert.

2.2.1 Server

Im Freitextfeld Server wird der Name oder die IP-Adresse des Rechners angegeben, auf dem der Mediator läuft, über den das neue Wissensnetz angelegt werden soll. Sollte dieser nicht über den Standard-Port erreichbar sein, muss außerdem die korrekte Port-Nummer genannt werden. Die Eingabeform hierzu lautet [Rechnername oder IP-Adresse]:[Portnummer].

Läuft der Mediator, über den das neue Wissensnetz angelegt werden soll, auf dem gleichen Rechner wie das Admin-Tool, kann er auch über den Rechnernamen localhost angesprochen werden.

Bleibt das Feld leer, wird das Wissensnetz im relativ zur Position des Admin-Tools direkten Unterordner volumes erzeugt.

2.2.2 Neues Wissensnetz

Im Freitextfeld Neues Wissensnetz wird der Name des Wissensnetzes festgelegt. Die dafür erlaubten Zeichen werden über das Dateisystem des Betriebssystems vorgegeben, auf dem das Wissensnetz gespeichert werden soll. Damit die Daten auch auf unterschiedlichen Dateisystemen gespeichert werden können, gilt:

  • maximal 64 Zeichen
  • keine Leerzeichen am Anfang oder Ende
  • erlaubte Zeichen: große und kleine lateinische Buchstaben, Ziffern, Leerzeichen, !@#$%&'()+-.[]^_`{}~Œœ sowie ASCII-Zeichen 160-255
  • nicht erlaubte Zeichenfolgen sind: AUX, CON, NUL, PRN sowie COM0-COM9 und LPT0-LPT9

Die Vergabe eines Namens ist zwingend.

Der Name lässt sich später nur bei Kopiervorgängen des Wissensnetzes oder über Umbenennungen der Datei- und Verzeichnisnamen ändern. Bei einer Änderung ist zu beachten, dass der Name des Wissensnetzes eventuell in Initialisierungsdateien verwendet wird und möglicherweise die Lizenz darauf angepasst wurde.

2.2.3 Passwort (Mediator)

Der Mediator unterstützt eine Authentifizierung über ein Passwort. Ist für den Mediator, über den das neue Wissensnetz angelegt werden soll, ein Passwort gesetzt, muss es im Freitextfeld Passwort, welches sich zwischen den Feldern Neues Wissensnetz und Lizenz befindet, eingegeben werden. Ist kein Passwort vergeben, muss das Freitextfeld leer bleiben.

2.2.4 Lizenz

Ein Wissensnetz muss eine gültige Lizenz besitzen, damit der Knowledge-Builder und andere Software-Komponenten (mit Ausnahme des Admin-Tools) damit arbeiten können. Über die Schaltfläche ... kann auf das Dateisystem des Betriebssystems zugegriffen werden, um einen Lizenzschlüssel (Dateiname: [Lizenzname].key) zu laden.

2.2.5 Benutzername

Im Freitextfeld Benutzername wird der Name des ersten im Wissensnetz registrierten Nutzers festgelegt. Die Art und Menge der dafür erlaubten Zeichen ist nicht beschränkt. Die Voreinstellung Administrator ist lediglich ein Vorschlag. Dieses Feld darf nicht leer bleiben.

Der Name kann im Admin-Tool oder im Knowledge-Builder nachträglich geändert werden. Der hierüber angelegte Nutzer besitzt automatisch Administratorrechte.

2.2.6 Passwort (Benutzer)

Im Freitextfeld Passwort kann ein Passwort für den ersten im Wissensnetz registrierten Nutzer vergeben werden. Dieses Passwort wird später gebraucht, wenn dieser Nutzer sich im Knowledge-Builder oder im Admin-Tool für das Wissensnetz anmelden will.

2.2.7 OK und Abbrechen

Die Schaltfläche Ok erzeugt das Wissensnetz unter Einbeziehung der eingegebenen Daten. Die Schaltfläche Abbrechen bricht den Vorgang ab. In beiden Fällen erfolgt eine Rückkehr zum Startfenster.

2.3 Server administration

Die Gesamtnetzverwaltung erlaubt die Administration aller Wissensnetze eines Mediators beziehungsweise des lokalen Unterordners volumes. Sie kann über die Schaltfläche Verwalten im Startfenster erreicht werden. Erforderlich ist hierzu eine entsprechende Eingabe im Feld Server des Startfensters. Etwaige Eingaben im Feld Wissensnetz des Startfensters werden ignoriert. Werden die zu administrierenden Wissensnetze über einen Mediator angesprochen, muss außerdem das korrekte Mediator-Passwort in einem eigenen Fenster angegeben werden.

Das Gesamtnetzverwaltungsfenster besteht aus einer tabellarischen Netzübersicht, einem Nachrichtenfeld und einer Menüzeile.

2.3.1 NetzĂĽbersicht

Die tabellarische Netzübersicht gibt Aufschluss über

  • den Namen (Volume),
  • die Anzahl an gegenwärtig aktiven Nutzern (Clients),
  • das Datum und die Uhrzeit der letzten Sicherung (letztes Backup) sowie
  • die letzte Statusmeldung (Status) des jeweiligen Netzes.

Die einzelnen Spalten sind über einen Klick auf den Spaltenkopf sortierbar.

Die Daten werden nur beim Auslösen von Operationen aktualisiert und sind deswegen nicht immer aktuell. Eine manuelle Aktualisierung kann jederzeit über den Menüpunkt Server --> Aktualisieren forciert werden.

2.3.2 Nachrichtenfeld

Das Nachrichtenfeld gibt alle Statusmeldungen aller Netze aus. Statusmeldungen werden durch das Auslösen von Aktivitäten im Admin-Tool erzeugt. Sie gehen beim Schließen des Admin-Tools verloren. Um dies zu verhindern, können sie über den Menüpunkt Datei --> Administrations-Log exportiert werden. Das Nachrichtenfeld ist zwar editierbar, Änderungen werden beim Export aber ignoriert.

2.3.3 MenĂĽzeile

Die Menüzeile besteht aus den folgenden Menüreitern: Datei

Administrations-Log speichern speichert alle Einträge im Nachrichtenfenster in einer Textdatei (Dateistandardname: admin.log) ab. Name und Speicherort können in einem Speicherdialog frei gewählt werden. Diese Operation setzt voraus, dass das Admin-Tool mit einem Mediator verbunden ist.

Abmelden schließt die Serververwaltung und öffnet wieder das Anmeldefenster-

Beenden schließt die Serververwaltung Server

Aktualisieren ermittelt die in der Netzübersicht im Gesamtnetzverwaltungsfenster erhobenen Daten neu.

Ini-Datei neu einlesen veranlasst den Server, seine ini-Datei neu einzulesen. Dabei können nicht alle Optionen im laufenden Betrieb aktualisiert werden. Der Server leifert eine Mitteilung über aktualisierte Optionen.

Log herunterladen erzeugt eine Kopie der üblicherweise im Ordner des verbundenen Mediators liegenden Mediator-Protokolldatei (Standarddateiname: mediator.log). Name und Speicherort der Kopie können in einem Speicherdialog frei gewählt werden. In der Mediator-Protokolldatei wird ein Protokoll über alle Aktivitäten des Mediators seit seiner ersten Inbetriebnahme geführt.

Serververbindungen gibt im Nachrichtenfeld die Nummer und die IP-Adresse aller gegenwärtig über den verbundenen Mediator in Wissensnetzen angemeldeten Software-Komponenten (außer dem Blob-Service) aus und gruppiert diese nach Wissensnetzen. Die Nummer wird vom Mediator fortlaufend generiert und bei jeder Neuanmeldung einer Software-Komponente neu vergeben. Administrate

Volume herunterladen erzeugt eine Kopie des in der Netzübersicht ausgewählten Wissensnetzes und speichert sie lokal im relativ zur Position des Admin-Tools liegenden Unterordner volumes. In einem separat erscheinenden Freitextfeld kann ein neuer Name für diese Kopie vergeben werden.

Volume kopieren erzeugt eine Kopie des in der Netzübersicht ausgewählten Wissensnetzes und speichert sie im gleichen Ordner wie das Originalnetz. In einem separat erscheinenden Freitextfeld muss ein neuer Name für diese Kopie vergeben werden.

Volume hochladen erzeugt eine Kopie eines ausgewählten lokalen Wissensnetzes und speichert sie im relativ zum verbundenen Mediator liegenden Unterordner volumes. In einem separat erscheinenden Freitextfeld kann ein neuer Name für diese Kopie vergeben werden. Die Auswahl des lokalen Wissensnetzes, das im relativ zur Position des Admin-Tools liegenden Unterordner volumes abgelegt sein muss, erfolgt über ein separates Auswahlfenster.

Volume austauschen erzeugt eine Kopie eines ausgewählten lokalen Wissensnetzes und überschreibt damit das in der Netzübersicht ausgewählte Wissensnetz. Die Kopie erhält dabei den Namen des überschriebenen Wissensnetzes. Die Auswahl des lokalen Wissensnetzes, das im relativ zur Position des Admin-Tools liegenden Unterordner volumes abgelegt sein muss, erfolgt über ein separates Auswahlfenster.

In Folge der über Transfer-Operationen ausgelösten Kopierprozesse wird die Blockbelegung der Cluster und Blobs innerhalb der Wissensnetzkopien neu festgelegt und dabei deren Platzverbrauch optimiert. Der hierdurch bewirkte Komprimierungseffekt ist der gleiche wie über die Operation Verwalten -> Volume komprimieren.

Mit Ausnahme der Operation Volume kopieren setzen alle diese Operationen voraus, dass das Admin-Tool mit einem Mediator verbunden ist. Verwalten

Admintool öffnen meldet sich im ausgewählten Volume mit dem Admintool an. Hiefür ist keine Authentifizierung im Volume nötig - die Mediator-Authentifizierung genügt.

Auf diese Art kann bei einem vergessenen Administrator-Passwort auf die Benutzerverwaltung des Volumes zugegriffen werden.

Backup erstellen erzeugt eine Sicherungskopie des in der Netzübersicht ausgewählten Wissensnetzes und speichert sie im relativ zur Position dieses Wissensnetzes liegenden Parallelordner backup. Für jede Sicherungskopie wird dort ein eigener Unterordner angelegt, in dessen Bezeichnung der Zeitpunkt der Kopieerstellung auf eine Sekunde genau eingearbeitet ist. Jede Sicherungskopie ist eine vollständige Kopie des Originalnetzes.

Vor Erzeugung der Sicherungskopie wird über ein eigenes Fenster erfragt, ob der Nutzer bis zum Abschluss des Kopiervorganges warten will. Gegebenenfalls wird bis zu diesem Zeitpunkt die weitere Nutzung des Admin-Tools blockiert. Andernfalls startet der Kopiervorgang im Hintergrund und eine Nachricht über den Fortgang des Kopiervorganges oder dessen Fertigstellung unterbleibt.

Backup wiederherstellen erzeugt eine Kopie einer ausgewählten Sicherungskopie und speichert sie im gleichen Ordner wie die in der Netzübersicht dargestellten Wissensnetze. In einem separat erscheinenden Freitextfeld muss ein neuer Name für diese Kopie vergeben werden. Die Auswahl der Sicherungskopie, die in einem Unterordner des Ordners backup abgelegt sein muss, der parallel zur Position der in der Netzübersicht dargestellten Wissensnetze liegt, erfolgt über zwei separate Auswahlfenster, in denen zuerst das Wissensnetz und danach die nach Erstellungszeiten sortierte Version ausgewählt werden.

Backup löschen löscht eine ausgewählte Sicherungskopie. Die Auswahl dieser Sicherungskopie, die in einem Unterordner des Ordners backup abgelegt sein muss, der parallel zur Position der in der Netzübersicht dargestellten Wissensnetze liegt, erfolgt über zwei separate Auswahlfenster, in denen zuerst das Wissensnetz und danach die nach Erstellungszeiten sortierte Version ausgewählt werden.

Die Blockbelegung der Cluster und Blobs innerhalb des Originalwissensnetzes wird bei der Erstellung einer Wissensnetzkopie nicht verändert. Der durch Backup-Operationen ausgelöste Kopiervorgang erzeugt deswegen keinen Komprimierungseffekt.

Volume löschen löscht das in der Netzübersicht ausgewählte Wissensnetz.

Volume komprimieren verringert den Platzbedarf des in der Netzübersicht ausgewählten Wissensnetzes. Dies geschieht über die Beseitigung ungenutzter Binnenblöcke. Durch Umkopierprozesse der Cluster und Blobs werden zunächst alle ungenutzten Blöcke an das Dateiende verschoben und dann im Dateisystem des Betriebssystems freigegeben.

Volume-Storage aktualisieren aktualisiert die Version des Blockdateisystems des in der Netzübersicht ausgewählten Wissensnetzes. Wird das Wissensnetz über einen Mediator angesprochen, wird die darin enthaltene Version verwendet, ansonsten wird die im Admin-Tool mitgelieferte Version verwendet. Die Aktualisierung ermöglicht eine schnellere Speicherung von Indexstrukturen. Sie ist möglich für Wissensnetze, deren i-views-Core-Komponente älter als 4.2 ist. Garbage Collection

Die Garbage-Collection ist ein Verfahren, das nicht mehr referenzierte Objekte (nach programmierterminologischer Lesart) in einem Wissensnetz löscht und damit den Speicherverbrauch des Wissensnetzes minimiert. Die Nutzung der Garbage-Collection setzt voraus, dass das zu bereinigende Wissensnetz über einen Mediator angesteuert wird.

Start startet eine neue Speicherbereinigung für das in der Netzübersicht ausgewählte Wissensnetz oder setzt eine pausierte Speicherbereinigung fort. Es erfolgt keine Rückmeldung, wann der Vorgang abgeschlossen ist. Der Stand des Fortschritts kann über den Menüpunkt Status in Erfahrung gebracht werden.

Pause unterbricht die Durchführung der aktiven Speicherbereinigung für das in der Netzübersicht ausgewählte Wissensnetz.

Anhalten bricht die Durchführung der aktiven Speicherbereinigung für das in der Netzübersicht ausgewählte Wissensnetz ab.

Status schreibt den aktuellen Zustand der Speicherbereinigung für das in der Netzübersicht ausgewählte Wissensnetz in die Statusspalte der Netzübersicht und in das Nachrichtenfeld. Ist eine Speicherbereinigung aktiv, erfolgt zusätzlich eine Rückmeldung über den Stand des Fortschritts in Form einer Prozentangabe.

2.4 Einzelnetzverwaltung

Die Einzelnetzverwaltung erlaubt die Administration eines einzelnen Wissensnetzes. Sie kann über die Schaltfläche Start im Startfenster erreicht werden. Erforderlich sind hierzu entsprechende Eingaben in den Feldern Server, Wissensnetz, Benutzer und Passwort des Startfensters.

2.4.1 Nutzerauthentifizierung

Für den Zutritt zum Einzelnetzverwaltungsfenster ist die Anmeldung eines Nutzers mit Administratorrechten notwendig.

Falls man keinen Zugang mehr zum Wissensnetz mehr hat, kann man mit Hilfe der Anmeldung in der Serververwaltung über die Authentifizierung am Server Zugang zum Wissensnetz bekommen.


2.4.2 Einzelnetzverwaltungsfenster

Das Einzelnetzverwaltungsfenster verfügt über eine mehrstufig gegliederte Menüliste links und ein Operationsfenster rechts. Der Inhalt des Operationsfensters richtet sich nach dem gewählten Menüpunkt in der Menüliste.

Die Schaltfläche Zurück wechselt zum Startfenster zurück.

Die Schaltfläche Beenden schließt das Admin-Tool.

Wird das zu administrierende Wissensnetz ohne Mediator angesprochen, ist ein Zutritt anderer Nutzer zum Wissensnetz über den Knowledge-Builder oder eine weitere Instanz des Admin-Tools nicht möglich, solange das Einzelnetzverwaltungsfenster geöffnet ist. Administrate data

Backup erstellen erzeugt eine Sicherungskopie des Wissensnetzes und speichert sie (auf dem Server) im relativ zur Position dieses Wissensnetzes liegenden Parallelordner backup. Für jede Sicherungskopie wird dort ein eigener Unterordner angelegt, in dessen Bezeichnung der Zeitpunkt der Kopierstellung auf eine Sekunde genau eingearbeitet ist. Jede Sicherungskopie ist eine vollständige Kopie des Originalnetzes.

Vor Erzeugung der Sicherungskopie wird über ein eigenes Fenster erfragt, ob der Nutzer bis zum Abschluss des Kopiervorganges warten will. Gegebenenfalls wird bis zu diesem Zeitpunkt die weitere Nutzung des Admin-Tools blockiert. Andernfalls startet der Kopiervorgang im Hintergrund und eine Nachricht über den Fortgang des Kopiervorganges oder dessen Fertigstellung unterbleibt.

Backup wiederherstellen ersetzt das aktuelle Wissensnetz durch eine Sicherungskopie (danach wird man automatisch abgemeldet). Die Auswahl der Sicherungskopie erfolgt über die Zeitpunkte der jeweiligen Backups.

Backup löschen löscht eine einzelne Sicherungskopie dieses Wissensnetzes.

Die Blockbelegung der Cluster und Blobs innerhalb des Originalwissensnetzes wird bei der Erstellung einer Wissensnetzkopie nicht verändert. Der durch Backup-Operationen ausgelöste Kopiervorgang erzeugt deswegen keinen Komprimierungseffekt.

Download erzeugt eine Kopie des Wissensnetzes und speichert sie lokal im relativ zur Position des Admin-Tools liegenden Unterordner volumes. In einem separat erscheinenden Freitextfeld kann ein neuer Name für diese Kopie vergeben werden.

Volume hochladen überträgt ein lokal gespeichertes Netz und ersetzt das aktuelle Wissensnetz durch dieses (danach wird man automatisch abgemeldet) Information Job-Client

Um den Knowledge-Builder von bestimmten rechenintensiven Prozessen wie der Indizierung und der Abfrage von Wissensnetzen sowie der Ausführung von Skripten zu entlasten, können diese Prozesse teils wahlweise, teils exklusiv als Aufgaben (Jobs) von Job-Clients (einem Software-Dienst) übernommen werden. Dazu muss über die Benutzeroberfläche des Knowledge-Builders oder per Skript eine Aufgabe ausgelöst oder es müssen die Bedingungen für ihre Auslösung festgelegt werden. Außerdem ist mindestens ein Job-Client zu konfigurieren und zu starten, der Aufgaben dieses Aufgabentyps (Job Pool) übernehmen kann. Das Admin-Tool übernimmt hierbei überwiegend eine Beobachtungsfunktion. Unerledigte Aufgaben erscheinen im Knowledge-Builder unter dem Eintrag Aufträge in der Rubrik Technik. Die Verwaltung von Job-Clients über das Admin-Tool setzt voraus, dass das Admin-Tool mit einem Mediator verbunden ist.

Die tabellarische Job-Clients-Übersicht zeigt für jeden aktuell laufenden Job-Client

  • seinen Namen im Format [Job-Client-Name]@[Mediator-Name] (Name),
  • seine Job-Client-Nummer (ID),
  • seine IP-Adresse (IP),
  • den Namen des mit ihm verbundenen Mediators (Server),
  • seine vom Betriebssystem vergebene Prozessnummer (Prozess),
  • die ihm zugeordneten Aufgabentypen (Pool),
  • seinen Arbeitsstatus (Status) und
  • die Anzahl von ihm erledigter Aufgaben (Erledigt).

Die Job-Client-Nummer wird vom Mediator fortlaufend generiert und bei jeder Neuanmeldung neu vergeben. Der Job-Client-Name und die dem Job-Client zugeordneten Aufgabentypen werden in der Initialisierungsdatei des jeweiligen Job-Clients (Standarddateiname: jobclient.ini) unter dem Schlüssel name respektive dem Schlüssel jobPools festgelegt. In der Job-Client-Übersicht wird jeder Aufgabentyp eines Job-Clients in einer eigenen Zeile dargestellt, so dass ein Job-Client regelmäßig mehrere Zeilen belegt.

Die einzelnen Spalten der Job-Clients-Übersicht sind über einen Klick auf den Spaltenkopf sortierbar. Per Rechtsklick auf eine Zeile kann außerdem ein Kontextmenü geöffnet werden:

  • Informationen anzeigen stellt alle in der ausgewählten Zeile gelisteten Daten mit Ausnahme des Aufgabentyps und der erledigten Aufgabenanzahl in einem neuen Fenster dar. Ergänzt werden
    • Datum und Uhrzeit des letzten Startzeitpunkts des Job-Clients (startUpTime),
    • die ihm zur Verfügung stehende maximal nutzbare Menge an Systemarbeitsspeicher in Byte (max Memory),
    • der Name seiner Protokolldatei (logFileName) und
    • sein spezieller Name, unter dem er zum Beenden gezwungen werden kann (eine Verkettung der Zeichenkette „jobclient“ und der Job-Client-Nummer) (shutDownString).
  • Die Daten können dort in die Zwischenablage des Betriebssystems kopiert (Schaltfläche In Zwischenablage kopieren) oder über einen Speicherdialog als frei benennbare Textdatei an eine beliebige Stelle exportiert werden (Schaltfläche Speichern).
  • Die über den Menüpunkt Informationen anzeigen ausgelöste Operation kann alternativ über einen Doppelklick auf eine Zeile in der Job-Clients-Übersicht erwirkt werden.
  • Job-Client entfernen beendet den in der Job-Clients-Übersicht ausgewählten Job-Client.
  • Alle Job-Clients entfernen beendet alle in der Job-Clients-Übersicht gelisteten Job-Clients.

Die tabellarische Job-Pools-Übersicht listet alle Aufgabentypen, die in der Job-Clients-Übersicht mindestens einem Job-Client zugeordnet sind. Für jeden Aufgabentyp werden

  • seine Bezeichnung (Name),
  • seine in der Job-Clients-Initialisierungsdatei verwendete technische Bezeichnung (JobPool),
  • die Anzahl unerledigter Aufgaben dieses Aufgabentyps (ToDo),
  • die Anzahl fehlgeschlagener Aufgaben dieses Aufgabentyps (Fehlgeschlagen) und
  • die Anzahl der ihm zur Verfügung stehender Job-Clients (Job-Clients)


Die einzelnen Spalten der Job-Pools-Übersicht sind über einen Klick auf den Spaltenkopf sortierbar. Per Rechtsklick auf eine Job-Client-Zeile kann außerdem ein Kontextmenü geöffnet werden:

  • Job-Pool leeren löscht alle unerledigten und fehlgeschlagenen Aufgaben des in der Job-Pools-Übersicht ausgewählten Aufgabentyps. Diese Operation ist nur möglich, wenn kein Job-Client läuft.
  • Zu ignorierende Fehlermeldungen konfigurieren ermöglicht die Unterdrückung bestimmter Fehlermeldungen bei der Ausführung von Aufgaben des in der Job-Pools-Übersicht ausgewählten Aufgabentyps. Wird eine Fehlermeldung auf diese Weise unterdrückt, bleibt die dem Fehler zugehörige Aufgabe bei der Ermittlung der Anzahl fehlgeschlagener Aufgaben in der Job-Pools-Übersicht unberücksichtigt. Diese Operation ist nur möglich, wenn bereits Aufgaben des in der Job-Pools-Übersicht ausgewählten Aufgabentyps auf ihre Bearbeitung warten oder bereits bearbeitet wurden.
  • Die Verwaltung der zu unterdrückenden Fehlermeldungen erfolgt in einem separaten Fenster:
    • In der alphabetisch sortierten Fehlermeldungsliste werden alle zu unterdrückenden Fehlermeldungen gelistet. Eine Fehlermeldung wird unterdrückt, wenn ihr Ausgabetext mit einem Text in der Fehlermeldungsliste übereinstimmt.
    • + erlaubt die Eingabe einer zu unterdrückenden Fehlermeldung über ein eigenes Fenster. Die eingegebene Fehlermeldung erscheint in der Fehlermeldungsliste.
    • ... erlaubt die Änderung der in der Fehlermeldungsliste ausgewählten Fehlermeldung.
    • - löscht die in der Fehlermeldungsliste ausgewählte Fehlermeldung. Leistung


Client-Leistungsdaten aufzeichnen startet und beendet die Erhebung diverser Leistungskennzahlen, die an Aktivitäten der mit dem Wissensnetz verbundenen Software-Komponenten gekoppelt sind. Diese Leistungskennzahlen können zur Performanzanalyse verwendet werden.

Intervall setzt die notwendige Zeitspanne in Sekunden, bis eine Software-Komponente erneut ein Datenpaket mit Leistungskennzahlen an das Admin-Tool sendet. Es kann nach dem Start der Aufzeichnung nicht mehr verändert werden. Die Vorerinstellung liegt bei 10 Sekunden.

In der Leistungskennzahlenübersicht werden die Leistungskennzahlen in geschachtelten Listenpunkten ausgegeben. Per Klick auf die links neben den Rubriken befindlichen Dreiecksymbole können Listenunterpunkte ein- und ausgeklappt werden. Alternativ lässt sich dies über ein Kontextmenü realisieren, das über einen Klick mit der rechten Maustaste auf einen Listenpunkt aufgerufen werden kann:

  • Expand klappt alle direkten Listenunterpunkte des gewählten Listenpunkts aus.
  • Expand fully klappt alle direkten und alle indirekten Listenunterpunkte des gewählten Listenpunkts aus.
  • Contract fully klappt alle Listenunterpunkte des gewählten Listenpunkts wieder ein.

Mit einem Doppelklick auf einen Listenpunkt lassen sich alle darunter abgelegten Leistungskennzahlen in einem separaten Fenster auf einen Blick darstellen. Dort können sie in die Zwischenablage des Betriebssystems kopiert (Schaltfläche In Zwischenablage kopieren) oder über einen Speicherdialog als frei benennbare Textdatei an eine beliebige Stelle exportiert werden (Schaltfläche Speichern).

Aktualisieren aktualisiert die in der Leistungskennzahlenübersicht dargestellten Leistungskennzahlen.

Zurücksetzen löscht die in der Leistungskennzahlenübersicht dargestellten Leistungskennzahlen.

In Zwischenablage kopieren kopiert diein der Leistungskennzahlenübersicht dargestellten Leistungskennzahlen in die Zwischenablage des Betriebssystems.


Leistung prüfen startet einen Testvorgang, der die Performanz des angeschlossenen Mediators auswertet. Dabei werden vier Anfragen an den Mediator geschickt und die an das Admin-Tool gesendeten Antworten ausgewertet. Gemessen werden

  • die Zeiten bis zur Rücksendung einer kleinen Datei (Roundtrip: Blob) und
  • des Ergebnisses einer Indexsuchanfrage (Roundtrip: RPC) sowie
  • die durchschnittliche Übertragungsgeschwindigkeite beim Versand mehrerer Dateien der Größe 1 MB (Throughput: Blob (1.0 MB)) und
  • die durchschnittliche Übertragungsgeschwindigkeite beim Versand mehrerer Dateien der Größe100KB (Throughput: Blob (100.0 KB)).

Die Testergebnisse werden in die bereitgestellte Ergebnisliste geschrieben. Die einzelnen Spalten der Tabelle sind über einen Klick auf den Spaltenkopf sortierbar.

In Zwischenablage kopieren kopiert die Testergebnisse der Ergebnisliste als Reintext in die Zwischenablage des Betriebssystems. Versionsinformation

Über diesen Menüpunkt lassen sich diverse versionsspezifische Informationen über das Wissensnetz und das Admin-Tool abrufen.

Konkret handelt es sich dabei um

  • die Versionsnummer des Admin-Tools (Build),
  • den Veröffentlichungsstatus des Admin-Tools (Release),
  • die Versionsnummer des Wissensnetzes (Netzversion), die Namen des Wissensnetzes und des verwendeten Mediators (Volume-Information),
  • die vom Admin-Tool maximal nutzbare Menge an Systemarbeitsspeicher in Byte (Speicherbegrenzung),
  • die Versionsnummer und der digitale Fingerabdruck der vom Admin-Tool verwendeten Ausführungsumgebung (VM Version),
  • die im Betriebssystem aktive Spracheinstellung (Locale),
  • die im Admin-Tool verwendeten, mitgelieferten Schriftarten (Fonts),
  • die im Wissensnetz installierten Wissensnetzkomponenten inklusive Versionsnummer (Softwarekomponenten) und
  • die im Admin-Tool verwendeten Smalltalk-Pakete inklusive Versionsnummer (Pakete).

Die Informationen werden in einem unsichtbaren Textfeld ausgegeben, welches über ein Kontextmenü verfügt, das per Rechtsklick aktiviert werden kann:

  • Select All markiert den gesamten Text. Alternativ kann mit dem Mauszeiger ein beliebiger Textausschnitt markiert werden.
  • Copy kopiert den gewählten Textbereich in die Zwischenablage des Betriebssystems.
  • Find Again sucht nach dem gewählten Textbereich und findet sein nächstes Auftreten gemäß der Leserichtung.
  • Find erlaubt die Eingabe einer zu suchenden Zeichenkette in einem separaten Fenster und findet ihr nächstes Auftreten gemäß der Leserichtung relativ zur Position der per Mausklick setzbaren Schreibmarke. Bei der Suche wird Groß- und Kleinschreibung unterschieden.

Über die Schaltfläche Kopieren werden alle Informationen in die Zwischenablage des Betriebssystems kopiert.

Die Schaltfläche RSA-Key kopieren kopiert den für jedes kompilierte Admin-Tool einzigartigen Schlüssel in die Zwischenablage des Betriebssystems. Dieser Schlüssel kann in die Initialisierungsdatei eines Mediators (Standarddateiname: mediator.ini) eingetragen werden und beschränkt dadurch den Zugang zu diesem Mediator über ein Admin-Tool auf Admin-Tools mit genau diesem Schlüssel. Systemkonfiguration Benutzer

Die Benutzerverwaltung gleicht derjenigen im Knowledge-Builder mit der Ausnahme, dass keine Verknüpfungen zwischen Nutzern und Objekten des nutzergenerierten Teilnetzes bearbeitet werden können.

Die tabellarische Nutzerübersicht zeigt für jeden im Wissensnetz registrierten Nutzer

  • seinen Benutzernamen (Benutzer),
  • mit welchem Objekt des nutzergenerierten Teilnetzes er verknüpft ist (Verknüpft mit),
  • welchen Status er momentan besitzt (Status),
  • an welchem Datum und zu welcher Uhrzeit er sich über den Knowledge-Builder im Wissensnetz angemeldet hat (Anmeldedatum), sofern er noch angemeldet ist, und
  • mit welchem Verfahren das Passwort verschlüsselt ist (Passworttyp).

Die einzelnen Spalten der Tabelle sind über einen Klick auf den Spaltenkopf sortierbar.

Der Status gibt Auskunft darüber, ob ein Nutzer Administratorrechte besitzt, ob ein Nutzer mit Administratorrechten kein Passwort besitzt und ob ein Nutzer über den Knowledge-Builder im Wissensnetz angemeldet ist. Namen von Nutzern mit Administratorrechten ohne Passwort sind rot markiert.

Erstellen legt einen neuen Nutzer an. Benutzername (verpflichtend) und Passwort (optional) werden in einem eigenen Fenster festgelegt. Die Art und Menge der dafür erlaubten Zeichen ist nicht beschränkt.

Passwort ändern ändert das Passwort des in der Nutzerübersicht ausgewählten Nutzers. In zwei aufeinanderfolgenden Fenstern wird zweimal das neue Passwort eingegeben.

Abmelden meldet den in der Nutzerübersicht ausgewählten Nutzer nach einer Sicherheitsbestätigung aus dem Wissensnetz ab. Damit diese Operation eine Wirkung entfaltet, muss dieser Nutzer aktuell über den Knowledge-Builder im Wissensnetz angemeldet sein.

Löschen löscht den in der Nutzerübersicht ausgewählten Nutzer nach einer Sicherheitsbestätigung. Mindestens ein Nutzer mit Administratorrechten muss verbleiben.

Umbenennen erlaubt über ein Freitextfeld in einem separaten Fenster die Vergabe eines neuen Benutzernamens für den in der Nutzerübersicht ausgewählten Nutzer. Bleibt das Freitextfeld leer, erfolgt keine Umbenennung.

Mitteilung sendet über ein Freitextfeld in einem separaten Fenster eine Nachricht an den in der Nutzerübersicht ausgewählten Nutzer. Die Nachricht wird im Wissensnetz zwischengespeichert und erscheint dem adressierten Nutzer in einem separaten Fenster im Knowledge-Builder, sobald er sich damit am Wissensnetz anmeldet. Der Nutzer kann auf diese Nachricht nicht antworten.

Administrator verleiht oder nimmt dem in der Nutzerübersicht ausgewählten Nutzer Administratorrechte. Damit ein Nutzer Administratorrechte erhalten kann, muss er ein Passwort besitzen. Nachdem er Administratorrechte besitzt, ist eine Löschung des Passworts indes möglich. Mindestens ein Nutzer muss Administratorrechte besitzen.

Operationen öffnet ein neues Fenster, in dem für den in der Nutzerübersicht ausgewählten Nutzer aus einer Liste von Operationen, namentlich

  • Backup erstellen,
  • Backup löschen,
  • Backup wiederherstellen,
  • Garage Collection,
  • Kopieren,
  • Log herunterladen,
  • Volume herunterladen,
  • Volume hochladen,
  • Volume löschen,

diejenigen gewählt werden können, die dieser Nutzer im Rahmen der Einzelnetzverwaltung in Zukunft ohne Eingabe des Mediator-Passworts ausführen darf. Zur Bestätigung der Auswahl muss in das Freitextfeld Server-Passwort für Operationen das korrekte Mediator-Passwort eingegeben werden.

Die Operation Operationen ist nur wählbar für einen Nutzer mit Administratorrechten. Ihre Verwendung setzt außerdem voraus, dass ein Mediator-Passwort gesetzt wurde.

Das Feld Administratoren gibt die Anzahl aller im Wissensnetz registrierten Nutzer mit Administratorrechten an.

Das Feld Benutzer gibt die Anzahl aller im Wissensnetz registrierten Nutzer ohne Administratorrechte an.

Das Feld Aktive gibt die Anzahl aller gegenwärtig über den Knowledge-Builder im Wissensnetz angemeldeten Nutzer an. Blob-Speicherung

Attributwerte von Attributen mit dem Attributdatentyp Datei (sogenannte Blobs) können auch wissensnetzextern in einem Blob-Speicher gespeichert werden. Dies hat den Vorteil, dass sie unabhängig vom Wissensnetz und damit bei Bedarf in einer anderen Systemumgebung verwaltet werden können. Um Blobs in einem Blob-Speicher zu sichern, muss der Blob-Speicher eingerichtet und mit einem konfigurierten Blob-Service (einem Software-Dienst) verbunden werden.

Anlegen erzeugt einen neuen Blob-Speicher. Er erscheint unter Verwendung des Namensformats [Wissensnetz-ID]+[Blob-Speicher-ID] in dem darüber liegenden Textfeld, der Blob-Speicher-Gesamtübersicht.

Löschen löscht den in der Blob-Speicher-Gesamtübersicht ausgewählten Blob-Speicher.

Das Zahlenfeld Löschbare Dateien zeigt die Anzahl der nicht mehr gebrauchten Blobs in dem in der Blob-Speicher-Gesamtübersicht ausgewählten Blob-Speicher. Blobs werden nicht mehr gebraucht, wenn ihre jeweiligen Attribute im Wissensnetz gelöscht wurden oder wenn die Verbindung zwischen Blob-Service und Blob-Speicher per Admin-Tool aufgehoben wurde.

Löschen löscht alle nicht mehr gebrauchten Blobs in dem in der Blob-Speicher-Gesamtübersicht ausgewählten Blob-Speicher.

Im Freitextfeld URLs kann ein Blob-Service identifiziert werden. Dies geschieht über die Eingabe der in der Initialisierungsdatei des zugehörigen Blob-Services (Standarddateiname: blobservice.ini) unter dem Schlüssel interfaces hinterlegten Netzadresse inklusive des Präfixes http. Soll der Blob-Service über mehrere Netzadressen angesprochen werden, können diese hintereinander mit Komma getrennt eingegeben werden.

Alternativ kann auch der im Mediator integrierte Blob-Service angesprochen werden. Dazu müssen in der Initialisierungsdatei des Mediators (Standarddateiname: mediator.ini) unter dem Schlüssel startBlobService der Wert true gesetzt und das Freitextfeld URLs leer gelassen werden. Das rechts neben dem Freitextfeld URLs positionierte Kontrollkästchen Intern indiziert, ob der integrierte Blob-Service oder ein externer Blob-Service angesprochen wird. Die Konfiguration des im Mediator integrierten Blob-Services erfolgt nicht über die Mediator-Initialisierungsdatei, sondern über eine separate Initialisierungsdatei (Standarddateiname: blobservice.ini).

Hinzufügen verbindet den in der Blob-Speicher-Gesamtübersicht ausgewählten Blob-Speicher mit dem über das Freitextfeld URLs identifizierten Blob-Service. Dafür muss der Blob-Service aktiviert sein. Gelingt die Verknüpfung, erscheint der Blob-Speicher unter Verwendung des Namensformats [Wissensnetz-ID]+[Blob-Speicher-ID] in dem darunter liegenden Textfeld, der Übersicht angemeldeter Blob-Speicher.

Aktualisieren aktualisiert die Übersicht angemeldeter Blob-Speicher. Dazu muss ein Blob-Speicher in der Blob-Speicher-Gesamtübersicht ausgewählt sein.

Entfernen unterbricht die Verbindung des in der Übersicht angemeldeter Blob-Speicher ausgewählten Blob-Speichers mit dem Blob-Service und entfernt den Blob-Speicher aus der Übersicht. Dabei verlieren alle im Blob-Speicher hinterlegten Blobs unwiderruflich ihre internen Verweise zu den jeweiligen Attributen im Wissensnetz und können im Wissensnetz nicht mehr abgerufen werden. Damit die Entfernung gelingt, muss der in der Übersicht angemeldeter Blob-Speicher ausgewählte Blob-Speicher auch in der Blob-Speicher-Gesamtübersicht ausgewählt sein.

Alle über einen Blob-Service gesicherten Blobs werden in einem relativ zur Position des Blob-Services liegenden Unterordner blobs abgelegt. Die interne Zuordnung jedes Blobs zu seinem Blob-Speicher und seinem Wissensnetz erfolgt über eine SQLite-Datenbank. Komponenten

Wissensnetze bestehen aus Wissensnetzkomponenten. Neben den Basisfunktionalitäten gewähren sie den Wissensnetzen im Wesentlichen zusätzliche Schnittstellen und im Browser darstellbare Bedienoberflächen für die Nutzdaten (Webfrontends).

Eine besondere Untergruppe von Wissensnetzkomponenten sind die Veröffentlichungsstatuskomponenten (Release States), die in drei Varianten (Preview, Release Candidate, Release) existieren. Wird eine derartige Komponente im Wissensnetz installiert, können ausschließlich Software-Komponenten mit dem passenden Veröffentlichungsstatus auf das Wissensnetz zugreifen.

In der Software-Liste sind alle mit dem Admin-Tool mitgelieferten Wissensnetzkomponenten mit ihren jeweiligen Versionsnummern alphabetisch gelistet. Bedürfen sie einer eigenen Lizenz, ist außerdem vermerkt, ob die aktuelle Lizenz des Wissensnetzes sie umfasst oder nicht. Veröffentlichungsstatuskomponenten verfügen über keine Versionsnummer.

Wird eine Wissensnetzkomponente mit der rechten Maustaste angeklickt, erscheint ein Kontextmenü. Der dort verfügbare Menüpunkt Standardkomponente hinzufügen verfügt über die gleiche Funktionalität wie die gleichnamige Schaltfläche.

Standardkomponente hinzufügen installiert die in der Software-Liste ausgewählte Wissensnetzkomponente im Wissensnetz. Ein separates Fenster informiert über den Installationsstatus. Manche Wissensnetzkomponenten setzen für ihre Installation die Installation anderer Wissensnetzkomponenten im Wissensnetz voraus. Die meisten installierten Wissensnetzkomponenten (außer Veröffentlichungsstatuskomponenten) tauchen im Knowledge-Builder als eigene Einträge in der Rubrik Technik auf. Es kann immer nur eine Veröffentlichungsstatuskomponente zur gleichen Zeit installiert sein.

Lizenztemplate schreiben erzeugt eine inhaltlich zu vervollständigende Vorlage der für die Lizenzschlüsselgenerierung verwendeten Komponentenlizenzkonfigurationsdatei und speichert sie über einen Speicherdialog an einer frei wählbaren Stelle ab (Standarddateiname: [Wissensnetz].componentLicenseTemplate.ini). Unabhängig von der Konfiguration des gerade administrierten Wissensnetzes werden Konfigurationsplatzhalter für die Komponenten KEM, i-views-Core und Knowledge-Builder vorgegeben. In jedem Konfigurationsplatzhalter wird die im Admin-Tool mitgelieferte Versionsnummer der jeweiligen Wissensnetzkomponente voreingetragen.

In der Wissensnetzliste sind alle im Wissensnetz installierten Wissensnetzkomponenten mit ihren jeweiligen Versionsnummern alphabetisch gelistet. Eine installierte Wissensnetzkomponente, für die im Admin-Tool eine neuere Version mitgeliefert ist, ist rot markiert. Die optionale Komponente Knowledge-Builder ist bei einem neuen Wissensnetz standardmäßig vorinstalliert.

Die Textfelder Name und Version zeigen den Namen respektive die dreistellige Versionsnummer der in der Wissensnetzliste ausgewählten installierten Wissensnetzkomponente.

Generische Komponente hinzufügen fügt der Wissensnetzliste eine generische Modellkomponente oder eine generische Softwarekomponente hinzu. Die Auswahl des Komponententyps erfolgt in einem separaten Fenster. Generische Komponenten erlauben die Bündelung projektspezifisch angefertigter Wissensnetzerweiterungen und vereinfachen deren (De-)Installation und Versionskontrolle über das Admin-Tool. Name und Versionsnummer einer im Wissensnetz installierten generischen Wissensnetzkomponente können in den entsprechend benannten Textfeldern frei vergeben werden.

Aktualisieren (die Bezeichnung wechselt zu Erneuern, wenn sie aktiviert werden kann) aktualisiert die in der Wissensnetzliste ausgewählte installierte Wissensnetzkomponente auf die im Admin-Tool mitgelieferte Version. Weicht die Sprache des aktuell laufenden Admin-Tools von der Sprache des Admin-Tools ab, mit dem die Wissensnetzkomponente ursprünglich im Wissensnetz installiert wurde, werden außerdem die Bezeichner aller Elemente und Elementtypen dieser Wissensnetzkomponente aktualisiert. Je nach Wissensnetzkomponente fügt die Aktualisierung den alten Bezeichnern neue Bezeichner in der Sprache des aktuell laufenden Admin-Tools hinzu (in Abhängigkeit von der Spracheinstellung des Knowledge-Builders wird dann die jeweils zutreffende Sprachversion dargestellt) oder ersetzt die alten Bezeichner mit den neuen Bezeichnern.

Entfernen deinstalliert die in der Wissensnetzliste ausgewählte installierte Wissensnetzkomponente. Sofern Wissensnetzkomponenten im installierten Zustand im Knowledge-Builder über einen eigenen Eintrag in der Rubrik Technik verfügen, hinterlassen sie dort nach ihrer Deinstallation ein eigenes Teilnetz, das manuell entfernt werden muss. Wissensnetzkomponenten lassen sich nur entfernen, wenn keine weiteren Wissensnetzkomponenten installiert sind, die von den zu deinstallierenden Wissensnetzkomponenten abhängig sind. Die beiden Wissensnetzkomponenten i-views-Core und View-Konfiguration bieten Basisfunktionalitäten und lassen sich nicht entfernen.

Boost Libraries 1.18.0

Dieses Konfigurationsmenü erscheint nur, wenn die Wissensnetzkomponente Boost Libraries installiert ist.

Mit Ausnahme des Blob-Services und des Mediators können alle Software-Komponenten JavaScript interpretieren. Um den Interpretationsumfang und die Interpretationsgeschwindigkeit von in JavaScript eingebetteten regulären Ausdrücken zu verbessern, kann deren Interpretation an die Bibliothek Boost.Regex übergeben werden. Unter Windows und Linux muss sich dazu die Bibliothek (Dateiname in Windows: boost_regex.dll, Dateiname in Linux: libboost_regex.so) im gleichen Verzeichnis befinden wie die übergebende Software-Komponente. In Mac OS ist die Bibliothek in die Datei der übergebenden Software-Komponente integriert.

Die Wissensnetzkomponente Boost Libraries ermöglicht die Sicherstellung, dass auf die Boost.Regex-Bibliothek zugegriffen werden kann.

Ist die Option Boost-Libraries für alle inkl. Admins erforderlich ausgewählt, können alle Software-Komponenten außer dem Admin-Tool auf das Wissensnetz nur zugreifen, wenn sie auf die Bibliothek Boost.Regex zugreifen können.

Ist die Option Boost-Libraries für alle außer Admins erforderlich ausgewählt, können alle Software- Komponenten außer dem Admin-Tool auf das Wissensnetz nur zugreifen, wenn sie auf die Bibliothek Boost.Regex zugreifen können. Ausgenommen von dieser Zugriffsperre sind Nutzer mit Administratorrechten, die das Wissensnetz über den Knowledge-Builder betreten.

Ist die Option Boost-Libraries nicht erforderlich, nur loggen ausgewählt, hinterlegt jede Software- Komponente in seiner jeweiligen Protokolldatei, sofern vorhanden, eine entsprechende Warnung, wenn es beim Start nicht auf die Bibliothek Boost.Regex zugreifen kann. Ein Zugriff auf das Wissensnetz bleibt unabhängig davon möglich.

Knowledge Portal

Dieses Konfigurationsmenü erscheint nur, wenn die Wissensnetzkomponente Knowledge-Portal installiert ist.

Die Wissensnetzkomponente Knowledge-Portal ermöglicht einem Wissensnetz den Betrieb eines Knowledge-Portals (eines über einen Browser darstellbaren Frontends). Die Konfiguration der Darstellungs- und Bedienelemente dieses Frontends erfolgt im Knowledge-Builder an den entsprechenden Elementtypen über einen von der Wissensnetzkomponente speziell dafür bereitgestellten Editor mit Hilfe der Auszeichnungssprache XML. Zur einfacheren Wartung und logischen Reglementierung der XML-Dokumente lassen sich Schemata im Format DTD installieren, anhand derer die XML-Dokumente validiert werden können.

Im Frontend wird eine Bearbeitungssicht und eine Präsentationssicht mit jeweils exklusiven Darstellungs- und Bedienelementen unterschieden. Für beide Sichten werden separate DTD-Schemata geführt. Die nachfolgend erläuterten Bedienelemente existieren jeweils für jede Sicht.

Über die Schaltfläche Wählen kann auf das Dateisystem des Betriebssystems zugegriffen werden, um eine DTD-Schema-Datei für die jeweilige Sicht zu laden und im Wissensnetz zu installieren. Der Standarddateiname für Bearbeitungssicht-DTDs lautet editConfig.dtd, der Standarddateiname für Präsentationssicht-DTDs lautet viewConfig.dtd.

Zurücksetzen löscht das für die jeweilige Sicht installierte DTD-Schema aus dem Wissensnetz.

Anzeigen stellt das für die jeweilige Sicht installierte DTD-Schema in einem eigenen Fenster dar. Dort kann es in die Zwischenablage des Betriebssystems kopiert (Schaltfläche In Zwischenablage kopieren) oder über einen Speicherdialog als frei benennbare Textdatei an eine beliebige Stelle exportiert werden (Schaltfläche Speichern). Das Fenster verfügt außerdem über ein eigenes Kontextmenü, welches mit einem rechten Mausklick geöffnet werden kann:

  • Suche erlaubt die Eingabe einer zu suchenden Zeichenkette in einem separaten Fenster und findet ihr nächstes Auftreten gemäß der Leserichtung relativ zur Position der per Mausklick setzbaren Schreibmarke. Bei der Suche wird Groß- und Kleinschreibung unterschieden.
  • Alles markieren markiert den gesamten Text. Alternativ kann mit dem Mauszeiger ein beliebiger Textausschnitt markiert werden.
  • Kopieren kopiert den gewählten Textbereich in die Zwischenablage des Betriebssystems.


Dieses Konfigurationsmenü erscheint nur, wenn die Wissensnetzkomponente Druckkomponente installiert ist.

Die Druckkomponente ermöglicht die Integration ausgewählter Wissensnetzelemente in ein speicherbares elektronisches Dokument. Dazu muss eine Dokumentvorlage in den Formaten ODT, DOCX oder RTF über den Knowledge-Builder in das Wissensnetz importiert und mit den in ein Dokument zu integrierenden Wissensnetzelementen verknüpft werden. Die Gestaltung dieser Dokumentvorlage erfolgt in einem externen Office-Programm, von Elementen des Wissensnetzes auszufüllende Platzhalter lassen sich mit Hilfe von KScript und KPath definieren.

Zum Funktionsumfang der Druckkomponente gehört der Konvertierungsservice. Soll im Knowledge-Builder über den Kontextmenüpunt Drucken ein Dokument erzeugt werden, lassen sich neben dem Ursprungsformat der importierten Dokumentvorlage diverse andere Ausgabeformate wählen, in die die Dokumentvorlage konvertiert werden kann. Damit diese Konvertierung funktioniert, müssen eine passend konfigurierte Bridge (ein Software-Dienst) gestartet und mit der Druckkomponente verknüpft sowie eine Version von LibreOffice oder OpenOffice installiert sein.

Passend konfiguriert wird die Bridge über ihre Initialisierungsdatei (Standarddateiname: bridge.ini). Dort muss in der Sektion [KHTTPRestBridge] unter dem Schlüssel services der Wert jodService ergänzt werden. Außerdem ist eine neue Sektion [file-format-conversion] anzulegen und dort über das Schlüsselwertpaar sofficePath=“[Dateipfad]/soffice.exe“ mit einer korrekten Pfadangabe der Ort der Startdatei von LibreOffice beziehungsweise OpenOffice zu hinterlegen.

Die Verknüpfung der Bridge mit der Druckkomponente erfolgt über das Freitextfeld URL. Dort wird die Netzadresse der Bridge im Format http://[ Bridge-IP-Nummer]:[Bridge-Port]/jodService/jodconverter/service eingetragen. Der Pfadabschnitt /jodService/jodconverter/service ist historisch bedingt und aktiviert den vordefinierten jodService.

Überprüfen startet einen Testprozess. Der Testprozess schickt über REST ein Testdokument an die über die Netzadresse festgelegte Bridge und erwartet, dass ein ordnungsgemäß konvertiertes Testdokument zurückgeschickt wird. Das Testergebnis wird in einem separaten Fenster ausgegeben.

Im Freitextfeld Timeout wird festgelegt, wie viele Sekunden lang auf die Rücksendung des konvertierten Testdokuments gewartet wird, bevor eine Fehlermeldung generiert wird. Die Voreinstellung liegt bei 20 Sekunden. Lizenz

Ein Wissensnetz muss eine gültige Lizenz besitzen, damit der Knowledge-Builder und andere Software- Komponenten (mit Ausnahme des Admin-Tools) damit arbeiten können.

Das Feld Status gibt an, ob die Lizenz gegenwärtig gültig oder ungültig ist. Falls sie ungültig ist, wird außerdem ein Grund genannt. Gründe für eine ungültige Lizenz können die Überschreitung des Gültigkeitsdatums oder der maximalen Anzahl erlaubter registrierter Nutzer sein.

Das Feld Kunde beschreibt den Kunden, für den die Lizenz ausgestellt wurde. Neben dem Namen können auch die Adresse und die Abteilung genannt sein.

Das Feld Komponenten stellt den Inhalt der für die Lizenzschlüsselgenerierung verwendeten Komponentenlizenzkonfigurationsdatei [Wissensnetz].componentLicenseTemplate.ini dar. Dort werden Festlegungen über

  • die lizensierten Versionen einzelner Komponenten (version),
  • die maximale Anzahl registrierter Nutzer mit Administratorrechten (maxAdminUsers) und
  • die maximale Anzahl registrierter Nutzer ohne Administratorrechte (maxUsers) getroffen.

Das Feld Partner enthält den Namen des Partners, über den die Lizenz weitergegeben wird.

Das Feld gültig bis enthält das Datum, nach dessen Ablauf die Lizenz erlischt.

Das Feld gültig für Netze enthält eine Liste der Namen aller Netze, auf die die Lizenz beschränkt ist. Möglich ist eine Erfassung über einen regulären Ausdruck.

Das Feld gültig für Server enthält eine Liste aller IP-Adressen und Port-Nummern, über die ein an das Wissensnetz angeschlossener Mediator erreicht werden darf.

Die Felder Partner, gültig bis, gültig für Netze und gültig für Server können leer sein.

Alle Felder verfügen über ein Kontextmenü, das per Rechtsklick aktiviert werden kann:

  • Select All markiert den gesamten Text. Alternativ kann mit dem Mauszeiger ein beliebiger Textausschnitt markiert werden.
  • Copy kopiert den gewählten Textbereich in die Zwischenablage des Betriebssystems.
  • Find Again sucht nach dem gewählten Textbereich und findet sein nächstes Auftreten gemäß der Leserichtung.
  • Find erlaubt die Eingabe einer zu suchenden Zeichenkette in einem separaten Fenster und findet ihr nächstes Auftreten gemäß der Leserichtung relativ zur Position der per Mausklick setzbaren Schreibmarke. Bei der Suche wird Groß- und Kleinschreibung unterschieden.

Hinzufügen / Erneuern erlaubt das Laden eines neuen Lizenzschlüssels (Dateiname: [Lizenzname].key) über das Dateisystem des Betriebssystems. Wartung Client-Caches

Zur Performanzverbesserung verwenden auf das Wissensnetz zugreifende Software-Komponenten häufig einen eigenen Pufferspeicher (Cache). Darin werden Schema- und Konfigurationsdaten des Wissensnetzes zwischengespeichert, um im Falle einer späteren Verwendung schneller auf sie zugreifen zu können.

Client-Caches zurücksetzen löscht diese zwischengespeicherten Daten. Dies ist sinnvoll, wenn sie aufgrund von Änderungen am Schema oder an der Konfiguration veraltet sind. Diese Operation setzt voraus, dass das Wissensnetz über einen Mediator angesteuert wird. Garbage Collection

Die Garbage-Collection ist ein Verfahren, das nicht mehr referenzierte Objekte (nach programmierterminologischer Lesart) in einem Wissensnetz löscht und damit den Speicherverbrauch des Wissensnetzes minimiert. Die Nutzung der Garbage-Collection setzt voraus, dass das zu bereinigende Wissensnetz über einen Mediator angesteuert wird.

Start startet eine neue Speicherbereinigung für das Wissensnetz oder setzt eine pausierte Speicherbereinigung fort. Es erfolgt keine Rückmeldung, wann der Vorgang abgeschlossen ist. Der Stand des Fortschritts kann über den Menüpunkt Aktualisieren in Erfahrung gebracht werden.

Pause unterbricht die Durchführung der aktiven Speicherbereinigung für das Wissensnetz.

Anhalten bricht die Durchführung der aktiven Speicherbereinigung für das Wissensnetz ab.

Aktualisieren schreibt den aktuellen Zustand der Speicherbereinigung für das Wissensnetz in das nebenstehende Textfeld. Ist eine Speicherbereinigung aktiv, erfolgt zusätzlich eine Rückmeldung über den Stand des Fortschritts in Form einer Prozentangabe. Wartung

Wartung jetzt ausführen überprüft

  • die Lizenz (Lizenz),
  • Indizes (Indizes),
  • registrierte Objekte (die Registratur),
  • Rechte (Zugriffsrechte),
  • Trigger (Trigger) und
  • installierte Wissensnetzkomponenten (aktive Komponenten)

auf Mängel. Im Zuge der Prüfung wird auch die über den Knowledge-Builder einsehbare Statistik von Eigenschaftshäufungen pro Objekt (Metriken) aktualisiert.

Gefundene Mängel werden in einer tabellarischen Mangelübersicht gesammelt. Für jeden Mangel wird dort

  • eine kurze Beschreibung, falls einschlägig inklusive der Cluster-ID und der Frame-ID (Format Cluster-ID/Frame-ID) des mangelhaften Objekts (in programmierterminologischer Lesart) (Mitteilung),
  • das vom Mangel betroffene übergeordnete Wissensnetzelement (Objekt),
  • dessen Typ (Typ),
  • die Schwere des Mangels (Priorität) und
  • dessen ersten Feststellungszeitpunkt in Form eines Datums (Datum)

ausgegeben. Die einzelnen Spalten der Tabelle sind über einen Klick auf den Spaltenkopf sortierbar.

Details stellt alle in der Mangelübersicht des ausgewählten Mangels gelisteten Daten in einem neuen Fenster dar. Ergänzt werden die Uhrzeit des ersten Feststellungszeitpunkts sowie Datum und Uhrzeit des letzten Feststellungszeitpunkts. Die Daten können dort in die Zwischenablage des Betriebssystems kopiert (Schaltfläche In Zwischenablage kopieren) oder über einen Speicherdialog als frei benennbare Textdatei an eine beliebige Stelle exportiert werden (Schaltfläche Speichern). Die über die Schaltfläche Details ausgelöste Operation kann alternativ über einen Doppelklick auf einen Mangel in der Mangelübersicht erwirkt werden.

Entfernen löscht den in der Mangelübersicht ausgewählten Mangel. Dies hat keine Auswirkungen auf den ersten Feststellungszeitpunkt des Mangels. Wartungsinformation

Über diesen Menüpunkt lässt sich eine chronologisch sortierte Wartungshistorie aller wesentlichen Administrationsvorgänge im Wissensnetz seit seiner Entstehung abrufen. Erfasst werden Backup- und Transfervorgänge, Komponenteninstallationen und -aktualisierungen sowie Ausführungen von Wartungsskripten und der Garbage-Collection, jeweils mit Datum und Uhrzeit.

Die Wartungshistorie verfügt über ein Kontextmenü, das per Rechtsklick aktiviert werden kann:

  • Select All markiert den gesamten Text. Alternativ kann mit dem Mauszeiger ein beliebiger Textausschnitt markiert werden.
  • Copy kopiert den gewählten Textbereich in die Zwischenablage des Betriebssystems.
  • Find Again sucht nach dem gewählten Textbereich und findet sein nächstes Auftreten gemäß der Leserichtung.
  • Find erlaubt die Eingabe einer zu suchenden Zeichenkette in einem separaten Fenster und findet ihr nächstes Auftreten gemäß der Leserichtung relativ zur Position der per Mausklick setzbaren Schreibmarke. Bei der Suche wird Groß- und Kleinschreibung unterschieden.

In Zwischenablage kopieren kopiert die gesamte Wartungshistorie in die Zwischenablage des Betriebssystems.

Kommentar hinzufügen erlaubt die Eingabe einer Anmerkung über ein Freitextfeld in einem separaten Fenster. Sie wird mit einem Zeitstempel versehen und in die Wartungshistorie aufgenommen. In die Wartungshistorie aufgenommene Anmerkungen lassen sich nicht löschen. Wartungsnachricht

Die Schaltfläche Setzen aktiviert eine Wartungssperre, die jedem Nutzer den Zutritt zum Wissensnetz über den Knowledge-Builder verwehrt. Dafür muss eine Wartungsnachricht formuliert werden.

Die Wartungsnachricht wird im Freitextfeld Wartungsnachricht formuliert. Sie wird jedem Nutzer, der das Wissensnetz bei aktivierter Wartungssperre über den Knowledge-Builder betreten will, in Form einer Fehlermeldung angezeigt.

Die Schaltfläche Zurücksetzen hebt die zuvor gesetzte Wartungssperre auf und löscht die Wartungsnachricht. Wartungsskript

Über Wartungsskript auswählen kann auf das Dateisystem des Betriebssystems zugegriffen werden, um ein Wartungsskript (Dateiname: [Wartungsskript].kss) zu laden. Wartungsskripte werden fallspezifisch in der Programmiersprache Smalltalk angefertigt und erlauben Operationen, die sich nicht über die vordefinierten Funktionen des Admin-Tools oder über die KEM- oder JS-Schnittstellen realisieren lassen.

Verfügt das Wartungsskript über eine Beschreibung, wird diese nach dem Laden des Wartungsskripts in einem unsichtbaren Textfeld unterhalb der Schaltfläche Wartungsskript auswählen ausgegeben. Dieses Textfeld verfügt über ein Kontextmenü, das per Rechtsklick aktiviert werden kann:

  • Select All markiert den gesamten Text. Alternativ kann mit dem Mauszeiger ein beliebiger Textausschnitt markiert werden.
  • Copy kopiert den gewählten Textbereich in die Zwischenablage des Betriebssystems.
  • Find Again sucht nach dem gewählten Textbereich und findet sein nächstes Auftreten gemäß der Leserichtung.
  • Find erlaubt die Eingabe einer zu suchenden Zeichenkette in einem separaten Fenster und findet ihr nächstes Auftreten gemäß der Leserichtung relativ zur Position der per Mausklick setzbaren Schreibmarke. Bei der Suche wird Groß- und Kleinschreibung unterschieden.

Wartungsskript ausführen startet das Wartungsskript. Ein separat erscheinendes Fenster gibt Auskunft, wenn das Wartungsskript vollzogen wurde, und bietet je nach Skript zusätzliche Ausführungsinformationen oder erlaubt skriptspezifische Ausführungsoptionen. XML-Import/-Export Schema und Konfiguration

Ein Wissensnetz im weiteren Sinne besteht neben den nutzergenerierten und über Komponenten eingebrachten Teilnetzen (Schemata mit Nutzdaten) noch aus diversen weiteren Bausteinen (Konfigurationen), die dieses Teilnetz funktional erweitern, konfigurieren oder damit arbeiten. Im Rahmen dieses Menüpunkts werden Schemata und Konfigurationen zusammenfassend als Konfigurationen bezeichnet.

Zahlreiche Konfigurationen eines Wissensnetzes lassen sich gezielt exportieren und importieren.

Die Konfigurationsübersicht bietet einen listenartigen Überblick über alle mittels der im Folgenden beschriebenen Operationen prinzipiell transferierbaren Konfigurationstypen eines Wissensnetzes. Prinzipiell transferierbar sind

  • einzelne registrierte Abbildungen von Datenquellen (Abbildungen von Datenquellen),
  • einzelne von Administratoren konfigurierte und benutzerdefinierte Suchfelder (Abfragen),
  • einzelne Datenquellenzugriffseinstellungen zur Nutzung für Abbildungen von Datenquellen (Datenquellen),
  • die Druckkonfiguration (Druckkonfiguration),
  • die Menge aller innerhalb der Rubrik Ermittlung der View-Konfiguration definierten Bausteine (Ermittlung der View-Konfiguration),
  • einzelne Indexfilter (Indexfilter),
  • einzelne Indexerkonfigurationen (Indizes),
  • die LDAP-Authentifizierung (LDAP),
  • die Lizenz des Wissensnetzes (Lizenz),
  • einzelne registrierte Sammlungen semantischer Objekte (Sammlung von Wissensnetzelementen),
  • einzelne registrierte Skripte (Skripte),
  • den Arbeitsordner (Strukturordner),
  • die Menge aller innerhalb der Rubrik Trigger definierten Bausteine (Trigger),
  • einzelne Teilnetze (Wissensnetz) und
  • die Menge aller innerhalb der Rubrik Rechte definierten Bausteine (Zugriffsrechte).

Die Konfigurationsübersicht verwaltet überdies alle konkret zum Export bestimmten Konfigurationen. Zum Export bestimmte Konfigurationen erscheinen als ausklappbare Listenunterpunkte ihrer jeweiligen Konfigurationstypen. Benötigen diese Konfigurationen für ihren erfolgreichen Export andere Konfigurationen, sind diese anderen Konfigurationen wiederum in Form ausklappbarer Listenunterpunkte der jeweiligen Konfigurationen aufgeführt. Konfigurationstypen ohne eigene Konfigurationen sind kursiv gekennzeichnet, Konfigurationstypen mit eigenen Konfigurationen sind fett gekennzeichnet und stellen die Anzahl ihrer zugeordneten Konfigurationen in Klammern dar. Konfigurationstypen und Konfigurationen jedes Konfigurationstyps sind jeweils in alphabetischer Reihenfolge sortiert.

Das Ein- und Ausklappen von Listenunterpunkten in der Konfigurationsübersicht geschieht per Klick auf die sich links neben den Listenpunkten befindlichen Dreiecksymbole. Alternativ lässt sich dies über ein Kontextmenü realisieren, das über einen Klick mit der rechten Maustaste auf einen Listenpunkt aufgerufen werden kann:

  • Expand klappt alle direkten Listenunterpunkte des gewählten Listenpunkts aus.
  • Expand fully klappt alle direkten und alle indirekten Listenunterpunkte des gewählten Listenpunkts aus.
  • Contract fully klappt alle Listenunterpunkte des gewählten Listenpunkts wieder ein.

Hinzufügen fügt der Konfigurationsübersicht eine Konfiguration des dort ausgewählten Konfigurationstyps hinzu. Existiert mehr als eine Konfiguration für den ausgewählten Konfigurationstyp im Wissensnetz, schließt sich eine Auswahlmöglichkeit in einem separaten Fenster an. Die Auswahl erfolgt dort entweder einzeln per Klick auf die jeweiligen Konfigurationen in einer Liste oder pauschal über die Schaltfläche Alles aus-/abwählen.

Entfernen löscht entweder alle Konfigurationen des in der Konfigurationsübersicht ausgewählten Konfigurationstyps oder die in der Konfigurationsübersicht ausgewählte Konfiguration.

Alle hinzufügen fügt der Konfigurationsübersicht alle im Wissensnetz existierenden Konfigurationen hinzu und verteilt diese auf die jeweils passenden Konfigurationstypen.

Über die Schaltflächen ... kann auf das Dateisystem des Betriebssystems zugegriffen werden, um ein Wartungsskript (Dateiname: [Wartungsskript].kss) zu laden. Wartungsskripte werden fallspezifisch in der Programmiersprache Smalltalk angefertigt und erlauben Operationen, die sich nicht über die vordefinierten Funktionen des Admin-Tools oder über die KEM- oder JS-Schnittstellen realisieren lassen.

Wird ein Wartungsskript geladen, erscheint der Dateiname des gewählten Wartungsskripts im links von der jeweiligen Schaltfläche positionierten Textfeld. Werden im Anschluss Konfigurationen importiert, wird das Wartungsskript ausgeführt. Werden im Anschluss Konfigurationen exportiert, wird das Wartungsskript ebenfalls exportiert und erst beim Import dieser Konfigurationen ausgeführt. Der genaue Ausführungszeitpunkt des Wartungsskripts in Relation zum Importprozess hängt davon ab, über welche der beiden ...-Schaltflächen es geladen wurde. Er befindet sich entweder vor dem Start des Importprozesses oder nach dem Ende des Importprozesses.

Export exportiert die in der Konfigurationsübersicht ausgewählten Konfigurationen. Zur Auswahl stehen der Export in eine einzige Archivdatei im Archivformat tar oder in einzelne Dateien in einem Ordner. Die Auswahl der Exportmethode vollzieht sich in einem separaten Fenster:

  • In den Freitextfeldern Datei oder Verzeichnis kann der Name der Archivdatei (Dateiname: [Wissensnetz].tar) respektive des Ordners (kein Standardname) angegeben werden. Die Archivdatei respektive der Ordner wird im gleichen Ordner wie das Admin-Tool angelegt. Alternativ kann über Wählen ein Speicherdialog aufgerufen werden, um Name und Speicherort der Archivdatei respektive des Ordners frei festzulegen.

Import importiert nach einer Bestätigungsfrage Konfigurationen in das Wissensnetz. Zur Auswahl stehen der Import aus einer einzigen Archivdatei im Archivformat tar oder aus einzelnen Dateien in einem Ordner. Die Auswahl der Importmethode vollzieht sich in einem separaten Fenster:

  • In den Freitextfeldern Datei oder Verzeichnis kann der Name der Archivdatei (Dateiname: [Wissensnetz].tar) respektive des Ordners (kein Standardname) angegeben werden. Die Archivdatei respektive der Ordner wird im gleichen Ordner wie das Admin-Tool gesucht. Alternativ kann über Wählen auf das Dateisystem des Betriebssystems zugegriffen werden, um eine Archivdatei respektive einen Ordner an einer beliebigen Stelle auszuwählen.
  • Ist die zu importierende Archivdatei respektive der zu importierende Ordner gewählt, erscheint in einem weiteren Fenster eine Übersicht über alle darin enthaltenen Konfigurationen. Diese Übersicht kann dort in die Zwischenablage des Betriebssystems kopiert (Schaltfläche In Zwischenablage kopieren) oder über einen Speicherdialog als frei benennbare Textdatei an eine beliebige Stelle exportiert werden (Schaltfläche Speichern). Die Schaltfläche Import startet den Importprozess. Das Fenster verfügt außerdem über ein eigenes Kontextmenü, welches mit einem rechten Mausklick geöffnet werden kann:
    • Suche erlaubt die Eingabe einer zu suchenden Zeichenkette in einem separaten Fenster und findet ihr nächstes Auftreten gemäß der Leserichtung relativ zur Position der per Mausklick setzbaren Schreibmarke. Bei der Suche wird Groß- und Kleinschreibung unterschieden.
    • Alles markieren markiert den gesamten Text. Alternativ kann mit dem Mauszeiger ein beliebiger Textausschnitt markiert werden.
    • Kopieren kopiert den gewählten Textbereich in die Zwischenablage des Betriebssystems.

Speichern speichert die in der Konfigurationsübersicht für dieses Wissensnetz aktuell getroffene Auswahl an Konfigurationen als XML-Datei. Über einen Speicherdialog werden Name und Ort der XML-Datei (Standarddateiname: instruction.xml) festgelegt.

Laden greift auf das Dateisystem des Betriebssystems zu, um eine zuvor gespeicherte Auswahl an Konfigurationen für dieses Wissensnetz aus einer XML-Datei (Standarddateiname: instruction.xml) zu laden.

Aktualisieren fügt dem Wissensnetz die mit dem Attributdatentyp Boolesch ausgestatteten Attributtypen

  • XML: Alle Objekte exportieren,
  • XML: Direkte Objekte exportieren,
  • XML: Typ und alle Untertypen nicht exportieren und
  • XML: Untertypen nicht exportieren

hinzu, falls sie darin noch nicht existieren. Diese Attributtypen werden benötigt, um bei einem Export einer Konfiguration des Konfigurationstyps Wissensnetz auszuwählen, welche in dieser Konfiguration befindlichen Elemente und Elementtypen jeweils exportiert und nicht exportiert werden sollen. Dazu werden diese Attributtypen über den Knowledge-Builder an passende Objekttypen gehängt und mit passenden Attributwerten versehen.

Soweit nicht anders über diese Attributwerte konfiguriert, gilt für jeden Objekttyp, dass er selbst exportiert wird, nicht aber seine Objekte. Wird ein Objekt oder Objekttyp exportiert, werden alle direkt mit ihm verbundenen Attribute und Relationen sowie deren Attribut- respektive Relationstypen ebenfalls exportiert.

3 ViewConfig-Mapper
3.1 Introduction

Mit dem Viewconfig Mapper (kurz VCM) können über einen einfachen Weg View-Konfigurationen in ein Web-Frontend transportiert und dort dargestellt werden. Dazu wird das in der View-Konfiguration generierte JSON über die REST-Schnittstelle von i-views in das Frontend transportiert und dort mithilfe von Mustache-Templates in HTML übersetzt.

Der Viewkonfig-Mapper unterstützt panelbasierte und rein viewbasierte View-Konfigurationen. Es werden alle Viewtypen, die im Knowledge-Builder zur Verfügung stehen, auch im Web-Frontend unterstützt. Für einige von ihnen (wie z.B. einer Graph-Konfiguration) sind weitere Plugins nötig, die als Bibliotheken zur Verfügung stehen und zu einem großen Teil auch in der Basis-Anwendung des Viewkonfig-Mappers, die einfach über eine REST-Ressurce eingebunden werden kann, schon integrtiert sind.

Der Viewconfig Mapper ist eine Single-Page-Applikation, die client-seitig im Web-Browser läuft. Sie verwendet ractive (ractive.js.org) für eine interaktive und reaktive Anwendung, die auf mustache-Templates (mustache.github.io/) basiert.

3.2 Configuration

Zunächst muss die Viewkonfig-Mapper-Komponente im Netz hinzugefügt werden. Dabei werden REST-Ressourcen, die spezielle für den Viewkonfig-Mapper zur Verfügung stehen, angelegt und einige speziell auf das Frontend abgestimmte Viewkonfigurationsoptionen angelegt.

Zu den speziellen Viewkonfig-Mapper-Requests gehören action, blob, config, element und panel/contents. Hinzu kommt eine Static File Resource, die die Viewkonfig-Mapper-Anwendung (Basis-Anwendung oder Anpassungsprojekt) ausliefert. Im obigen Beispiel wird die Anwendung als File Resource ausgeliefert. Diese REST-Resource bietet dann den Einstieg über das Web-Frontend in die Viewkonfig-Mapper-Anwendung.

3.2.1 View-Konfigurationen fĂĽr den Viewconfig Mapper

Der Viewconfig-Mapper interpretiert alle View-Konfigurationen, die in i-views erstellt wurden. Dabei gibt es jedoch ein paar Unterschiede zwischen der Verarbeitung im Knowledge-Builder und im Viewconfig-Mapper, auf die in diesem Kapitel eingegangen wird. Panel configuration

 Falls die Web-Anwendung auf einer Panel-Konfiguration basieren soll, muss die Anwendung mit der Panel-Konfiguration verknüpft werden.

Dazu wird an der Anwendung ein Objekt eines Hauptfensterpanels angehängt, an das jegliche weitere Panel-Konfigurationen angehängt werden können. Weitere Panels (wie z.B. Dialog-Panels) sind optional. Falls sie jedoch im Web-Frontend verwendet werden sollen, müssen sie über diesen Weg mit der Anwendung verbunden sein. Es reicht nicht, sie z.B. nur als Zielfenster einer Aktion zu definieren, da sie sonst für die Anzeige der Anwendung nicht berücksichtigt würden. anwenden in

Um eine geeignete View-Konfiguration für ein semantisches Element zu bestimmen, wird einerseits nach dem Typ des Elements geschaut sowie nach dem Kontext, in dem eine View-Konfiguration verwendet werden soll. Dieser Kontext wird über die Relation "anwenden in" bestimmt. Für die Verwendung einer View-Konfiguration in vcm sollte daher darauf geachtet werden, dass die Relation entsprechend gezogen wurde.

Mögliche Ziele von "anwenden in" sind Anwendung, Panel und Aktion.

Bei Panel-Konfigurationen kommt diese Technik immer dann zur Anwendung, wenn bei einem Panel "Flexible Ansicht" konfiguriert wurde. Style/additionalConfig

Grundsätzlich wird die Darstellung in HTML über die Templates bestimmt, so dass dies nicht Teil der View-Konfiguration ist. Um aber dem Ersteller der View-Konfigurationen die Möglichkeit zu geben, in einigen Aspekten doch Einfluss auf die Darstellung zu haben, gibt es sogenannte "Styles" in der View-Konfiguration.

Im Reiter "Styles" können beliebig viele Styles hinzugefügt werden. Nach dem Ablegen eines Styles hat man die Möglichkeit, diesen genauer zu definieren. Unter dem Reiter "StylePropertyKey" findet man alle bereits konfigurierten Styles und kann die entsprechenden Werte für das Frontend dort konfigurieren.

Eine Besonderheit kommt dem Attribut "render-Mode" zu: Es sorgt dafür, dass für einen View-Typ (Gruppe, Alternative, Tabelle, Hierarchie, etc.) nicht das Default-Template angewendet wird, sondern ein über "render-Mode" spezifiziertes Template. Das Mapping erfolgt dabei über den Dateinamen des Templates nach dem Muster VIEWTYP_RENDERMODE.html. ausfĂĽhren in

Beim Anlegen einer benutzerdefinierten Aktion kann auch die Relation "ausführen in" gezogen werden. Dies bewirkt, dass die zurückgegebenen Daten nicht auf alle vcm-Inhalte angewendet werden, sondern sich die Änderung nur auf eine bestimmte View bezieht. Diese View muss als Relationsziel von "ausführen in" gesetzt werden. Globaler Kontext

Der Viewconfig-Mapper verwendet die Session Storage, um die Menüführung für den Nutzer verständlich zu gestalten. Damit dies auch funktioniert, wenn aktualisierte Daten aus dem Backend geladen werden, wird bei allen Aktionsrequests ein für das Backend verständlicher Teil aus der Session Storage mitgeschickt, der sogenannte globale Kontext. Dieser hat z.B. Einfluss auf das Auswählen des aktiven Reiters einer Alternative oder die Sortierung einer Tabelle.

Ab 5.2 ist es möglich, für eigene Widgets relevante Informationen aus dem Backend (z.B. aus Action-Skripten) an das Frontend zu schicken. Dazu bietet die JavaScript-API eine Schnittstelle zu customVariables an. Diese können im Frontend ausgelesen werden.

3.2.2 Login-Konfiguration JWT Authentication Login Formular anpassen

Das Loginformular kann über folgende Übersetzungsschlüssel angepasst werden:

login.form.titleÜberschrift des Formulars
login.form.username.labelLabel des Benutzernamenfeldes
login.form.username.placeholderPlaceholder des Benutzernamenfeldes
login.form.password.labelLabel des Passwortfeldes
login.form.password.placeholderPlaceholder des Passwortfeldes


3.3 Actions

 In diesem Kapitel werden alle VCM-spezifischen Aktionseinstellungsmöglichkeiten und Skript-Parameter (context, actionResponse) beschrieben.

vcm unterstützt Standard-Interaktionen wie das Editieren von Inhalten, ohne dass dies extra konfiguriert werden muss. Es ist aber möglich, in der View-Konfiguration benutzerdefinierte Aktionen zu definieren, die dann auch in vcm ausgeführt werden können.

Es gibt zwei Sorten von benutzerdefinierten Aktionen:

  • Standard-Aktion mit benutzerdefiniertem Rückgabewert
  • Skript-Aktion

Die Auswahl geschieht über ein Dropdown-Menü.

Für eine Skript-Aktion muss in diesem Menü "Skript" ausgewählt werden und in der Liste unter dem Eintrag "Skript" ein Skript angelegt werden.

Um den Rückgabewert einer Aktion zu bestimmen, kann für beide Aktionsarten unter dem Eintrag "Skript (Action Response)" ein Skript angelegt werden.

Ein typisches Rückgabeskript:

function actionResponse(element, context, actionResult){
 var actionResponse = new $k.ActionResponse();
                elementId: actionResult.idString(),
                viewMode: "edit"
 return actionResponse;

Mögliche Follow-Ups:

  • show - Die übergebenen Inhalte werden geladen und auf der ganzen Seite dargestellt.
  • refresh - Alle Komponenten aktualisieren ihre Inhalte.
  • reload - Die Seite wird neu geladen.
  • update - Die übergebenen Inhalte werden geladen und in der View dargestellt, die in "ausführen in" bestimmt wurde. Es kommt zu einem Fehler, wenn "ausführen in" nicht gesetzt ist.

Außerdem ist es möglich, eigene Follow-Ups zu definieren. Die Interaktion mit dem Frontend muss dann aber darauf angepasst werden, da vcm dafür standardmäßig nicht ausgelegt ist. Auf der anderen Seite ist es aber auch möglich, die derzeitigen Reaktionen auf einen Follow-Up im eigenen Anpassungsprojekt zu überschreiben.

 Weitere mögliche Rückgabewerte:

  • elementId - ID des anzuzeigenden Elements
  • viewMode - Derzeit gibt es nur die Unterscheidung zwischen Lese- und Schreibmodus, wobei standardmäßig der Lesemodus angenommen wird und nur bei viewMode: "edit" der Schreibmodus angezeigt wird.

 Auch hier ist es möglich, eigene Werte zu definieren und sein Frontend darauf anzupassen.

3.4 View-Konfigurationselemente
3.4.1 Alternative

Bei einer Alternative-View handelt es sich um eine Sammel-View für andere Views, d.h. mithilfe dieses Viewtyps lassen sich Views zusammenfassen, die Daten zu einem gemeinsamen Objekt anzeigen (z.B. eine Eigenschaften-View mit den Lebensdaten eines Künstler und eine Tabelle-View, in der die Werke des Künstlers aufgelistet werden). Im Gegensatz zur Gruppen-View werden die zusammengefassten Views aber nicht gleichzeitig, sondern abwechselnd (z.B. über Reiter) angezeigt.

Um die Views zusammenzufassen, werden die entsprechenden Views als Unterviews an die Alternative-View angehängt. Ihre Position entscheidet dabei über die Reihenfolge der Anzeige. Deswegen kann die Position über die Pfeilbuttons geändert werden.

Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung der Liste:

BeschriftungDer hier eingegebene Wert erscheint als Überschrift der Alternative
Default-AlternativePer Default wird die erste angehängt View angezeigt. Falls man z.B. möchte, dass die View auf dem dritten Reiter zuerst angezeigt wird, kann man diese View hier angeben. Im Frontend wird die zuletzt angezeigte View innerhalb einer Session vermerkt, so dass der Nutzer, wenn er innerhalb einer Session eine Alternative-View mehrfach betrachtet, auf den zuletzt von ihm betrachteten Reiter landet.
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.
Skript für BeschriftungAlternativ zu "Beschriftung" kann der Titel der Alternative in einem Skript bestimmt werden.
Skript für SichtbarkeitÜber dieses Skript kann festgelegt werden, ob und unter welchen Bedingungen die Alternative angezeigt werden soll.

Im Reiter"Menüs" lassen sich Aktionen zu der Alternative konfigurieren, und im Reiter "Styles" können bestimmte Darstellungsoptionen ausgewählt werden. Der "KB"-Reiter enthält Optionen, die nur für den Knowledge-Builder gelten und im Web-Frontend keine Anwendung finden. Über den "Kontext"-Reiter lässt sich konfigurieren, für welche Objekttypen die Alternative-View verwendet werden soll und in welchen Anwendungskontexten.

Eine Alternative-View sollte dann verwendet werden, wenn mehrere Views auf den Daten eines Objekts oder Typs basieren, aber nicht gleichzeitig sondern alternativ angezeigt werden sollen.

3.4.2 Group

Bei einer Gruppen-View handelt es sich um eine Sammel-View für andere Views, d.h. mithilfe dieses Viewtyps lassen sich Views gruppieren, die Daten zu einem gemeinsamen Objekt anzeigen (z.B. eine Eigenschaften-View mit den Lebensdaten eines Künstler und eine Tabelle-View, in der die Werke des Künstlers aufgelistet werden). Um die Views zu gruppieren, werden die entsprechenden Views als Unterviews an die Gruppe-View angehängt. Ihre Position entscheidet dabei über die Reihenfolge der Anzeige. Deswegen kann die Position über die Pfeilbuttons geändert werden.

Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung der Liste:

BeschriftungDer hier eingegebene Wert erscheint als Überschrift der Gruppe
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.
Skript für BeschriftungAlternativ zu "Beschriftung" kann der Titel der Gruppe in einem Skript bestimmt werden.
Skript für SichtbarkeitÜber dieses Skript kann festgelegt werden, ob die Gruppe angezeigt werden soll.

Im Reiter"Menüs" lassen sich Aktionen zu der Gruppe konfigurieren, und im Reiter "Styles" können bestimmte Darstellungsoptionen ausgewählt werden. Der "KB"-Reiter enthält Optionen, die nur für den Knowledge-Builder gelten und im Web-Frontend keine Anwendung finden. Über den "Kontext"-Reiter lässt sich konfigurieren, für welche Objekttypen die Gruppen-View verwendet werden soll und in welchen Anwendungskontexten.

Eine Gruppen-View sollte dann verwendet werden, wenn mehrere Views gleichzeitig gruppiert angezeigt werden sollen, die auf den Daten eines Objekts oder Typs basieren. Im Gegensatz dazu steht die Alternative, die die enthaltenen Views zu einem Objekt alternierend (z.B. als reiter) anzeigt.

Im Web-Frontend gibt es unterschiedliche Möglichkeiten, die gruppierten Views anzuzeigen. Falls nicht anders konfiguriert, werden die Views untereinander angeordnet. Mit einem Style kann man eine horizontale oder Grid-Anordnung ermöglichen:

Dazu wird ein Style-Objekt an der Gruppe-View angelegt und im Reiter Viewkonfiguration-Mapper wird als "renderMode" der Wert "grid" ausgewählt und bei "groupColumnGrid" die gewünschte Grid-Konfiguration eingetragen.

Die Beispiel-View hat das Grid "4 8 0". Die Summe der Summanden muss immer zwölf ergeben.

Wählt man den "renderMode" "panel" aus, erhält man eine aufklappbare Gruppe.

Auch die aus Bootstrap bekannten "renderMode"-Werte "jumbotron" und "well" werden bei der Gruppe unterstützt.

3.4.3 Hierarchy

 Bei einer Hierarchie-View handelt es sich um eine hierarchische Ansicht zu konfigurierbaren Aspekten eines Objekts.

Die Konfiguration im Knowledge-Builder erfolgt über das Anlegen einer Hierarchie-View.


Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung der Hierarchie:

BeschriftungDer hier eingegebene Wert erscheint als Überschrift der Hierarchie
Skript für BeschriftungAlternativ zu "Beschriftung" kann der Titel der Hierarchie in einem Skript bestimmt werden.
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.

Relation (aufsteigend)

Relation (absteigend)

Strukturabfrage (aufsteigend)

Strukturabfrage (absteigend)

Skript (aufsteigend)

Skript (absteigend)

Die Hierarchie-View geht von einem Objekt als Basis aus. Welche Knoten und Äste für dieses Objekt angezeigt werden sollen, ist sowohl in aufsteigender als auch in absteigender Richtung konfigurabel. Dabei kann eine im Netz definierte Relation als Verbindung zwischen den Knoten ausgewählt werden, aber auch eine Strukturabfrage oder sogar ein Skript. Diese drei Arten können vermischt werden, d.h. es ist möglich z.B. in absteigende Richtung eine Relation anzugeben und in aufsteigende Richtung eine Strukturabfrage. Die Angabe beider Richtungen ist optional, es ist auch möglich nur die aufsteigende oder nur die absteigende Richtung zu konfigurieren. Im ersten Fall wäre dann das Objekt, auf dem die Hierarchie basiert, der unterste Knoten. Und im zweiten Fall wäre das Basisobjekt der Hierarchie dann der Wurzelknoten der Hierarchie.
Absteigend sortierenPer default wird die Hierarchie aufsteigend sortiert. Durch Aktivieren der Checkbox wird diese Sortierreihenfolge umgekehrt.
Aktion (Auswahl)An dieser Stelle kann die Aktion konfiguriert werden, die erfolgen soll, wenn ein Nutzer ein Element in der Hierarchie selektiert.
Banner der Hierarchiewurzel anzeigenÜber diese Checkbox kann festgelegt werden, ob das Banner des Wurzelelements in der Hierarchie-View angezeigt werden soll. Diese Konfiguration wird nur im Knowledge-Builder berücksichtigt.
Detailansicht ausblendenStandardmäßig wird zu einem selektierten Knoten (siehe auch Aktion (Auswahl) eine Detailansicht angezeigt, dies kann über diese Option deaktiviert werden.
Primäres SortierkriteriumÜber das Sortierkriterium wird bestimmt, nach welchem Aspekt die Sortierung der Hierarchieelemente auf eine Ebene erfolgen soll.
Sekundäres SortierkriteriumWie "Primäres Sortierkriterium", wird aber nur genutzt, falls die errechnete Position aus "Primäres Sortierkriterium" bei zwei oder mehr Attributen gleich ist.
Skript für SichtbarkeitÜber dieses Skript kann festgelegt werden, ob die Liste angezeigt werden soll.
Skript für SortierungDieses Skript wird genutzt, wenn als primäres oder sekundäres Sortierkriterium "Skript für Sortierung" ausgewählt wurde.
Verbiete manuelles SortierenÜber diese Option wird die Möglichkeit eine Hierarchie durch den Nutzer umsortieren zu lassen unterbunden. Diese Option wird nur im Knowledge-Builder angewendet.

Es ist möglich, an der ganzen  Hierarchie Aktionen und Styles zu konfigurieren oder diese nur auf Knotenebene anzubringen. Daher gibt es einen Reiter "Hierarchie" mit den Unterpunkten "Menüs" und "Styles" und einen Reiter "Knoten" mit den gleichen Unterpunkten. Im Reiter"Menüs" lassen sich Aktionen zu der Liste konfigurieren, und im Reiter "Styles" können bestimmte Darstellungsoptionen ausgewählt werden. Der "KB"-Reiter enthält Optionen, die nur für den Knowledge-Builder gelten und im Web-Frontend keine Anwendung finden. Über den "Kontext"-Reiter lässt sich konfigurieren, für welche Objekttypen die Hierarchie-View verwendet werden soll und in welchen Anwendungskontexten.

3.4.4 Eigenschaften

Bei einer Eigenschaften-View handelt es sich um eine Liste von Attributen und Relationen zu einem Objekt.

Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung der Liste:

Absteigend sortierenGrundsätzlich werden die enthaltenen Attribute/Relationen in der Reihenfolge angezeigt, wie es die Reihenfolge der eingehängten Eigenschaft-Views vorgibt. Da es bei diesen aber möglich ist, übergeordnete Typen (z.B. "Benutzerrelation") anzugeben, werden die so zusammengefassten Eigenschaften nach ihrem Namen aufsteigend sortiert. Durch Aktivieren der Checkbox "Absteigend sortieren" kann diese Reihenfolge geändert werden.
BeschriftungDer hier eingegebene Wert erscheint als Überschrift der Liste
Initial ausgeklapptIm Knowledge-Builder werden ab einer großen Anzahl Eigenschaften nicht direkt angezeigt, sondern ausklappbar. Durch das Aktivieren dieser Option werden sie direkt ausgeklappt.
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.
Primäres SortierkriteriumGrundsätzlich werden die enthaltenen Attribute/Relationen in der Reihenfolge angezeigt, wie es die Reihenfolge der eingehängten Eigenschaft-Views vorgibt. Über diesen Punkt kann dieses Verhalten geändert werden. Mögliche Werte sind "Position", "Skript für Sortierung" und "Wert". Bei "Wert" wird nach dem Attributwert sortiert und nicht nach dem Namen des Attributs.
Sekundäres SortierkriteriumWie "Primäres Sortierkriterium", wird aber nur genutzt, falls die errechnete Position aus "Primäres Sortierkriterium" bei zwei oder mehr Attributen gleich ist.
Skript für BeschriftungAlternativ zu "Beschriftung" kann der Titel der Liste in einem Skript bestimmt werden.
Skript für SichtbarkeitÜber dieses Skript kann festgelegt werden, ob die Liste angezeigt werden soll.
Skript für SortierungDieses Skript wird genutzt, wenn als primäres oder sekundäres Sortierkriterium "Skript für Sortierung" ausgewählt wurde.

Im Reiter"Menüs" lassen sich Aktionen zu der Liste konfigurieren, und im Reiter "Styles" können bestimmte Darstellungsoptionen ausgewählt werden. Der "KB"-Reiter enthält Optionen, die nur für den Knowledge-Builder gelten und im Web-Frontend keine Anwendung finden. Über den "Kontext"-Reiter lässt sich konfigurieren, für welche Objekttypen die Eigenschaften-View verwendet werden soll und in welchen Anwendungskontexten.

Für die Lese-Ansicht kann die Eigenschaften-View alleinstehend verwendet werden, wird aber oft auch in Gruppe- oder Alternative-Views verwendet. Um die Bearbeitung der Objekteigenschaften zu ermöglichen, muss eine Eigenschaften-View in eine Edit-View eingehängt werden.

Die Attribute und Relationen, die zu einem Objekt angezeigt werden sollen, sind konfigurabel. Dazu werden einer Eigenschaften-View Eigenschaft-Views hinzugefügt, an denen das/die entsprechende Attribut/Relation ausgewählt werden und bestimmt wird, wie diese im einzelnen dargestellt werden sollen.

3.4.5 Property

Bei einer Eigenschaft-View handelt es sich um die Darstellunskonfiguration eines Attributs oder einer Relation zu einem Objekt. Eine Eigenschaft-View kann nur innerhalb einer Eigenschaften-View verwendet werden.

Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung der Attrubute/Relationen:

Absteigend sortierenDa zu einem Objekt mehrere Attribute/Relationen eines Typs existieren können, werden diese bei Mehrfachvorkommen nach dem Eigenschaftswert aufsteigend sortiert. Diese Option dreht die Sortierreihenfolge. Es ist auch möglich bei "Eigenschaft" einen übergeordneten Attributtyp (z.B. Benutzerrelation) auszuwählen. Die Sortierreihenfolge der untergeordneten Attributtypen wird aber über die Sortierungskonfiguration der dazugehörigen Eigenschaften-View bestimmt. Auf Basis der Eigenschaft-View kann nur die Sortierung innerhalb des gleichen Attributs Einfluss genommen werden.
Aktion (Auswahl)Die hier konfigurierte Aktion wird ausgeführt, wenn der Eigenschaftswert im Frontend ausgewählt wird (z.B. per Klick).
anwenden auf/anwenden inAn dieser Stelle kann der Kontext genauer bestimmt werden, so dass unterschiedliche Konfigurationen einer Eigenschaft in einer Eigenschaften-View genutzt werden können.
BeschriftungEine Eigenschaft wird als Name-Wert-Paar in den Frontends dargestellt. Als default wird der Name der konfigurierten Eigenschaft genommen. Über "Beschriftung" kann ein anderer Wert als Name angezeigt werden.
EigenschaftAn dieser Stelle wird der Attribut-/Relationstyp des dargestellten Objekts bestimmt. Es ist möglich, einen übergeordneten Attributtyp anzugeben. Wenn z.B. "Benutzerrelation" ausgewählt wird, werden in der dargestellten Liste alle Relationsausprägungen, die der Benutzerrelation untergeordnet sind, zu diesem Objekt angezeigt. Die Sortierreihenfolge dieser Eigenschaften kann in der Eigenschaften-View konfiguriert werden.
Einblendung neuer EigenschaftenFalls noch kein Attribut dieses Typs am dargestellten Objekt existiert, würde in der Default-Ansicht das Attribut nicht aufgeführt. Über diese Option kann man konfigurieren, dass stattdessen ein Platzhalter mit einem Eingabefeld für den Wert des neuen Attributs angezeigt wird, falls noch kein Attributwert existiert.
Einblendung zusätzlicher EigenschaftenFalls das konfigurierte Attribut mehrfach vorkommen darf, kann man über diese Option festlegen, dass automatisch ein neuer Platzhalter für einen weiteren Attributwert angezeigt wird.
EinblendungsfilterÜber dieses Skript können die vorhandenen Attribute dieses Typs gefiltert werden, sodass in der Darstellung nur bestimmte von ihnen berücksichtigt werden.
Konfiguration für eingebettete Metaeigenschaften/Konfiguration für MetaeigenschaftenFalls das Attribut Metaeigenschaften enthält, kann an dieser Stelle eine View angebracht werden, um die Darstellung dieser Eigenschaften zu bestimmen. Der einzige Unterschied bei den eingebetteten Metaeigenschaften ist, dass sie eingerückt unter dem Attribut erscheinen.
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.
Skript für BeschriftungAlternativ zu "Beschriftung" kann der dargestellt Attributsname in einem Skript bestimmt werden.
Skript für SichtbarkeitÜber dieses Skript kann festgelegt werden, ob diese Eigenschaft angezeigt werden soll.
Skript für SortierungDieses Skript kann genutzt werden, wenn mehrere Ausprägungen einer Eigenschaft zu einem Objekt existieren.

Für Relationen gibt es noch weitere Optionen:  

Einblendung des RelationszielsPer Default wird als Attributwert der Name des Relationszielsobjekts als Link angezeigt. Über diese Option werden konfigurierte Eigenschaften des Relationsziels angezeigt. Die dafür verwendete View kann über ihren Kontext bestimmt werden, d.h. bei "anwenden in" der entsprechenden View sollte die Eigenschaft-View angegeben werden.
RelationszielansichtDefaultmäßig wird ein Link bzw.ein Relationszieleditor im Bearbeitungsmodus angezeigt. Es kann aber sinnvoll sein, anstelle dessen z.B. eine Drop-Down-Liste mit schon vorgefilterten Relationszielen anzuzeigen. Diese alternativen Ansichten sind an dieser Stelle konfigurierbar.
RelationszielfilterUm den Benutzer in seiner Auswahl eines geeigneten Relationsziels zu unterstützen, kann hier eine Filterungsabfrage angebracht werden.
RelationszieltypfilterFalls mehrere Objekttypen als Ziel einer Relation definiert wurden, kann an dieser Stelle ein Filter auf die angezeigten Typen konfiguriert werden.
Skript für RelationszielbezeichnerPer Default wird der Name des Relationszielobjekts angezeigt. Dies kann per Skript an dieser Stelle angepasst werden.


Im Reiter "Menüs" lassen sich weitere Aktionen zu der Eigenschaft konfigurieren, und im Reiter "Styles" können bestimmte Darstellungsoptionen ausgewählt werden. Der "KB"-Reiter enthält Optionen, die nur für den Knowledge-Builder gelten und im Web-Frontend keine Anwendung finden. Über den "Kontext"-Reiter lässt sich nachvollziehen, in welchen Views die Eigenschaft-View angewendet wird.

3.4.6 Edit

Eine Edit-View dient zur Pflege von Attributen oder Relationen.

Dabei werden alle Kind-Konfigurationen vom Typ Eigenschaften als Formularfelder angezeigt. Eine Edit-View darf genau eine Kind-View enthalten. Dies sollte eine Eigenschaften Konfiguration sein. Über eine Gruppen-View ist aber auch möglich mehrere Eigenschaften-Views zu verwenden. Änderungen können über einen Speicherbutton mit dem Wissensnetz synchronisiert werden.

Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung der Edit-View: 

Editiermodus umschaltbar Über dieses Option ist der Formularmodus "Umschaltbar". D.h. Eigenschaften werden zuerst im nur lesen Modus angezeigt. Über einen Umschaltbutton kann dann in den Pflegemodus geschaltet werden.
Nur benutzerdefinierte Schaltflächen Über diese Option können eigene Buttons zum Umschalten und Speichern konfiguriert werden. Hierfür muss ein Menü mit Aktionen konfiguriert werden.



 Benutzerdefinierte Schaltflächen

Ist die Option Nur benutzerdefinierte Schaltflächen aktiv, können eigene Buttons zum Umschalten und Speichern konfiguriert werden. Dabei muss an der jeweiligen Aktion eine eigene ActionResponse mit definierten Followups konfiguriert werden:

Umschalten Lesemodus


Umschalten Pflegemodus


 Beispiel für einen eigenen Speichern Button:

function actionResponse(element, context, actionResult) {
    var actionResponse = new $k.ActionResponse();
    return actionResponse;

 Ab 5.2 ist dies für den Speichern-Button nicht mehr nötig. Dann genügt es, eine Update-Aktion zu konfigurieren und bei "ausführen in View" die Edit-View auszuwählen, in der das Speichern erfolgen soll.

3.4.7 Table

Bei einer Tabellen-View handelt es sich um die Darstellungskonfiguration einer Liste von Objekten. Eine Tabellen-View kann unabhängig an verschiedenen Stellen verwendet werden und ihr Inhalt ist vom Kontext abhängig.

Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung und des Verhaltens.

Aktion (Auswahl)Die hier konfigurierte Aktion wird ausgeführt, wenn eine Zeile im Frontend ausgewählt wird (z.B. per Klick).
Anzahl Zeilen (Page size)Hier wird die maximale Anzahl Zeilen angegeben, die auf einer Seite angezeigt werden.
BeschriftungEine Tabelle wird in den Frontends mit Überschrift dargestellt. Als default wird der Name aus dem Kontext erzeugt. Über "Beschriftung" kann ein anderer Wert als Name angezeigt werden.
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.
Ohne SpaltenfilterHier kann bestimmt werden, ob zwischen Tabellen-Kopfleiste und Tabelleninhalt ein Spaltenfilter dargestellt werden soll. Anhand des Spaltenfilters kann für die jeweilige Spalte das Suchergebnis durch Eingabe eines Begriffs gefiltert werden.
Skript für BeschriftungAlternativ zu "Beschriftung" kann der dargestellt Attributsname in einem Skript bestimmt werden.
Tabelle vonHier wird die Ansicht referenziert, deren Ergebnisse in der vorliegenden Tabelle angezeigt werden. Dies kann eine Suche, eine Suchergebnis-Ansicht oder wieder eine Tabelle sein.

Im Reiter "Sortierung" kann das Sortierverhalten anhand der Spalten konfiguriert werden.

Der Reiter "Tabelle" enthält zwei Unterpunkte: "Menüs" und "Styles". Im Reiter "Menüs" lassen sich weitere Aktionen zu der Tabelle konfigurieren, und im Reiter "Styles" können bestimmte Darstellungsoptionen, die sich auf die gesamte Tabelle auswirken ausgewählt werden. Im nächsten Reiter, "Spalten" > "Styles" werden dann entsprechend die Darstellungsoptionen für Spalten ausgewählt.

Die Spalten der Tabelle werden durch Subkonfigurationen definiert, siehe nächster Abschnitt. Die Reihenfolge der Spalten kann in der Baumansicht auf der linken Seite mittels der Pfeil-Buttons darüber verändert werden.

Die Spalten-View repräsentiert die Konfiguration einer gesamten Spalte. Hier lässt sich Einfluss auf die Darstellung und das Verhalten (z.B. Filterung) nehmen.

Der Inhalt der Zellen ("Spaltenelement") wird wiederum durch eine Subkonfiguration festgelegt, wie im folgenden Abschnitt beschrieben.

BeschriftungAngezeigter Name der Spalte
Breite der Spalte (%)Breite der Spalte in Prozent, bezogen auf die Breite der Tabelle
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.
Nicht anzeigenHiermit wird eine Spalte ausgeblendet. Sie wird trotzdem im Hintergrund berechnet und kann z.B. für die Sortierung verwendet werden.
Nicht sortierbarIn der Standardeinstellung lassen sich Spalten mit Klick auf den Header sortieren. Hier lässt sich diese Funktionalität deaktivieren.
Skript für BeschriftungAlternativ zu "Beschriftung" kann der dargestellt Attributsname in einem Skript bestimmt werden.
Skript für Vorverarbeitung von EingabefeldernDer Text, der im Spaltenfilter angegeben wurde, lässt sich hier mittels Skript beeinflussen.
Standard-OperatorHier kann aus den möglichen Filter-Operatoren der Default ausgewählt. Wenn hier nichts konfiguriert ist, wird der erste aus der Liste gewählt.
SuchtextHier lässt sich der Text für den Spaltenfilter im Voraus festlegen.


Die Spaltenelement Sub-Konfiguration bestimmt den Inhalt der Spalte. Der Inhalt wird typischerweise von den Elementen abgeleitet, auf die sich die Tabelle bezieht.


EigenschaftDie in dieser Spalte anzuzeigende Eigenschaft des Elements
Strukturabfrage-BausteinAlternativ zu "Eigenschaft" kann der anzuzeigende Inhalt auch über eine Strukturabfrage bestimmt werden
SkriptAlternativ zu den ersten beiden Möglichkeiten, kann der anzuzeigende Inhalt auch über ein Skript vom Element abgeleitet werden
Nicht anzeigenHiermit wird das Spaltenelement ausgeblendet. Es wird trotzdem im Hintergrund berechnet und kann z.B. für die Sortierung oder Filterung verwendet werden.
HervorhebungHier kann ausgewählt werden, ob der Inhalt des Spaltenelements durch Unterstreichung hervorgehoben werden soll.
Hits verwendenAlternativ zu "Beschriftung" kann der dargestellte Attributname in einem Skript bestimmt werden.
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.


3.4.8 Search

Mit einer Suche-View lassen sich Suchseiten erstellen, auf denen die Suchabfrage und die -ergebnisse gleichzeitig angezeigt werden. Sollte die Suche keine oder nur optionale Parameter haben, wird die Suche sofort ausgeführt und die Ergebnisse direkt angezeigt. Gibt es obligatorische Parameter, wird die Suche erst nach einer Benutzereingabe ausgeführt.

Soll z.B. nur ein Suchschlitz im Titel einer Seite angezeigt werden und die Ergebnisse dieser Suche dann weiter unten auf der Seite, ist dies über die Konfiguration von Suchfeldansicht und Suchergebnisansicht möglich. Außerdem kann man auch Suchfacetten anlegen. Diese drei Konfigurationen werden in den Unterabschnitten dieses Kapitels näher beschrieben.


Für eine einfache Suchseite legt man im Knowledge-Builder eine Suche-View an.

Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung der Suche:

Abfrage     Hier wird die Suche konfiguriert, die beim Ausführen der Suche ausgeführt werden soll.
ParameternameDer Name eines Suchparameters. Alle Parameter, die in der Suche konfiguriert wurden, müssen an dieser Stelle auch konfiguriert werden, damit es nicht zu Fehlern in der Suche kommt.

Falls der Parameterwert über ein Skript ermittelt werden soll, muss dieses hier konfiguriert werden.


Hier wird angegeben, wie der Parameterwert bestimmt werden soll.

  • "Skript" (Wertermittlung per Skript)
  • "Skript, überschreibbar" (Wertermittlung per Skript, wird aber über Benutzereingaben im Frontend überschrieben
  • "Benutzereingabe (optional)" (Der Parameterwert wird aus der Benutzereingabe übernommen, falls er gesetzt wird. Er wird dem Nutzer als optional im Frontend angezeigt. Bitte beachten, dass die Suche dann auch so konfiguriert ist, dass dieser Parameter nicht gesetzt sein muss)
  • "Benutzereingabe (obligatorisch)" (Der Nutzer muss im Frontend einen Wert eingeben, ansonsten wird die Suche nicht ausgeführt)
  • "Benutzereingabe (deaktiviert, wenn leer)" (Der Parameter wird für die Suche gesetzt, wenn es eine Benutzereingabe gab. Ansonsten wird der Parameter beim Ausführen der Suche deaktiviert)
TypDatentyp des Parameters
BeschriftungDie Bezeichnung des Parameters im Frontend
ReihenfolgeDie Reihenfolge der Parameter, wie sie im Frontend angezeigt werden
BeschriftungDer hier eingegebene Wert erscheint als Überschrift der Suche
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.
Skript für BeschriftungAlternativ zu "Beschriftung" kann der Titel der Gruppe in einem Skript bestimmt werden.
Skript für SichtbarkeitÜber dieses Skript kann festgelegt werden, ob die Gruppe angezeigt werden soll.
Skript für TabellenkonfigurationAlternativ zu "Tabelle" kann an dieser Stelle über ein Skript die dargestellte Tabelle bestimmt werden.
Tabelle     Die Suchergebnisse werden im Frontend in der Tabellenkonfiguration angezeigt, die hier konfiguriert wird.

Im Reiter"Menüs" lassen sich Aktionen zu der Suche konfigurieren, und im Reiter "Styles" können bestimmte Darstellungsoptionen ausgewählt werden. Der "KB"-Reiter enthält Optionen, die nur für den Knowledge-Builder gelten und im Web-Frontend keine Anwendung finden. Über den "Kontext"-Reiter lässt sich konfigurieren, für welche Objekttypen die Suche-View verwendet werden soll und in welchen Anwendungskontexten. Search field view

 Eine Suchfeld-Ansicht wird verwendet, wenn z.B. nur ein Suchschlitz an einer Stelle angezeigt werden soll, nicht aber die Suchergebnisse. Die Konfiguration erfolgt wie bei der Suche-View, jedoch ohne die Konfiguration zur Ergebnisdarstellung. 

Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung des Suchfeldes:

Abfrage     Hier wird die Suche konfiguriert, die beim Ausführen der Suche ausgeführt werden soll.
ParameternameDer Name eines Suchparameters. Alle Parameter, die in der Suche konfiguriert wurden, müssen an dieser Stelle auch konfiguriert werden, damit es nicht zu Fehlern in der Suche kommt.

Falls der Parameterwert über ein Skript ermittelt werden soll, muss dieses hier konfiguriert werden.


Hier wird angegeben, wie der Parameterwert bestimmt werden soll.

  • "Skript" (Wertermittlung per Skript)
  • "Skript, überschreibbar" (Wertermittlung per Skript, wird aber über Benutzereingaben im Frontend überschrieben
  • "Benutzereingabe (optional)" (Der Parameterwert wird aus der Benutzereingabe übernommen, falls er gesetzt wird. Er wird dem Nutzer als optional im Frontend angezeigt. Bitte beachten, dass die Suche dann auch so konfiguriert ist, dass dieser Parameter nicht gesetzt sein muss)
  • "Benutzereingabe (obligatorisch)" (Der Nutzer muss im Frontend einen Wert eingeben, ansonsten wird die Suche nicht ausgeführt)
  • "Benutzereingabe (deaktiviert, wenn leer)" (Der Parameter wird für die Suche gesetzt, wenn es eine Benutzereingabe gab. Ansonsten wird der Parameter beim Ausführen der Suche deaktiviert)
TypDatentyp des Parameters
BeschriftungDie Bezeichnung des Parameters im Frontend
ReihenfolgeDie Reihenfolge der Parameter, wie sie im Frontend angezeigt werden
BeschriftungDer hier eingegebene Wert erscheint als Überschrift der Suche
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.
Skript für BeschriftungAlternativ zu "Beschriftung" kann der Titel der Gruppe in einem Skript bestimmt werden.

Im Reiter"Menüs" lassen sich Aktionen zur Suchfeld-Ansicht konfigurieren, und im Reiter "Styles" können bestimmte Darstellungsoptionen ausgewählt werden. Der "KB"-Reiter enthält Optionen, die nur für den Knowledge-Builder gelten und im Web-Frontend keine Anwendung finden. Über den "Kontext"-Reiter lässt sich konfigurieren, für welche Objekttypen die Suchfeldansicht verwendet werden soll und in welchen Anwendungskontexten.

Suchfeld-Ansichten lassen sich mit Suchergebnis-Ansichten und Facetten-Ansichten kombinieren. Damit nach einer Suche aus einer Suchfeld-Ansicht die Ergebnisse in einer Suchergebnis- oder Facetten-Ansicht sichtbar werden, müssen die Aktionen entsprechend konfiguriert werden. Die einfachste Option ist, auf dem Panel, das die Suchfeld-Ansicht enthält, zu konfigurieren, dass die Aktionen in einem Panel ausgeführt werden sollen, das eine Facetten-Ansicht bzw. eine Suchergebnis-Ansicht enthält.

Möchte man alle drei Ansichten miteinander verbinden, aktiviert man die Aktionen einer Suchfeld-Ansicht wie oben beschrieben in einem Panel, das eine Suchergebnis- oder Facetten-Ansicht enthält und auf diesem Panel konfiguriert man, dass das andere Ergebnis-Ansichtspanel von diesem Panel beeinflusst wird. Search result view

Eine Suchergebnis-Ansicht wird dann verwendet, wenn in einer View nur die Ergebnisse einer Suche angezeigt werden sollen und nicht die Suchparameter. Falls die konfigurierte Suche parameterlos ist, reicht die Konfiguration einer Suchergebnis-Ansicht. Gibt es Parameter, sollte die Suchergebnis-Ansicht mit einer Suchfeld-Ansicht verknüpft werden.

Sie kann im Knowledge-Builder angelegt werden.

Im Reiter "Konfiguration" gibt es Möglichkeiten zur Bestimmung der allgemeinen Darstellung der Suche:

Abfrage     Hier wird die Suche konfiguriert, die beim Ausführen der Suche ausgeführt werden soll.
BeschriftungDer hier eingegebene Wert erscheint als Überschrift der Suche
KonfigurationsnameÜber den Konfigurationsnamen können Views und Panels identifiziert werden.
Skript für BeschriftungAlternativ zu "Beschriftung" kann der Titel der Gruppe in einem Skript bestimmt werden.
Skript für TabellenkonfigurationAlternativ zu "Tabelle" kann an dieser Stelle über ein Skript die dargestellte Tabelle bestimmt werden.
Tabelle     Die Suchergebnisse werden im Frontend in der Tabellenkonfiguration angezeigt, die hier konfiguriert wird.

Im Reiter"Menüs" lassen sich Aktionen zu der Suche konfigurieren, und im Reiter "Styles" können bestimmte Darstellungsoptionen ausgewählt werden. Der "KB"-Reiter enthält Optionen, die nur für den Knowledge-Builder gelten und im Web-Frontend keine Anwendung finden. Über den "Kontext"-Reiter lässt sich konfigurieren, für welche Objekttypen die Suche-View verwendet werden soll und in welchen Anwendungskontexten. Facet view


Eine Facetten-Ansicht lässt sich im Knowledge-Builder konfigurieren.


AbfrageDie Suche, mit der die Ansicht verknüpft ist. Wenn die Ansicht mit anderen verwandten Ansichten wie z.B. der Suchfeld-Ansicht verknüpft ist, muss hier keine Abfrage konfiguriert werden. 
BeschriftungDer Titel, der über der Facetten-Ansicht im Frontend erscheinen soll.
KonfigurationsnameÜber Konfigurationsnamen lassen sich Views und Panels identifizieren
Skript für BeschriftungAlternativ zu einer festen Beschriftung kann der Titel auch über ein Skript gesetzt werden.

Um Facetten zu konfigurieren, werden Facette-Views erstellt und an die Facetten-Ansicht gehängt. Diese können mehrfach hierarchisch angeordnet werden.

Abfrage zur Elterntermermittlung 
Abfrage zur TermermittlungStrukturabfrage, über die die Facette gebildet wird. Die Struktur einer solchen Abfrage wird im nächsten Abschnitt erklärt.
Ausblenden ab Anzahl von TermenDie Facette wird ausgeblendet, wenn die der Facette zugrundeliegenden Suchergebnisse diese Anzahl übersteigen.
BeschriftungDer Titel der Facette
Kindterme initial anzeigenFalls die Facette hierarchisch aufgebaut ist, kann über diese Option definiert werden, ob die Unter-Facetten initial angezeigt werden sollen.
KonfigurationsnameViews und Panels können über einen Konfigurationsnamen identifiziert werden.
Leere Terme anzeigenFalls zu der Facette keine Ergebnisse gefunden werden, wird sie per Default ausgeblendet. Über diese Option wird sie trotzdem angezeigt.
Maximale Anzahl von TermenBeschreibt die maximale Anzahl der Terme, die die Facette haben kann.
Term-Anzahl nicht anzeigenIm Frontend wird hinter dem Facettentitel die Anzahl der gefundenen Terme angezeigt. Über diese Option kann das deaktiviert werden.
Term-OperatorAn dieser Stelle kann konfiguriert werden, wie die Terme miteinander verknüpft werden. Möglich ist eine "Und" oder eine "Oder"-Verknüpfung.
TermartDynamisch oder statisch.
Terme absteigend sortierenPer Default werden die für eine Facette gefundenen Terme aufsteigend sortiert. Über diese Option dreht sich die Sortierreihenfolge.
Terme nach Anzahl sortierenDie Facetten-Terme werden grundsätzlich alphabetisch sortiert, über diese Option werden sie nach der gefundenen Anzahl Ergebnisse sortiert.



 Die für die Termermittlung genutzte Strukturabfrage muss sich an ein paar Vorgaben halten, damit eine Facette ermittelt werden kann.

Im Prinzip ist alles möglich, was sonst auch in Strukturabfragen möglich ist. Wichtig ist nur, dass die Ausprägungen einer Facette über den Bezeichner "term" ermittelt werden. Es ist auch möglich, dass der Bezeichner mehrfach in einer Strukturabfrage verwendet wird. Dann wird er über den bei "Term-Operator" definierten Wert verknüpft.

3.4.9 Graph configuration

Eine Graph-Konfiguration dient dazu, Objekte in einem Graphen darstellen zu können. Eine erste Einführung zur Nutzung des Graphen im Knowledge-Builder ist unter Knowledge-Builder > Grundlagen > Graph-Editor zu finden.

Details zu den Einstellungsmöglichkeiten der verschiedenen Views, die für das Einbinden eines Graphen in das Frontend benötigt werden, sind unter Knowledge-Builder > View-Konfiguration > View-Konfigurationselemente > Graph erläutert.

Es wird eine Graph-View sowie eine Graph-Konfigurations-View zur Darstellung benötigt.
Das Panel, in dem der Graph angezeigt werden soll, erhält eine Graph-View ("V:Graph"). Die Angabe des Kontextelements ist optional und wird beim Start der Applikation im Graphen angezeigt.

Die Graph-View muss nur eine Verknüpfung zur Graph-Konfiguration enthalten. Optional, aber meist vorhanden, ist die Einstellung der Größe des Graph-Feldes über die Felder Breite und Höhe, sowie die Strukturabfrage für Startelemente.


In der Regel sieht die Strukturabfrage so aus:


Über die Angabe der Anzahl der Wiederholungen an der Benutzerrelation kann festgelegt werden, wie viele Schritte vom Ausgangsknoten aus angezeigt werden sollen, wenn ein Objekt angezeigt wird. (Achtung: Kann zu langen Rechenzeiten führen!)

Die Graph-View sorgt dafür, dass der Graph insgesamt angezeigt wird. Um festzulegen, welche Knoten und Relationen angezeigt werden sollen, wird die Graph-Konfiguration verwendet.

Für jeden Typen, dessen Objekte (oder auch Typen) angezeigt werden sollen, muss eine Knotenkategorie angelegt werden. Diese werden standardmäßig als Legende im Graphen angezeigt.

Im Graphen werden Objekte angezeigt, die direkt am Typen oder an dessen Untertypen hängen. Über An konkreten Typ anpassen werden die Untertypen gesondert in der Legende angezeigt, ohne das diese einzeln als Knotenkategorien angelegt werden müssen.

Um Typen statt Objekte anzuzeigen, muss im Reiter Kontext der Haken bei anwenden auf Untertypen gesetzt sein.

Im Reiter Knoten kann unter Menüs ein Satellitenmenü vergeben werden, um weiter im Graphen zu arbeiten (siehe Knowledge-Builder > View-Konfiguration > Aktionen > Aktionen für den Viewconfiguration-Mapper > NN-Expand/NN-Hide/NN-Pin Aktionen).



Um die Relationen zwischen den Knoten anzuzeigen, wird eine Verknüpfung unter jeder Knotenkategorie benötigt. Hier wird festgelegt, welche Relationen für diesen Typen angezeigt werden sollen. Die Relationen können über eine Abfrage, ein Skript oder über die direkte Bestimmung der Relation festgelegt werden. Benutzerrelation kann vergeben werden, wenn alle Relationen (außer Systemrelationen) angezeigt werden sollen.



Für weitere Details siehe Kapitel vcm-plugin-net-navigator

3.4.10 Text

Mit der Text-View kann Text dargestellt werden, der entweder statisch vorgegeben oder durch ein Skript berechnet wird.

Text Statischer, mehrsprachiger Text
Skript für Text Skript zur Berechnung des Textes
Beschriftung Optionale Überschrift
Skript für Beschriftung Optionales Skript zur Berechnung der Überschrift

Beispiel für ein Text-Skript:

function text(element)
    return "Durch ein Skript im Netz " + $k.volume() + " generierter Text";


3.4.11 Image

Stellt ein im Wissensetz gespeichertes Bild dar, das entweder statisch vorgegeben oder durch ein Script berechnet wird.

Bild Statisches Bild
Skript für Bild Skript zur Berechnung des Bildes. Als Rückgabewert wird ein Blob-Attribut erwartet. Dynamische Blobs (z.B. durch Download mittels Http-Client) sind nicht möglich.
Beschriftung Optionale Überschrift
Skript für Beschriftung Optionales Skript zur Berechnung der Überschrift
Breite / Höhe Fest vorgegebene Breite / Höhe des Bildes


3.4.12 Skriptgeneriertes HTML

Dieser View erzeugt per Skript HTML. Sowohl Knowledge-Builder als auch ViewConfigMapper zeigen dies ungefiltert dar, d.h. es ist Aufgabe des Script-Entwicklers, Nutzerinhalte nicht ungefiltert auszugeben. Im Knowledge-Builder sind die Anzeigemöglichkeiten stark eingeschränkt (u.a. kein CSS).

Bei umfangreicherem HTML sollte man besser einen scriptgenerierten View verwenden.

Als Parameter werden an das Skript folgende Argumente übergeben:

element $k.SemanticElement Das Element, in dessen Kontext der View dargestellt wird
document $k.TextDocument Dokument, auf das HTML ausgegeben wird

Zur Ausgabe des HTML kann man zwei Ansätze wählen:

  • Ausgabe des HTML-Quellcodes per Funktion print() des Dokuments
  • Strukturierte Ausgabe per XMLWriter

Das nachfolgende Beispiel zeigt die Verwendung eines XMLWriters, um eine Überschrift auszugeben:

 * Render the semantic element on the document.
 * @function
 * @param {$k.SemanticElement} element The element to render
 * @param {$k.TextDocument} document Target document
function render(element, document)
	var xmlWriter = document.xmlWriter();
3.4.13 Skriptgenerierte View

Ein scriptgenerierte View ermöglicht es, eigene View-Komponenten zu definieren. Die Daten werden durch ein Skript erzeugt und per JSON weitergegeben. Es ist Aufgabe des Frontends, diese darzustellen.


frei wählbarer Berzeichner, der im JSON ausgegeben wird. Dieser wird dazu verwendet, im Frontend die eigene Komponente zuzuordnen.

Skript Liefert die Daten, die im JSON ausgegeben werden.

An das Skript werden zwei Parameter übergeben:

element $k.SemanticElement Das Element, in dessen Kontext der View angezeigt wird
view object Vorbefülltes Objekt mit den Viewdaten. Konfigurationselemente wie z.B. Styles sind hier bereits enthalten.

Nachfolgendes Skript liefert die Daten für einen View, der im Plugin vcm-plugin-timeline enthalten ist:

 * Get json object to modify.
 * @function
 * @this $k.View
 * @param {$k.SemanticElement} element
 * @param {object} json object
 * @returns {object} modified json object

function customizeView (element, view) {
  view.options = {
    layout: 'vertical'
  view.events = $k.Registry.type('election').allInstances().map(function (election) {
    return {
      elementId: election.idString(),
      name: election.name(),
      date: election.attributeValue('electionDate').toString()
  return view
3.5 Plugins
3.5.1 vcm-plugin-calendar

Mit dem vcm-plugin-calendar können Daten in einem Kalender dargestellt werden.

Um die Daten als Kalender anzuzeigen, muss an der Tabellenkonfiguration ein Style-Element hinzugefügt werden, das den renderMode calendar enthält. Der Wert unter Anzahl Zeilen (Page Size) gibt an, wieviele Kalendereinträge maximal pro Ansicht (in diesem Fall pro Monat) angezeigt werden können. Die Tabelle muss die folgenden Spalten haben:

  • start: Ein Datum an dem der Kalendereintrag startet.
  • end: Enddatum des Eintrags (optional)
  • title: Der Titel des Eintrags
  • allDay: Boolean-Wert der angibt, ob der Eintrag für den gesamten Tag gilt (optional)
  • Weitere Möglichkeiten für Spalten sind in der fullcalendar.io Event_Object Dokumentation zu finden.

Es kann auch eine Auswahlaktion auf die Spalten der Tabelle konfiguriert werden. Diese wird dann beim Klick auf einen Kalendereintrag ausgeführt.

Außerdem lassen sich mit dem Style Attribut vcmPluginCalendarOptions weitere Konfigurationen vornehmen.

Weiterführende Informationen zum Plugin sind unter fullcalendar.io abrufbar.

3.5.2 vcm-plugin-chart

Das vcm-plugin-chart dient dazu, Daten aus einer Tabellenkonfiguration in Form eines Diagramms im Web-Frontend anzeigen zu können. Es stehen verschiedene Diagrammtypen zur Verfügung: Linien-, Balken-, Torten-, Ring- und Radardiagramme.

Beispiel eines Balkendiagramms:

Beispiel eines Tortendiagramms: Konfiguration

Das vcm-plugin-chart dient dazu, Daten aus einer Tabellenkonfiguration in Form eines Diagramms im Web-Frontend anzeigen zu können. Hierbei muss ein Style angelegt werden, der als renderMode die Option "chart" hat.

Wird beispielsweise in der zugrundeliegenden Tabellenkonfiguration eine Aktion mit der Option "Graphisch darstellen" angefügt, so kann durch Klick auf Teile des Diagramms der jeweilige Datensatz zussätzlich im Net-Navigtor angezeigt werden.

Für den vcm-plugin-chart gibt es mehrere Optionen zur Darstellungsanpassung:

  • vcmPluginChartDataColumns
  • vcmPluginChartDataMode
  • vcmPluginChartHeight:
    Angabe der Diagrammhöhe in Pixel
  • vcmPluginChartLabelColumn
  • vcmPluginChartOptions:
    JavaScript für Anpassung von Legenden-Anzeige und Skalierung von Achsen
  • vcmPluginChartType:
    Angabe zu Diagrammtyp: bar, doughnut, line, pie, polar, radar
  • vcmPluginChartWidth:
    Angabe der Diagrammbreite in Pixel
3.5.3 vcm-plugin-html-editor


Das vcm-plugin-html-editor ermöglicht es, HTML-formatierten Text zu bearbeiten. Es verwendet hierfür den WYSIWYG-Editor summernote.



Für die View-Konfiguration des HTML-Editors wird eine Grupe benötigt: Im Reiter "Kontext" wird hierzu unter "anwenden auf" der Eintrag "vcm-plugin-html-editor" benötigt.

Nach dem der Konfiguration der Gruppe muss eine Eigenschafts-Konfiguration angelegt werden. Diese ist mit einem Style zu versehen, welchen den renderMode "htmleditor" enthält:

Die Eigenschafts-Konfiguration benötigt darüber hinaus ein Zeichenketten-Attribut, welches den Text enthalten soll.

Damit der Inhalt vom Web-Frontend aus bearbeitbar ist, muss ein zusätzlicher Style mit dem renderMode "edit" an der übergeordneten Gruppe der Eigenschafts-Konfiguration angelegt werden. Alternativ kann hierzu eine übergeordnete Edit-Konfiguration angelegt werden.

3.5.4 vcm-plugin-markdown

Das vcm-plugin-markdown ermöglicht die HTML Ausgabe von Markdown Texten.

Es lässt sich verwenden indem man einen Style mit dem renderMode markdown an eines der folgenden Konfigurationselemente anbringt:

  • Statischer Text : Hierbei wird die Viewconfig-Eigenschaft Text des Konfigurationselements als Markdown interpretiert.

    Für die Anwendung des Plugins muss im Reiter "Style" der RenderMode mit der Bezeichnung "markdown" eingegeben werden:

  • Eigenschaft : hierbei wird der Wert des Attributes als Markdown interpretiert.

    Die Konfiguration der View für das Zeichenketten-Attribut "Markdown" findet mithilfe einer Eigenschafts-View statt:

    Die Eigenschaft erhält wie ein Text-Objekt gleichermaßen den RenderMode "markdown".

Nach dem Rendern erhält der Text im Web-Frontend die optischen Hervorhebungen:

Weitere Konfiguration des Plugins kann über das Style-Attribut vcmPluginMarkdownOptions vorgenommen werden.

Das Plugin verwendet das Modul markdown-it

3.5.5 vcm-plugin-net-navigator

 Das vcm-plugin-net-navigator visualisiert Elemente in einer graphartigen Ansicht. Konfiguration

Das Plugin kann über Styles konfiguriert werden. 

Styles der View

Style Beschreibung
vcmPluginNetNavigatorOptions Ein JSON Objekt für die View Optionen. Details s. unten
extra Alternativ zu vcmPluginNetNavigatorOptions


Option Beschreibung
vcmPluginNetNavigatorOptions.categories.hideLabel Ein-/Ausblenden der Kategorielabels
vcmPluginNetNavigatorOptions.categories.embeddedActions Konfiguration wo die Aktionen angezeigt werden sollen. Bei true werden sie neben den Kategorien angezeigt
vcmPluginNetNavigatorOptions.categories.compactActions Aktionen in einem Menü zusammenfassen
vcmPluginNetNavigatorOptions.history.enabled Aktiviert/Deaktiviert die Navigationshistorie
vcmPluginNetNavigatorOptions.enableEditing Aktiviert-/Deaktiviert die Möglichkeit Elemente im Graph neu zu verknüpfen
vcmPluginNetNavigatorOptions.nnOptions Optionen für die Net-Navigator Komponente
vcmPluginNetNavigatorOptions.nnOptions.overload.maxExpandNodes Anzahl der gleichzeitig zu öffnenden Knoten, bevor ein Rückfragedialog zu den zu öffnenden Relationen erscheint. Default-Wert ist 5.

Styles der Knoten

extra Ein JSON Objekt für die Knoten Optionen. Details s. unten

Optionen der Knoten

color Überschreibt die Hintergrundfarbe des Knotens
label Überschreibt das Label des Knotens
icon Überschreibt das Icon des Knotens

Styles der Kanten

extra Ein JSON Objekt für die Kanten Optionen. Details s. unten

Optionen der Kanten

color Überschreibt die Hintergrundfarbe der Kante
label Überschreibt das Label der Kante Actions

Knoten und Relationen können um Aktionen erweitert werden. Diese werden Kreisförmig um einen Knoten bzw. die Relation angeordnet. 

Aktionen werden in der Graph-Konfiguration innerhalb von einer Knotenkategorie bzw. Verknüpfung konfiguriert.

Vorkonfigurierte Aktionen 

NN-ExpandÜber ein kleines Plus Symbol können benachtbarte Knoten (für die es eine Konfiguration gibt) angezeigt werden
NN-HideAusblenden eines Knotens
NN-PinFestpinnen eines Knotens

Eigene Aktionen

Für die Darstellung wird immer ein Symbolbild benötigt Followups

Die Graphansicht reagiert auf folgende Followups:

graph-show{elementId: ["ID123_456"]}Zeigt die Elemente im Graph an. Bereits angezeigte Elemente werden ausgeblendet
graph-join{elementId: ["ID123_456"]}Fügt die Elemente dem Graph hinzu. Bereits angezeigte Elemenete bleiben erhalten
graph-hide{elementId: ["ID123_456"]}Entfernt Elemente aus dem Graph
graph-back Geht in der Graph-Historie einen Schritt zurück
graph-forward Geht in der Graph-Historie einen Schritt vorwärts
graph-reload Aktualisiert die Elemente im Graph

 Beispiel ActionResponse Skript um den Wurzelbegriff der Graphansicht hinzuzufügen:

function actionResponse (element, context, actionResult) {
  var actionResponse = new $k.ActionResponse()
    elementId: [$k.rootType().idString()]
  return actionResponse
4 k-infinity services
4.1 Overview
4.1.1 Command line parameters

 Falls es zu einem Aufrufparameter auch einen Eintrag der Ini-Datei gibt, hat der der Aufrufparameter höhere Priorität.

-inifile <Dateiname>, -ini < Dateiname >

 Name der Ini-Datei, die statt dem Standard-Ini-Datei verwendet wird.


4.1.2 Configuration file

Einige Einstellungen können über eine Konfigurationsdatei (*.ini) festgelegt werden. Der Aufbau der Datei sieht folgendermaßen aus:


Im folgenden sind Konfigurationen aufgeführt, die für jeden Dienst verwendet werden können. Für dienstspezifische Einstellungen siehe den Abschitt "Konfigurationsdatei" des entsprechenden Dienstes.


loglevel = <LogLevel>

Konfiguriert, welche Meldungen im Log erscheinen sollen: 

  • FATAL ERROR: Nur kritische Fehlermeldungen
  • ERROR: Nur Fehlermeldungen
  • WARNING: Nur Warnungen und Fehlermeldungen
  • NORMAL (Standardwert): Alle Meldungen außer Debug-Ausgaben
  • NOTIFY: Alle Meldungen inklusive einiger Debug-Ausgaben
  • DEBUG: Alle Meldungen inklusive aller Debug-Ausgaben
debug = true/false

Veraltet. Setzt den Log-Level bei true auf DEBUG, bei false auf NORMAL. Wird nur noch ausgewertet, wenn logLevel nicht gesetzt wird

nolog = true/false

Veraltet. Entspricht bei true einem logtargets=null. Wird nur noch ausgewertet, wenn logtargets nicht gesetzt wird

channels = <Channel1> [,<Channel2>,...]

Namen von Channelfiltern. Mit Hilfe der Channelfilter werden nur Log-Meldungen ausgegeben, die zu den angegebenen Channelfiltern gehören. Der Name eines Channelfilters deutet darauf hin, zu welchem Themengebiet die Log-Ausgaben gehören. Welche Channelfilter möglich sind, erfährt man in der Kommandozeile mit Hilfe des Parameters -availableChannels.

channelLevels = <Channel1>:<Level1> [,<Channel2>:<Level2>,...]

Gezielte Konfiguration des Loglevels für den jeweiligen Channel.

logTargets = <Name1> [,<Name2>,...]

Namen von Log-Targets. Für die Konfiguration siehe Abschnitt „Log-Targets“.

logprefix = <Prefix1> [, <Prefix2>,... ]

Zusätzliche Daten, die bei jeder Log-Ausgabe hinzugefügt werden:

  • $pid$ : Prozess-ID der Anwendung
  • $proc$ : ID des aktuellen Smalltalk-Threads
  • $alloc$ : belegter Speicher der VM (in Megabyte)
  • $free$ : Freier Speicher der VM (in Megabyte)
  • $incGC$ : Status inkrementelle GCs
  • $os$ : Information über OS
  • $cmd$ : Kommandozeile
  • $build$ : Build-Version
  • $coast$ : COAST-Version

Bei einem Präfix, der nicht in dieser Liste enthalten ist, wird der Präfix unverändert ausgegeben.

logTimestampFormat = <FormatString>

Formatierungsangabe für den Timestamp des Log-Eintrags, z.B. "hh:mm:ss".

exceptionLogSize = <Integer>

Setzt die maximale Größe des bei einer Fehlermeldung mitgelieferten StackTrace.


Über Log-Targets lassen sich verschiedene Ziele für das Logging festlegen, für die sich jeweils Log-Level, Channels, Formatierung und mehr konfigurieren lassen. Für jeden angegebenen Namen aus der logtargets-Liste muss eine Konfiguration im Abschnitt [<Konfigurationsname>] angegeben werden:


type=stderr format=json loglevel= ERROR

konfiguriert zum Beispiel eine Ausgabe aller Fehlermeldungen im JSON-Format auf dem Standard-Error-Stream.

Eine Ausnahme stellt das Log-Target null da: bei eine konfiguration von logtargets=null muss kein Konfigurationsabschnitt erstellt werden. Fehlt dieser, so ist dies gleichbedeutend mit folgender Konfiguration



Es ist jedoch möglich, null als bezeichner für eine beliebige Log-Target Konfiguration zu verwenden.

Grundsätzlich lassen sich genau wie in der allgemeinen Konfiguration loglevel, debug, channels, channelLevels, logprefix und logTimestampFormat festlegen (siehe oben). Die Konfiguration am Log-Target hat immer Vorrang, wenn keine angegeben ist wird jedoch auf die allgemeine Konfiguration zurückgegriffen.

Zusätzlich gibt es noch einige weitere Konfigurationsmöglichkeiten:

format = <Format>

legt das Ausgabeformat fest. Mögliche Werte sind:

  • plain: Die Standardformatierung in möglichst menschenlesbarer Form
  • json: einzeilige Ausgabe als JSON-String, vorallem für Maschinenverarbeitung
type = <Zieltyp>

legt den Typ der Ausgabe fest. Diese Konfiguration MUSS angegeben werden, sonst wird das Log-Target ignoriert. Im folgenden sind Beschreibung und weitere Konfigurationsmöglichkeit der verschiedenen Typen angegeben:


Ausgabe in eine Log-Datei. 

file = <Dateiname>

legt den Dateinamen der Ziel-Datei fest.

maxLogSize = <size>

Die maximale Größe des Logfiles, ab der die alte Logdatei archiviert wird und eine neue angebrochen wird. Bei Werten kleiner als 1024 wird die Angabe als in MB verstanden.

maxBacklogFiles = <amount>

Die maximale Anzahl an archivierten Logdateien. Beim Anbruch einer neuen wird die letzte gelöscht.


Ausgabe in das Transcript, kann außerdem in eine Log-Datei umgeleitet werden und akzeptiert daher die gleichen Konfigurationen wie file.


Ausgabe auf den Standard-Out-Stream.


Ausgabe auf den Standard-Error-Stream.


Versendet die Log-Ausgabe per Mail.

type = mail
loglevel =  ERROR
sender = mail@example.org
recipient = rec@example.org
smtpHost = stmp.example.org
;Port des Mail-Servers:
smptPort = 465
;Aktiviert bei true die gesicherte Verbindung (TLS/SSL).
;Bei true muss username und password gesetzt sein.
tls = true    
username = mail@example.org
password = 12345abc
;Anzahl der Versuche, die Mail bei einem Fehlschlag erneut zu senden:
retries = 3
;Wartezeit zwischen den Versuche in Sekunden:
retryDelay = 5


Wie mail, allerdings werden Ausgaben mit niedrigem Log-Level zunächst angesammelt und erst per Mail versendet, wenn ein Eintrag mit hohem Level geloggt wird.

mailSendLevel = <LogLevel>

setzt das Log-Level, ab dem die Mail gesendet wird.


Ausgabe als UDP-Datagramm an einen Syslog-Client. 

format = <Format>

Anders als bei anderen Log-Targets werden json und plain als Formatierung nicht unterstützt, stattdessen kann hier die Syslog-Version angegeben werden:

  • rfc5424: Formatiert die Nachricht nach RFC 5424. Die meisten Daten werden strukturiert im Structured-Data-Feld hinterlegt. Nur die eigentliche Log-Message wird im Message-Feld übertragen.
  • rfc3164: Formatiert die Nachricht nach RFC 3164. Da dieser Standard kein Structured-Data-Feld hat, werden die entsprechenden Daten in der gleichen Formatierung an den Anfang des Message-Felds gestellt. Achtung: Der Zeitstempel ist standardkonform in Lokalzeit des sendenden Rechners angegeben.
facility = <Integer>

Die Facility als Ganzzahl. Für detailierte Informationen siehe https://tools.ietf.org/html/rfc5424#section-6.2.1

targetHostname = <Hostname>

Der Hostname des Zielsystems. Falls nicht angegeben wird localhost verwendet.

targetPort = <Integer>

Der Port, an den gesendet werden soll. Falls nicht angegeben, wird der Syslog-Standard-Port 514 verwendet.

hostname = <Hostname>

Der Hostname des Senders. Falls nicht angegeben, wird des Hostname des Systems ausgelesen.

appname = <Name>

Name der sendenden Anwendung. Falls nicht angegeben, wird der Name der EXE verwendet.

maxMessageSize = <Integer>

Die maximale Nachrichtengröße in Bytes. Falls nicht angegeben, wird die maximale Größe für UDP verwendet. Zum Kürzen der Nachricht wird zunächst stückweise Structured Data entfernt und im Notfall die Message abgeschnitten. Die Nachricht ist auch nach der Kürzung in validem Syslog-Format. 


Zum Unterdrücken der Logausgaben. Es werden keinerlei Optionen ausgelesen.

4.2 Mediator
4.2.1 Overview

Der i-views-Server sorgt für konsistente und persistente Datenhaltung und für die Aktualität der Daten auf den angeschlossenen i-views-Clients.

Die Datenhaltung erfolgt in einer objektorientierten Datenbank, die durch ein optimistisches Transaktionssystem kooperatives Arbeiten auf dem Wissensnetz ermöglicht.

In seiner Funktion als Kommunikationszentrale sorgt der i-views-Server für die Synchronisation von Clients und Services. Als Basismechanismus stellt er hierfür einen geteilten Objektraum und aktive Updates zur Verfügung.

Technische Daten:

  • Multi-Platform Executable auf Basis der VisualWorks Smalltalk Virtual Machine (mediator.exe bzw. mediator.im).
  • Konfigurierbarer TCP/IP Server-Port für die Kommunikation mit den Clients, Standard bei i-views 5.1 ist 30063.

Der i-views-Server kann in drei Modi betrieben werden:

  1. Klassisch / kompakt: In diesem Modus startet der Server als einzelner Prozess - dem sogenannten "mediator".
  2. Multiprozess: In diesem Modus startet der Server mindestens zwei Prozesse. Der Speicherverbrauch ist dadurch höher als im kompakten Betrieb, aber viele Aufgaben können parallelisiert werden.
  3. Verteilt: In diesem Modus müssen die Server-Komponenten "stock" und "dispatcher" separat konfiguriert und betrieben werden. Es ist dann möglich, die Server-Komponenten auf unterschiedliche Rechnerknoten zu verteilen.
4.2.2 System requirements

Der i-views-Server ist Plattform-unabhängig und läuft auf allen gängigen Betriebssystemen, z. B. Windows, Solaris und Linux (ab Kernel 2.2).

OS Version Prozessor Unterstützt 64 Bit VM
Windows 10, 8, 7,Vista, 2000, XP, Server 2003, 2008, 2012 x86 ja ja
  2003 IA64 x86 Emulation nein
AIX 5.3   ja nein
HP-UX 11.x PA-RISC ja nein
  11.x IA64 nein nein
Solaris 8+ Sparc ja ja
  10 x86 nein nein
Linux RedHat, SLES9+, u.a. x86 ja ja
  RedHat, SLES9+, u.a. IA64 x86 Emulation nein
  RedHat, SLES9+, u.a. PPC ja nein
Mac OSX 10.4+ x86 ja nein
  OSX 10.4+ PPC ja nein


4.2.3 Betriebsmodi

Folgende Startparameter unterscheiden zunächst grundsätzlich über den Modus, in dem der Server gestartet wird. Ohne Parameter starter der Server im kompakten "mediator"-Modus.


Startet die Serverkomponente "Stock", die für die persistente Datenhaltung verantwortlich ist.


Startet die Serverkomponente "Dispatcher", die für die Synchronisation der Clients bzw. für die Verteilung der "active updates" verantwortlich ist.


Startet den vollständigen Server im Multiprozess-Modus. Multi-Process Mode (-server)

Mit dem Startparameter -server wird automatisch ein Stock und ein Dispatcher gestartet. Der Dispatcher öffnet einen Server auf dem Standard-Port (30063). Der Port des Stock wird automatisch ausgewählt. Authentifizierungs-Tokens zwischen den beiden Prozessen werden automatisch erzeugt und müssen nicht konfiguriert werden.

Achtung: Es ist wichtig, dass alle Clients (Knowledge-Builder, Bridge, BatchTool etc) Zugriff auf Stock und Dispatcher haben.

Falls ein dies nur für bestimmte Ports möglich ist, muss eine explizite Konfiguration von Stock und Dispatcher erfolgen. Es werden die gleichen Konfigurations-Dateien im lokalen Verzeichnis verwendet wie im echten verteilten Modus

  • dispatcher.ini konfiguriert den Dispatcher-Prozess
  • stock.ini konfiguriert den Stock-Prozess

Es ist aktuell nicht möglich, andere Konfigurations-Dateien zu verwenden. Stock-Configuration

Der Stock ist für die Speicherung der Daten auf der Festplatte verantwortlich. Ein einfaches Beispiel für die Konfiguationsdatei stock.ini ist



Diese Konfiguration sorgt dafür, dass der Stock auf Port 4998 horcht und über das Native Coast-Protokoll kommuniziert.

Die Konfigurations-Datei kann folgende Einträge enthalten:



Folgende Parameter sind an dieser Stelle einsetzbar:



Startet den Stock mit der Portnummer <num>. Ohne diese Angabe wird Port 30063 verwendet.

Dieser Parameter ist veraltet. Er wird durch den Parameter "interfaces" ersetzt. Dabei entspricht ein Eintrag von "port=1234" dem Eintrag "interfaces=cnp://". Im Unterschied zum Startparameter sind hier mehrere Werte zulässig, die, durch Komma getrennt, hintereinander aufgezählt werden.


Dieser Parameter bestimmt, unter welchen Adressen und Protokollen der Server erreichbar ist. Mehrere Werte sind zulässig, und werden durch Komma getrennt. Mögliche Protokolle sind: http, https, cnp, cnps. Dabei steht "cnp" für "Coast Native Protocol" bzw. "Coast Native Protocol Secure". Der syntaktische Aufbau einer Interface-Definition entspricht der einer URL mit Schema, Host und Port. Über den Host-Teil steuert man, über welche Netzwerkadresse(n) der Server erreicht werden kann. z.B: ""=IPv4 alle Interfaces, "[::1]"=IPv6 nur Loopback.

Die Protokolle "http" und "https" lassen sich über Proxies umleiten, so dass man den Server bspw. über einen auf Port 443 laufenden IIS erreichen kann.


Setzt das Verzeichnis, in dem sich das Verzeichnis ‚volumes’ befindet. Sollte dieser Wert auf volumes enden, so wird dieses Verzeichnis direkt verwendet, ohne noch zusätzlich darunter ein Verzeichnis ‚volumes’ anzulegen.


In diesem Verzeichnis liegen die Wissensnetze. Als Standardwert ist an dieser Stelle 'volumes' eingetragen.


Gibt das Verzeichnis an, in welches Wissensnetz-Backups geschrieben und zum Wiederherstellen auch gelesen werden. Nur vollständige Verzeichnisnamen erlaubt, keine Relativ-Angabe.

networkBufferSize=<Größe in Bytes> 

Gibt die Größe des Puffers an, der für das Senden/Empfangen von Daten verwendet wird. Der Standardwert ist 20480. In manchen Infrastrukturen kann man durch Angabe von


einen höheren Durchsatz erreichen.

flushJournalThreshold=<Anzahl der Cluster>

gibt den Maximalwert an, den "veränderte Cluster" + "Indexcluster" in einem Speichervorgang erreichen dürfen. Wenn der Wert für "veränderte Cluster" bereits überschritten ist, werden keine "Indexcluster" gespeichert sondern diese werden mit Journal geführt.

Ein niedriger Wert (z.B. 50) garantiert schnelle Speicherzeiten, baut aber potentiell ein großes Journal auf.

Ein Wert von "0" deaktiviert Journaling. Standardwert ist "2000".

Anmerkung: Ein "flush" des Journals wird immer spätestens bei einer vollständigen Speicherung ausgeführt. Diese wiederum wird ausgelöst, wenn:

  • der Mediator beendet wird
  • der letzte Client des entsprechenden Volumes abgemeldet wird
  • eine Speicherung durch einen full-save-job (siehe jobs.ini) ausgelöst wird
autoSaveTimeInterval=<Warteintervall in Sekunden>

gibt an in Sekunden, wie lang nach dem letzten Cluster-Speichern maximal gewartet wird, bis wieder automatisch gespeichert wird.  Standardwert ist 15.

clientTimeout=<Timeout in Sekunden>

gibt die Zeit in Sekunden an, die ein verbundener Client maximal keine Alive-Nachricht geschickt haben darf, bevor der Mediator ihn als inaktiv erachtet und ihn ausschließt.


Das Mediator-Passwort wird zusammen mit einem zufälligem flavour zu einen (SHA256) hashwert berechnet. Diese beiden Informationen genügen dann, um dem Mediator eine Authentifizierungsanfrage zu überprüfen. Beim Authentifizieren am Server muss der Benutzername mit "Server:admin" angegeben werden. Um diese Werte zu ermitteln kann man mit


den Server veranlassen, beim Start einen neuen Flavour und einen passenden Hashwert zu berechnen und in die ini-Datei zurückzuschreiben. Der Eintrag password.update wird dabei entfernt.


Die veraltete, noch unterstützte Art, das Mediator-Passwort zu setzen. Diese Variante darf nicht gleichzeitig mit der SHA256-Hash Variante verwendet werden.



gibt an, ob die normalerweise nach dem Start des Mediators durchgeführte Überprüfung der vorhandenen Volumes ausgelassen wird



Zu den Konfigurationsmöglichkeiten des Loggings siehe Logging-Einstellungen im Kapitel 11.1.2 Konfigurationsdatei.


Die folgenden drei Parameter dienen zur Konfiguration der Speicherzuteilung und -nutzung. Erlaubt ist die Angabe von Werten entweder in Megabyte oder in tatsächlichen Byte, wobei die Annahme gilt, dass sich Werte kleiner als 1048576 auf Megabyte-Angaben beziehen. 

maxMemory=<Integer, in MB>

 Maximal erlaubte Hauptspeicherbelegung. Minimal 50 MB, standardmäßig gesamter physikalisch vorhandener Hauptspeicher (unter Windows) bzw. 512 MB.

growthRegimeUpperBound=<Integer, in MB>

Hauptspeicherbelegung ab der verstärkt versucht wird, Speicher freizugeben. Standardmäßig 0.6 * maxMemory. 

freeMemoryBound=<Integer, in MB> [10]

Falls belegter, aber nicht mehr benötigter Speicher diese Grenze überschreitet, wird er wieder freigegeben.


Soll der Mediator mit einem integrierten BLOB-Service gestartet werden, damit die BLOBs getrennt von der Datenbank auf der Festplatte gespeichert werden, so muss die folgende Einstellung in der "mediator.ini" eingetragen werden:


Nähere Informationen dazu finden Sie in der Dokumentation des BLOB-Service (siehe Link unten). Dispatcher-Configuration

Der Dispatcher ist verantwortlich für Transaktionssteuerung und Koordination mehrere Clients. Eine einfacher Konfigurations-Datei ist 





Diese Konfiguration öffnet einen Server auf Port 5000 zu dem sich Clients verbinden können. Den Stock sucht der Dispatcher unter localhost:4998. Diese Adresse ist auch die Adresse, die von den Clients verwendet wird um Daten vom Stock zu 

Falls Dispatcher und Stock auf dem gleichen Server laufen, teil der Dispatcher seinen Clients eigenen Hostname mit, damit auch Verbindungen über das Netzwerk funktionieren.

Für die Authentifizierung des Dispatchers beim Stock wird das Token dsfkhvqw3n9485z432504 verwendet. Dieses Token muss in der Stock-Konfiguration über die "password.*"-Schlüssel eingestellt sein.



4.2.4 Installation

Der i-views-Server benötigt prinzipiell keine spezielle Installation, d.h. er ist ad hoc aus einem beliebigen Verzeichnis startbar.

Es ist dabei darauf zu achten, dass die notwendigen Zugriffsrechte (lesen/schreiben/erzeugen) für das Arbeitsverzeichnis des Servers und alle Unterverzeichnisse gesetzt sind. start parameters

Dem Mediator Prozess können beim Start diverse Parameter mit übergeben werden. Die meisten Parameter können aber auch in der mediator.ini angegeben werden, sodass man den Mediator mit einer einfachen Kommandozeile starten kann. Dabei gilt, dass auf der Kommandozeile angegebene Parameter Präzedenz vor evtl. doppelt in der .ini-Datei angegebenen Parametern haben.

Die komplette Liste der möglichen Startparameter gibt der Mediator beim Aufruf mit dem Parameter "-?" aus.

-interface <interface-1>

Dieser Parameter bestimmt, unter welchen Adressen und Protokollen der Server erreichbar ist. Mögliche Protokolle sind: http, https, cnp, cnps. Dabei steht "cnp" für "Coast Native Protocol" bzw. "Coast Native Protocol Secure". Der syntaktische Aufbau einer Interface-Definition entspricht der einer URL mit Schema, Host und Port. Über den Host-Teil steuert man, über welche Netzwerkadresse(n) der Server erreicht werden kann. z.B: ""=IPv4 alle Interfaces, "[::1]"=IPv6 nur Loopback.

Die Protokolle "http" und "https" lassen sich über Proxies umleiten, so dass man den Server bspw. über einen auf Port 443 laufenden IIS erreichen kann.

-clientTimeout <sec> 

Setzt die Zeit, innerhalb der sich ein Client automatisch melden muss, auf <sec> Sekunden. Der Wert sollte mindestens auf 600 gesetzt werden (was auch der Standardwert ist).  

-baseDirectory <directory>  

Setzt das Verzeichnis, in dem sich das Verzeichnis "volumes" befindet.  Neben dem Unterverzeichnis "volumes" werden hier auch standardmäßig die Verzeichnisse für Backups und Downloads angelegt. Dieser Parameter hieß früher "-volumes".

Die folgenden Parameter stellen Kommandos an das Mediator Executable, um bestimmte Aufgaben auszuführen, ohne danach als Server für Wissensnetze zu fungieren.

-quickRecover <volume> -recover <volume> 

Falls der Mediator unordnungsgemäß beendet wird (z.B. Absturz des Rechners), bleiben in Volumes, die in Benutzung waren, Lock-Dateien stehen. Das Volume kann dann nicht mehr betreten werden. Um das Lock aufzuheben, kann man mit dem Aufruf von -quickRecover <volume> das Lock entfernen. Der Aufruf schlägt fehl, wenn (mögliche) Inkonsistenzen gefunden wurden. In diesem Fall muss der Startparameter -recover verwendet werden. 


Das Arbeitsverzeichnis beim Aufruf muss hier das Verzeichnis sein, welches das „volumes“-Verzeichnis enthält. Der „-volumes“-Parameter wirkt hier also nicht.

-bfscommand <volume> <command>

Führt Kommandos aus, die vom BlockFileSystem erkannt werden.

Kommandozeilen-Parameter für das Logging:



Schaltet Logging ab

-loglevel <Integer>

Konfiguriert, welche Meldungen im Log erscheinen sollen:

  • 0: Alle Meldungen inklusive Debug-Ausgaben
  • 10 (Standardwert): Alle Meldungen außer Debug-Ausgaben
  • 20: Nur Warnungen und Fehlermeldungen
  • 30: Nur Fehlermeldungen
-logfile <Dateiname>, -log <Dateiname>

Name der Log-Datei, die statt der Standard-Log-Datei verwendet wird. Dieser Parameter muss auf jeden Fall verändert werden, wenn mehrere Clients im selben Arbeitsverzeichnis gestartet werden sind.


 Schaltet das Logging auf debug-mode  

-log <logname> 

 Setzt die Logdatei auf <logname>. Configuration file "mediator.ini"

Einige Mediator-Einstellungen können auch in der Konfigurationsdatei mediator.ini festgelegt werden. Der Aufbau der Datei sieht folgendermaßen aus:


Folgende Parameter sind an dieser Stelle einsetzbar:



Startet den Server mit der Portnummer <num>. Ohne diese Angabe wird Port 30061 verwendet.

Dieser Parameter ist veraltet. Er wird durch den Parameter "interfaces" ersetzt. Dabei entspricht ein Eintrag von "port=1234" dem Eintrag "interfaces=cnp://". Im Unterschied zum Startparameter sind hier mehrere Werte zulässig, die, durch Komma getrennt, hintereinander aufgezählt werden.


Dieser Parameter bestimmt, unter welchen Adressen und Protokollen der Server erreichbar ist. Mehrere Werte sind zulässig, und werden durch Komma getrennt. Mögliche Protokolle sind: http, https, cnp, cnps. Dabei steht "cnp" für "Coast Native Protocol" bzw. "Coast Native Protocol Secure". Der syntaktische Aufbau einer Interface-Definition entspricht der einer URL mit Schema, Host und Port. Über den Host-Teil steuert man, über welche Netzwerkadresse(n) der Server erreicht werden kann. z.B: ""=IPv4 alle Interfaces, "[::1]"=IPv6 nur Loopback.

Die Protokolle "http" und "https" lassen sich über Proxies umleiten, so dass man den Server bspw. über einen auf Port 443 laufenden IIS erreichen kann.

Für ssl-Kommunikation (cnps:// bzw. https://) müssen in der Konfigurationsdatei zusätzlich die Dateipfade für  Zertifikat und Private Key angegeben werden:

certificate=Name der .crt-Datei
privateKey=Name der .key-Datei



Setzt das Verzeichnis, in dem sich das Verzeichnis ‚volumes’ befindet. Sollte dieser Wert auf volumes enden, so wird dieses Verzeichnis direkt verwendet, ohne noch zusätzlich darunter ein Verzeichnis ‚volumes’ anzulegen.


In diesem Verzeichnis liegen die Wissensnetze. Als Standardwert ist an dieser Stelle 'volumes' eingetragen.


Gibt das Verzeichnis an, in welches Wissensnetz-Backups geschrieben und zum Wiederherstellen auch gelesen werden. Nur vollständige Verzeichnisnamen erlaubt, keine Relativ-Angabe.

networkBufferSize=<Größe in Bytes> 

Gibt die Größe des Puffers an, der für das Senden/Empfangen von Daten verwendet wird. Der Standardwert ist 20480. In manchen Infrastrukturen kann man durch Angabe von


einen höheren Durchsatz erreichen.

journalMaxSize=<Maximale Größe des Journals>

Mit journalMaxSize=0 kann man das normalerweise aktive Journalling deaktivieren. Der Standardwert ist 5242880 (5 MB).

autoSaveTimeInterval=<Warteintervall in Sekunden>

gibt an in Sekunden, wie lang nach dem letzten Cluster-Speichern maximal gewartet wird, bis wieder automatisch gespeichert wird.  Standardwert ist 15.

clientTimeout=<Timeout in Sekunden>

gibt die Zeit in Sekunden an, die ein verbundener Client maximal keine Alive-Nachricht geschickt haben darf, bevor der Mediator ihn als inaktiv erachtet und ihn ausschließt.


Das Mediator-Passwort wird zusammen mit einem zufälligem flavour zu einen (SHA256) hashwert berechnet. Diese beiden Informationen genügen dann, um dem Mediator eine Authentifizierungsanfrage zu überprüfen. Beim Authentifizieren am Server muss der Benutzername mit "Server:admin" angegeben werden. Um diese Werte zu ermitteln kann man mit


den Server veranlassen, beim Start einen neuen Flavour und einen passenden Hashwert zu berechnen und in die ini-Datei zurückzuschreiben. Der Eintrag password.update wird dabei entfernt.


Die veraltete, noch unterstützte Art, das Mediator-Passwort zu setzen. Diese Variante darf nicht gleichzeitig mit der SHA256-Hash Variante verwendet werden.



gibt an, ob die normalerweise nach dem Start des Mediators durchgeführte Überprüfung der vorhandenen Volumes ausgelassen wird


Zu den Konfigurationsmöglichkeiten des Loggings siehe Logging-Einstellungen im Kapitel 11.1.2 Konfigurationsdatei.


Die folgenden drei Parameter dienen zur Konfiguration der Speicherzuteilung und -nutzung. Erlaubt ist die Angabe von Werten entweder in Megabyte oder in tatsächlichen Byte, wobei die Annahme gilt, dass sich Werte kleiner