i-views 5.3
1 Knowledge-Builder
1.1 Grundlagen

When using i-views, databases work the way people think: simple, agile and flexible. That is why in i-views 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 i-views 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 i-views has to offer.

Our central tool is the knowledge builder, one of the core components of i-views. 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 Grundbausteine

The basic components of modelling within i-views 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 i-views: 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 i-views 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 Typhierarchie – Vererbung

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 i-views 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", i-views 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 i-views 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 Objekte anlegen und bearbeiten

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 i-views 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 EinfĂĽhrung 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. Operationen auf Objekten im Graph-Editor

Der Name kann im Admin-Tool oder im Knowledge-Builder nachträglich geändert werden. Der hierüber angelegte Nutzer besitzt automatische Graph-Administratorrechte. Über das Kontextmenü können mit Rechtsklick auf das Objekt weitere Operationen ausgeführt werden. Größtenteils bietet dieses Kontextmenü dieselben Funktionen wie der Formular-Editor, enthält aber 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ürzester Pfad Ansicht

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. Lesezeichen und Historie

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 Schemadefinition / Modell
1.2.1 Typen definieren

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 i-views: 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, i-views 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, i-views 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 Relations- und Attributtypen

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

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 i-views 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). Neuen Attributtyp anlegen

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

Die Dialoge zum Anlegen von neuen Attribut- und Relationstypen sind reduzierte Ansichten der Attribut- und Relationstyp-Editoren. Zur Bearbeitung von Details von Relationen und Attributen müssen Editoren mit erweitertem Funktionsumfang gestartet werden.

Zu diesen beiden Editoren gelangt man über die Auflistung der Relationen und Attribute im Reiter Schema des Objekt-Editors:

Alternativ kann über den Hierarchie-Baum links im Hauptfenster zugegriffen werden. Unter den Objekttypen befinden sich die Hierarchien für Relations- und Attributtypen. Die Editoren werden mit Rechtsklick auf die zu bearbeitende Relation oder Attribut im Kontextmenü mit Bearbeiten  gestartet.

Im Folgenden schauen wir uns die Details der Definition von Eigenschaften am Beispiel des Relationstyp-Editors an (die Attributtypdefinition ist eine Untermenge davon):

Definiert für: Hier können wir nachträglich ändern, bei welchen Objekttypen die Relation angelegt werden kann. Relationen können zwischen mehreren Objekten definiert werden und damit mehrere Quellen und Ziele haben. 

So können wir es z.B. im Schema erlauben, dass sowohl Personen als auch Bands Autoren eines Songs sein können oder einem Ort zugeordnet werden auch wenn sie keinen gemeinsamen Obertyp haben.
Mit der Schaltfläche Hinzufügen können wir weitere Objekttypen hinzunehmen. Mit Entfernen können wir dem selektierten Objekttyp und allen seinen Objekten die Möglichkeit entziehen diese Relation einzugehen.

Ändern ermöglicht das austauschen eines Objekttyps. Bereits existierende Relationen werden dann vom System gelöscht. Falls es zu löschende Relationen gibt, erscheint vor der Durchführung der Änderung ein Bestätigungsdialog.

Ziel: Hier lässt sich nachträglich ändern, zu welchen Typen von Objekten die Relation  gezogen werden kann. Um den Ziel-Objekttyp zu ändern, muss zum inversen Relationstyp gewechselt werden: Die Schaltfläche zum Wechseln trägt die Benennung des inversen Relationstyps. Nach anklicken der Schaltfläche erscheint die inverse Relation im Editor und kann auf dieselbe Weise wie die vorherige Relation bearbeitet werden.

Abstrakt: Wenn wir eine Relation definieren wollen, die nur zur Gruppierung dient aber selber keine konkreten Eigenschaften ausprägen soll, dann definieren wir sie als "abstrakt"

Beispiel: Wenn die Relation schreibt Song als abstrakt definiert wird, bedeutet dies: wenn wir Songs und ihre Relation zu Künstlern oder Bands anlegen, können wir nur spezifische Angaben machen (wer hat den Text geschrieben, wer die Musik). Die unspezifische Relation schreibt Song kann nicht in den konkreten Daten angelegt werden, sondern nur für Abfragen verwendet werden.

Kann Mehrfach vorkommen: Ein Merkmal von Relationen ist es, ob sie mehrfach vorkommen können. Beispiel: die Relation hat Geburtsort kann für jede Person nur einmal auftreten, während bspw. die Relation ist Mitglied von mehrfach für eine Person auftreten kann. Somit lassen sich logische Sachverhalte präzise modellieren. Beispielsweise können Musiker als Person nur einen Geburtsort haben, aber (auch zeitgleich) Mitglied in mehreren Musikgruppen sein. Ob die Relation mehrfach vorkommen kann, wird für beide Richtungen der Relation unabhängig angegeben: Eine Person ist nur an einem Ort geboren, der Ort kann aber wiederum Geburtsort von mehreren Personen sein.

Die Option kann nur ausgeschaltet werden wenn die Relation im tatsächlichen Datenbestand nicht mehrfach vorkommt. Bei mehrfachen Vorkommen kann das System nicht automatisch entscheiden, welche der Relationen entfernt werden soll.

Mix-In: Mix-In werden im Kapitel Erweiterungen erklärt.

Hauptrichtung: Zu jeder Beziehung gehört die Gegenrichtung. Im Kern sind beide Richtungen gleichwertig, aber es gibt zwei Stellen, wo es hilfreich ist eine Hauptrichtung zu bestimmen:

  • Im Graph-Editor: Hier stellen sich die Relationen, was Pfeilrichtung und Beschriftung angeht, immer in Hauptrichtung dar - unabhängig davon in welche Richtung sie angelegt wurden.
  • Bei einseitigen Relationen (ohne Rückrelation)

Weitere Einstellungsmöglichkeiten für Relationen und Attribute finden sich im Reiter "Details" im Unterpunkt "Definition". Die Einstellungsmöglichkeiten unter Definition werden oft gebraucht und sind darum auch bereits im Übersichtsreiter vorhanden. Unter "Definition (erweitert)" finden sich hingegen Einstellungsmöglichkeiten, die nicht so oft gebraucht werden.

Behaviour: Diese Information dient i-views Entwicklern zum debuggen und kann ignoriert werden.

Zähler: Wenn eine Zahl im Zähler eingegeben wird, ist das die Zahl, mit der Objekte dieses Typs weiter hochgezählt werden. Über die JavaScript-Funktionen getCounter(), increaseCounter() und setCounter() kann auf den Zähler zugegriffen werden. 

Namensattribut für Objekte: (Hinweis: nur an Objekttypen einstellbar, nicht an Relations- oder Attributtypen)
Typischerweise wird in vielen Ansichten in i-views ein Objekt über seinen Namen repräsentiert (z.B. in Objektlisten, Hierarchien, im Graph-Editor, der Relationszielsuche, etc.). Statt des Namen kann man hier ein beliebiges anderes Attribut der Objekte verwenden, mit denen es repräsentiert werden kann. Prominentes Beispiel bei Produkten: Die Artikelnummer.

Namensattribut für Typen: Hiermit kann auch für Typen ein alternatives Attribut zur repräsentativen Anzeige gewählt werden.

Eigenschaft ist iterierbar:
Auswahlmöglichkeiten: Aktiv / Nur schreibend / inaktiv.
Default: Aktiv.

Manchmal kommt es vor, dass die Pflege des Index zum Iterieren von Eigenschaften die Performance stark verlangsamt. Typischerweise ist dies bei Meta-Eigenschaften wie "geändert von" oder "geändert am" der Fall, die nicht unbedingt immer berücksichtigt werden müssen. In solchen Fällen wird empfohlen diese Eigenschaften auf nicht iterierbar zu schalten, indem hier die Auswahlmöglichkeit "inaktiv" verwendet wird. "Nur schreiben" dient dazu, zunächst nur den lesenden Zugriff zu verbieten, aber den schreibenden noch zu erlauben. Auf diese Weise kann getestet werden, ob ungewollte Seiteneffekte auftreten.

Richtwert für minimales Auftreten: Dieser Richtwert betrifft das User-Interface im Knowledge-Builder und ab Version 5.3 auch das User-Interface im Web-Frontend und gibt an, wie oft die Eigenschaft mindestens an einem Objekt vorkommen soll. Wenn die angegebene Zahl unterschritten wird, dann wird die Eigenschaft im User-Interface zwar rot dargestellt, das Objekt kann aber dennoch existieren. Ein Import ignoriert den Richtwert.

Richtwert für maximales Auftreten: Dieser Richtwert betrifft ab Version 5.3 das User-Interface im Knowledge-Builder und das User-Interface im Web-Frontend. Er gibt an, wie oft die Eigenschaft maximal an einem Objekt vorkommen soll. Wird die angegebene Zahl erreicht, können keine weiteren Eigenschaften angelegt werden. Ein Import ignoriert den Richtwert.

1.2.3 Modelländerungen

In i-views 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 i-views 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, i-views always provides information on the consequences of an operation. If an object has to be deleted, i-views lists all properties which will thus be removed in the confirmation dialogue of the delete operation:

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

i-views 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, i-views 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 Darstellung von Schema im 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 Metamodellierung und fortgeschrittene Konstrukte Erweiterungen

As a further means of modelling, i-views 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. Berechnete Relationen

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

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

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

Die Indexierung bildet einen Bestandteil der internen Datenverwaltung von Datenbanken. Richtig eingesetzt, kann das Setzen von Indizes eine deutliche Verbesserung der Performance hervorrufen.

Hintergrund: Grundsätzlich werden in i-views alle Wissensnetz-Elemente (Typen oder Objekte) zusammen mit ihren Eigenschaften (Attribute oder Relationshälften) in einem Cluster abgespeichert. Für gewisse Transaktionen oder Anwendungszwecke kann es allerdings von Vorteil sein, nur einen Teil der Informationen zu laden. Anstatt bei Anfragen die kompletten Elemente bzw. Cluster für das Auslesen weniger Eigenschaften laden zu müssen, wird durch einen entsprechenden Index auf die ausschließlich benötigten Eigenschaften verwiesen. Im übertragenen Sinne sind Indizes zugleich Wegweiser und Abkürzung zu benötigten Teilinformationen.

Der Bedarf für das Indexieren wird dabei in Strukturabfragen oder beim Importmapping durch diverse Hinweise deutlich: Wird ein Objekt im Importmapping anders als erwartet nicht durch den Primärnamen, sondern durch ein anderes Attribut identifiziert, so erscheint der Hinweis: „Kein nutzbarer Index für [...]“. 

Importmapping mit Rückmeldung zu fehlender Indexierung


Strukturabfrage mit Rückmeldung zu fehlender Indexierung


Vor allem beim Schreiben von Daten (= Importieren) kann die Performance durch Indexierung verbessert werden.

Benötigt wird die Indexierung für:

  • Transaktionen:
        Lesende Vorgänge: Suchen/Strukturabfrage; View-Konfiguration
        Schreibende Vorgänge: Importe (Importmapping)
  • Rechteprüfung

Je nach Verwendungsabsicht müssen für bestimmte Attribute oder Relationen die passenden Indizes gewählt werden.

Das Definieren der Indizes wird in den Einstellungen des Knowledge-Builders, das Zuordnen der Indizes kann entweder in den Einstellungen des KB oder im Detaileditor eines Typs erfolgen (Details > Indexierung > Index zuordnen). VerfĂĽgbare Indizes verwalten und anwenden

Verfügbarer Indizes (Einstellungen > Indexkonfiguration)

Alle im Knowledge-Builder angelegten Indizes können in den Einstellungen zentral verwaltet werden.

Rubrik "Indizes"

Mit Hilfe dieser Einstellungsmöglichkeit lassen sich die Indexstrukturen verwalten. Unter "Verfügbare Indizes" werden alle verfügbaren Indextypen aufgeführt. Jeder Indextyp kann für bestimmte Arten von Attributen oder Relationen verwendet werden.

Falls ein Index grau dargestellt wird, ist der Index zurzeit deaktiviert, ist er rot hervorgehoben, so ist der Index momentan nicht synchron.

Auf der rechten Seite befinden sich Schaltflächen zum Erzeugen, Löschen, Konfigurieren, Zuordnen und Synchronisieren.

Index Verwendung
Lucene-Volltextindex (JNI) Volltextsuche
Metriken Verbesserung der Performance in Strukturabfragen
System Systemrelationen (vordefiniert, kann nicht verändert werden) Wird verwendet für Relationen „erweitert Objekt“/“hat Erweiterung“/“ist Obertyp von“/“ist Untertyp von“
topic -> value Für die Auflistung von Attributwerten/Relationszielen in Objektlisten
topic -> value (domain segmented) Für die Auflistung von Attributwerten/Relationszielen in Objektlisten
value -> property Für Einwegrelationen; bewirkt Speedup für gewichtete inverse Einwegrelationen
value -> topic Attributwerte für ein Objekt
value -> topic (unique) Attributwerte, die nur einmal pro Attributtyp für ein Objekt vorkommen dürfen (Schreibrechtprüfung bei Importen)
value -> topic (word)[Zeichenketten-Zerlegung] CDP-spezifisch: Findet nur in i-views content Verwendung
value -> topic for subject keys (word)[Zeichenketten-Zerlegung] CDP-spezifisch: Findet nur in i-views content Verwendung
Volltextindex für Terme [Zeichenketten-Zerlegung] CDP-spezifisch: Findet nur in i-views content Verwendung


Rubrik "Index für Relationen"/ "Index für Attributwerte"

Indizes können unter verschiedenen Aspekten eingeteilt werden. Zunächst kann man zwischen vorwärts und rückwärts gerichteten Indizes unterscheiden. Bei den rückwärts gerichteten Indizes kann es ggf. sinnvoll sein, vom Ziel/Wert auf die Eigenschaft zu verweisen, um Metabedingungen an der Eigenschaft zu lösen. Schließlich kann ein Index optional eine Segmentierung je Typ des Quellobjektes vornehmen, um Strukturabfragen, die auf Objekte untergeordneter Typen eingeschränkt sind, effizienter zu lösen.

Anwendungsspezifisch kann es auch vorkommen, dass manche Eigenschaften keinen Index benötigen. (Diese können dann mit der Markierung "Ignorieren" versehen werden. Sie werden bei diesem Optimierungsschritt nicht weiter betrachtet.)

  • Relationen können anstelle eines vorwärts gerichteten Index einen rückwärts gerichteten Index an der Inversen verwenden - und umgekehrt.
  • Attribute können auch mit modifizierten/normalisierten Werten indexiert werden (z.B. Volltext mit Wortgrundformen). Nach diesen kann dann über einen entsprechenden Operator gesucht werden.


Anwendbare Indizes (Detailkonfiguration)

Die für einen Relations- oder Attributtyp anwendbaren Indizes können über die Detailkonfiguration zugeordnet werden.

Das Zuweisen von Indizes in der Typen-Detailkonfiguration

Attributtypen Relationstypen
topic -> value topic -> value
topic -> value (domain segmented) topic -> value (domain segmented)
value -> property value -> property
value -> topic value -> topic
value -> topic (unique) Neuen Index erstellen

Ein neuer Index wird in den Einstellungen des Knowledge-Builders angelegt unter:
Einstellungen > Indexkonfiguration > Indizes > Neu anlegen

Zu Beginn ist folgende Auswahl verfügbar:

Index Verwendung
Lucene-Volltextindex (JNI) Volltext-Suche
Redundante Speicherung für Relationsattribute Zur schnelleren Anzeige von Metaeigenschaften symmetrischer Relationen; wird ohne weitere Filter verwendet
Zusammensteckbarer Index Kombinierte Verwendung von Verteiler- und Index-Bausteinen für angepasste Indexierung; spezifische Konfiguration durch Anwendung von Indexfilter möglich

Im Folgenden wird die Konfiguration der zusammensteckbaren Indexer beschrieben, da diese am flexibelsten einsetzbar sind und nahezu jeden Einsatzbereich abdecken.

Hinzufügbare Indexbausteine

Zusammensteckbare Indizes erlauben es dem Administrator, einen Indexer aus vorgefertigten Bausteinen zusammenzustellen, um ein zugehöriges Verhalten des Indexers zu erreichen.

Ein zusammensteckbarer Indexer besteht aus Verteilerstufen, die duch eine Index-Stufe abgeschlossen werden, welche die Datenspeicherung regelt. Dabei kann ein Indexer sowohl Attribute als auch Relationen indexieren.

Wenn dem Indexer ein optionaler Indexfilter zugewiesen wird, so lässt sich das Indexerverhalten noch weiter beeinflussen, es können dann nur noch passende Eigenschaften-Typen dem Indexer zugeordnet werden.

Da Eigenschaften Attribute und Relationen umfassen, wird im Folgenden ein Attributswert bzw. Relationsziel als Wert der Eigenschaft bezeichnet.


Zusammensteckbarer Index




T = Topic = Objekt/Element/Instanz

P = Property = Attribut/Relation

"V" = Value = Attributwert/Relationsziel

 Verteiler/Index  Verwendung
Verteiler je Definitionsbereich
(danach sind alle anderen Verteiler auswählbar
Für die Suche nach Teilmenge von Objekttypen, die gemeinsam eine Eigenschaft verwenden
Verteiler je Eigenschaftstyp
(Index danach auswählbar:)
Unterscheidung, ob Attribut oder Relation
    Index Eigenschaft auf Wert/Ziel

Attribut -> Attributwert,
Relation -> Zielobjekt/Zieltyp


Für das Auffinden von Relationszielen in Strukturabfragen mit Einschränkung über Metaeigenschaft
    âť¶ Index Objekt auf Wert/Ziel
= topic -> value
    = topic -> value (domain segmented)

Objekt -> Attribut,
Objekt -> Zielobjekt von Relation


Für die Auflistung von Attributwerten/Relationszielen in Objektlisten
    âť· Index Wert/Ziel auf Eigenschaft
= value -> property

Attributwert -> Attribut
Metarelationsziel -> Attribut
Relationsziel -> Relation
Metaattribut(wert) -> Relation

Für Einwegrelationen; bewirkt Speedup für gewichtete inverse Einwegrelationen
    Index Wert/Ziel auf Eigenschaft     (Eindeutigkeitsprüfung)

Attributwert -> Attribut

Für die Suche nach Metaeigenschaften
    âť¸ Index Wert/Ziel auf Objekt
= value -> topic

Attributwert -> Attribut
Relationsziel -> Relation

Für die Unterstützung von Strukturabfragen nach Objekten mit gegebenen Werten/Zielen an Attributen/Relationen
    âť¸ Index Wert/Ziel auf Objekt
= value -> topic (unique)
Attributwert -> Objekt (Bsp.: Email-Adresse)
Verteiler je Eigenschaftswert Zusammen mit „Index Eigenschaft“:
Für eine kompakte Speicherung von sehr vielen gleichen Werten/Zielen; gleiches Verhalten wie bei „Index Wert/Ziel auf Eigenschaft“
Verteiler je Objekt Für Einwegrückrelationen
Index redundante Speicherung für Relationseigenschaften

(Schließt sich ggs. mit der Verwendung zusammensteckbarer Indizes aus)

Schnellere Anzeige von Metaeigenschaften an Relationen bei Verwendung symmetrischer Relationseigenschaften


BreitengradFür Indexierung eines Attributtyps vom Wertetyp „Geographische Position“
LängengradFür Indexierung eines Attributtyps vom Wertetyp „Geographische Position“
Intervall-StartwertFür Indexierung eines Attributtyps vom Wertetyp „Intervall“
Intervall-StopwertFür Indexierung eines Attributtyps vom Wertetyp „Intervall“
Zeichenketten-Zerlegung. Details zu Indexerbausteinen

Es wird unterschieden zwischen den aufschlüsselnden Indexerbausteinen und den indexieren­den Indexerbausteinen. Ein aufschlüsselnder Indexerbaustein partitioniert den Index nach unterschiedlichen Aspekten. Dahinter folgt entweder eine weitere Auf­schlüssel­ung oder ein indexierender Indexerbaustein, welcher die Indexeinträge speichert.


Die Abbildung zeigt exemplarisch, wie ein zusammensteckbarer Indexer aus drei Bausteinen (ohne Wertefilter) die Indexeinträge gruppiert. Dieser Index kann nun effizient beantworten

  • Welche Tiere beginnen mit S
  • Welche Pflanzen fressen andere Lebewesen
  • Welche Tiere fressen Zebra (T03)
  • u.s.w.

Fragestellungen wie zum Beispiel

  • Welche Lebewesen beginnen mit S
  • Welche Lebewesen fressen Fliegen (T05)

können ebenfalls beantwortet werden, hierzu wäre bereits eine Indexer-Konfiguration ohne Verteiler je Definitionsbereich ausreichend (und ist je nach Datenlage effizienter). Verteiler je Eigenschaftsbegriff

Der wichtigste Baustein, ohne den die meisten indexierenden Bausteine nicht eingefügt werden können. Er sollte in der Regel an erster Stelle kommen und partitioniert die Einträge nach deren Eigenschaftsbegriff. Verteiler je Definitionsbereich

Ermöglicht eine Partitionierung nach den jeweiligen Begriffen der eigenschaftstragenden Objekte. Der Baustein kann nur bei Eigenschaften an Individuen sinnvoll verbaut werden.

Kann eine Eigenschaft an mehreren Objekttypen vorkommen und wird in einer Suche nur eine Teilmenge dieser Objekttypen gesucht, so beschleunigt dieser Baustein die Suche durch entsprechende Indexzugriffen. Verteiler je Objekt

Bei der Indexierung zum Zusammenfassen der Relationsziele am Quellobjekt kann dieser Baustein verwendet werden. Wie der vorherige Baustein dient er dem Abbilden älterer Indexer und ist sein i-views 3.1 nur bei Einwegrückrelationen sinnvoll. Verteiler je Eigenschaftswert

Dient zum Partitionieren nach Relationsziel bzw. nach Attributwert. Indexiert werden kann dann nur noch die Eigenschaft (siehe Index Eigenschaft). Index Wert/Ziel auf Objekt

Mit diesem Indexbaustein werden Attributwert auf Objekt bzw. Relationsziel auf Relations­quelle im Index hinter­legt. Diese Indexierungsart ist dann sinnvoll, wenn Expertensuchen nach Objekten mit gegebenen Werten an den indexierten Attributen (bzw. mit gegebenen Zielen an den indexierten Relationen) unterstützt werden sollen. Index Objekt auf Wert/Ziel

Dieser Indexbaustein indexiert genau umgekehrt wie der „Index Wert/Ziel auf Objekt“ und kann bei Attributen genutzt werden, um für Objektlisten die Spaltenwerte der indexierten Attribute zu ermitteln. Bei Relationen kann er genauso verwendet werden wie der „Index Wert/Ziel auf Objekt“, wenn entweder die inverse Relation indexiert ist oder das Quellobjekt durch die Suche bereits stärker eingeschränkt ist als das Zielobjekt.

Möchte man Expertensuchen mit der indexierten Relation in beide Richtungen (Quelle-Ziel und Ziel-Quelle) unterstützen, so kann die Relation entweder mit diesem und dem „Index Wert/Ziel auf Objekt“ indexiert werden oder die Relation und ihre inverse Relation werden beide mit einer der beiden Index-Arten indexiert. Hierbei kann es eine Rolle spielen, ob der Indexbaustein mit einem „Verteiler je Definitionsbereich“ kombiniert ist, denn durch die Verwendung dieses Verteiler-Bausteines für einen Index auf der inversen Relation kann eine Partitionierung mittels der Zieldomain erreicht werden. Index Wert/Ziel auf Eigenschaft

Mit diesem Indexbaustein werden Wert auf Attribut bzw. Ziel auf Relation im Index hinter­legt. Diese Indexierungsart ist dann sinnvoll, wenn an den indexierten Attributen und Rela­tionen auch Suchen nach weitere Metaeigenschaften unterstützt werden sollen. Damit dieser Index in einer Suche auch für die Objekte der Eigenschaft (analog dem „Index Wert/Ziel auf Objekt“) be­nutzt werden kann, muss die jeweilige Eigenschaft im zugehörigen Begriffseditor bei „Eigenschaft ist iterierbar“ auf „Aktiv“ bleiben. Index Eigenschaft auf Wert/Ziel

Dieser Indexbaustein unterstützt Expertensuchen, bei denen Ziele der Relationen gesucht sind. Dafür muss die stärkste Einschränkung über Metaeigenschaften der Relation erfolgen. Einfache Quelle-Ziel Bedingungen werden jedoch nicht unterstützt. Index Eigenschaft

Zusammen mit dem Verteiler je Eigenschaftswert kann dasselbe Verhalten wie bei einem Index Wert/Ziel auf Eigenschaft erreicht werden. Bei sehr vielen gleichen Werten bzw. Zielen kann so eine kompaktere Speicherung erreicht werden, andernfalls bietet diese Kombination keine Vorteile. Index Eigenschaftswert

Dieser Index speichert nur die Attributwerte bzw. die Relationsziele. Eine Verwendung ist dann sinnvoll, wenn ein „Verteiler je Objekt“ vorgeschaltet ist und wenige Objekte viele Werte/Ziele haben. Index Redundante Speicherung fĂĽr Relationseigenschaften

Dieser Baustein kann nur alleine verwendet werden und dient der schnelleren Anzeige von Metaeigenschaften an Relationen, wenn symmetrische Relationseigenschaften verwendet werden. Auf technischer Ebene wird keine Indexstruktur angelegt, der Indexer kann aber über dieselben Konfigurations- und Programmschnittstellen angesprochen werden. EindeutigkeitsprĂĽfung

Die Bausteine Index Wert/Ziel auf Objekt und Index Wert/Ziel auf Eigenschaft können um eine Eindeutigkeitsprüfung ergänzt werden. Üblicherweise werden auf diese Weise ergänzte Bausteine zur Konsistenzprüfung eindeutiger Kennzeichner verwendet. Sie stehen in der Auswahlliste der hinzufügbaren Indexbausteine zur Auswahl (z.B. Index Wert/Ziel auf Objekt (Eindeutigkeitsprüfung)).

Wenn ein neuer Wert geschrieben werden soll und einen gleichen Wert im Index vorfindet, so kann dieser neue Wert nicht übernommen werden. Werte werden dann als gleich erkannt, wenn sie auch von allen Verteilern des Indexes gleich gruppiert werden. Möchte man zum Beispiel eine Eindeutigkeitsprüfung nur je Domain (zum Beispiel erlaubt dies die Koexistenz von „modern“ als Individuum von Verb und als Individuum von Adjektiv), so muss ein Verteiler je Definitionsbereich im Index enthalten sein.

Wenn auch ein Wertefilter konfiguriert wird, so wird die Eindeutigkeitsprüfung auf den gefilterten Werten durchgeführt. So kann zum Beispiel „arm“ und „Arm“ als gleich erkannt werden.
Anmerkung: ein Wertefilter, der Zeichenketten zerlegt (für Volltext) kann zwar mit der Eindeutigkeitsprüfung kombiniert werden, dies erscheint in der Regel nicht sinnvoll, da bereits eine Teilzeichenkette nach der Zerlegung zu einem Duplikat führen kann, zum Beispiel „Das Haus“ und „Haus und Hof“.

Der Index Wert/Ziel auf Objekt kann bei mehrfach vorkommenden Eigenschaften keine doppelten Werte dieser Eigenschaften an einem Objekt als Duplikate erkennen. Es könnten also zwei gleichartige Attribute mit gleichem Wert am selben Objekt existieren, nicht jedoch an verschiedenen Objekten. Will man dies nicht erlauben, so muss am Attributbegriff das mehrfache Vorkommen deaktiviert werden oder stattdessen ein Index Wert/Ziel auf Eigenschaft zur Eindeutigkeitsprüfung verwendet werden. Details zu Wertefilter Wertzerlegung

Für Geokoordinaten und Intervall-Attribute kann kein atomarer Attributwert indexiert werden. Stattdessen wird mit Längengrad und Breitengrad bzw Intervall-Startwert und Intervall-Stopwert nur eine Komponente des Wertes indexiert. Für eine komplette Indexierung muss ein entsprechender Indexer für die jeweils andere Komponente des Wertes konfiguriert werden. Zeichenketten-Manipulationen

Für Zeichenketten können im Admintool Volltext-Filter konfiguriert werden. An diesen kann konfiguriert werden, welche Manipulation an den Zeichenketten vorgenommen werden und wie die Zeichenketten in einzelne Worte zerlegt werden sollen. In Expertensuchen werden dann zusätzliche Operatoren angeboten, die mit der jeweiligen Bezeichnung des Filters er­gänzt sind, damit gezielt mittels dieses Filters gesucht werden kann.

Mittels einer „Zeichenketten-Filterung“ können die Zeichenketten in manipulierter Form indexiert werden, bei einer Suche werden dann alle Attributwerte als Treffer interpretiert, die durch den Filter auf die gleiche Zeichenkette abgebildet werden wie die Sucheingabe.

Mittels einer „Zeichenketten-Zerlegung“ können aus einem Text mehrere (manipulierte) Teil­zeichen­ketten (Tokens) indexiert werden. Der zugehörige Index ermöglicht dann Experten­suchen, die mittels der Operatoren „Enthält Worte“ und „Enthält Phrase“ innerhalb der Zeichen­ketten suchen. Metriken

An allen Eigenschaftstypen kann ein Attribut "Durchschnittliche Anzahl (berechnet)" angelegt werden. Der Wert des Attributes gibt an, wie viele Ausprägungen der zugehörigen Eigenschaft ein Objekt aus der Eigenschaftsdomäne durchschnittlich hat.

Mit dieser Information können Strukturabfragen besser entscheiden, wie sie ihre Ergebnismenge ermitteln. Zusätzlich kann ein Attribut "Durchschnittliche Anzahl (manuell)" angelegt werden, dessen Wert diesen Wert überschreibt. (Das ist dann sinnvoll, wenn die Domäne abstrakt ist, aber die Eigenschaft in Abfragen nur bei tatsächlichen Vorkommen angewendet werden soll.)

1.3 Suchen / Abfragen

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 Strukturabfragen

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. Verwendung Strukturabfragen

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 i-views 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. Aufbau von Strukturabfragen

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. Mehrere Bedingungen

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 Bedingungen

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. Transitivität / Wiederholungen

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: Negativ-Bedingungen

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). Entspricht / Referenz

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"). Weitere Optionen im Aufbau der Strukturabfragen

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": Die Bedingungen im 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 i-views 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 Einfache Suche / Volltextsuche

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. Einfache Suche - Einstellungen im 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 i-views server will be disburdened. Mehrwort-Eingaben



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. Volltextsuche und Indexierung

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 i-views 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 i-views, 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 Such-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. Zusammenstellung von Such-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%. Die einzelnen Komponenten

Gewichtete Relationen und Attribute

Ausgehend von semantischen Objekten können wir mit diesem Schritt den Graph traversieren und Relationsziele oder Attribute aufsammeln. Dazu müssen wir den Typ der Relation oder des Attributs angeben.

Achtung: Ausgabe sind nur noch die aufgesammelten Ziele, nicht mehr die Ausgangsmenge. Wenn diese angezeigt werden sollen, müssen wir anschließend die Eingangs- und die Ausgangstreffer zusammenfassen.

Bei der Traversierung einer Relation kann die Gewichtung der Treffer beeinflusst werden. Nehmen wir an, wir wollen den Ausgangs-mood unserer Beispielsuche um Unter-moods semantisch erweitern. Aber diese Indirektion soll sich in einem Ranking niederschlagen: Verbindungen zu Bands, die über die Untermoods laufen, sollen nicht so stark zählen wie Verbindungen über einen  Ausgangsmood. Zu diesem Zweck können wir das Relation-Entlanggehen mit einem pauschalen Wert – z.B. 0,5 – belegen, und mit dem Eingangsgewicht verrechnen, beispielsweise multiplizieren. Dann zählen die in diesem Schritt hinzugefügten Untermoods nur halb so viel wie die direkten.

Statt eines pauschalen Gewichts für das Entlanggehen der Relation zu vergeben, können wir den Wert auch aus einer Metaeigenschaft des Basistyps Fließkommazahl der ausgewählten Relation auslesen. Falls dieses Attribut nicht vorhanden ist oder keines konfiguriert wurde, wird der Standardwert verwendet. Der Wert sollte zwischen 0 und 1 liegen. Die Treffererzeugung kann detaillierter konfiguriert werden: Bei Relationen kann optional auch für die Relationsquelle (statt für das Relationsziel) ein neuer Treffer erzeugt werden. 

Wenn eine Relation als Eigenschaft ausgewählt wurde und Treffer für Relationsziele erzeugt werden, können wir optional auch die Relation transitiv verfolgen. Bei jedem Schritt verringert sich der Qualitätswert, bis der angegebene Schwellwert unterschritten wird. Falls ein Objekt mehr Relationen hat als bei maximaler Fanout angegeben, werden diese Relationen nicht verfolgt. Je höher der Dämpfungsfaktor ist, desto stärker wird der Qualitätswert verringert.



Mit Strukturabfrage-Komponenten können wir entweder semantische Objekte suchen / von einer bestehende Menge zu anderen Objekten gehen (wie mit der gewichteten Relation) oder eine Menge filtern.

Wenn wir Objekte suchen, leiten wir unsere Ausgangsmenge von Treffern aus einem der vorhergehenden Schritte über den Parameternamen in die Suche ein. (Allgemein: Innerhalb der Expertensuche können Variablen der Such-Pipeline wie z.B. search-String über Parameter referenziert werden). Die Eingabe bleibt in diesem Fall leer.


Zur Filterung geben wir dagegen als Eingabe eine Menge von Objekten an. In der Ausgabe sind alle Objekte enthalten, auf die die Suchbedingung zutrifft. Objekte, die nicht zur Suchbedingung passen, können optional in einer weiteren Variable (Rest) gespeichert werden.

Wir können die Strukturabfrage entweder direkt in der Komponente ad hoc definieren oder eine bestehende Strukturabfrage verwenden.

Achtung: Wenn eine bestehende Suche ausgewählt wurde, wird keine Kopie angelegt, Änderungen, die wir an für Zwecke der Such-Pipeline an der Strukturabfrage vornehmen, ändern sie auch für alle anderen Verwendungen.



Mit der Komponente Suche können einfache Suchen, Volltextsuchen und andere Such-Pipelines ausgeführt werden. Einfache Suchen und Volltextsuchen werden dabei mit einer Zeichenkette versehen, z.B. mit dem searchString: Das ist ein Parameter, der in allen Such-Pipelines zur Verfügung steht um die Nutzereingabe zu verarbeiten. Die Treffermenge der aufgerufenen Suche belegt die Ausgabe dieser Komponente. 

Über das Einbinden von Such-Pipelines in anderen Such-Pipelines können wir häufiger auftretende Teilschritte ausfaktorisieren. Anderen Such-Pipelines können mehrere Parameter übergeben werden und ganze Treffermengen übergeben. Mit eingebundenen Such-Pipelines können wir auch mehrere Parameter austauschen, d.h. wir können in der eingebundenen Suche auf jede Teilschrittausgabe der umgebenden Suche zugreifen und umgekehrt. Wenn wir auf "ausgewählte Parameter gehen, können wir diese auch umbenennen, falls wir z.B. eine Treffermenge aus der eingebundenen Suche nutzen wollen, aber den Namen schon verwendet haben. Oder wir können, um solche Konflikte zu vermeiden, nur einen Teil der Parameter aus der eingebundenen Suche übernehmen.


Treffer zusammenfassen

Mit dieser Komponente können wir mehrere Treffermengen aus unterschiedlichen vorangegangenen Schritten zusammenfassen. Folgende Methoden zur Zusammenfassung stehen zur Verfügung:

Vereinigungsmenge: Alle Treffer, die in mindestens einer der Mengen vorkommen, werden als Ergebnis ausgegeben

Schnittmenge: Nur Treffer, die in allen Mengen vorkommen, werden als Ergebnis ausgegeben.

Bei Vereinigungsmengen und Schnittmengen kommt es vor, dass ein semantisches Objekt in mehreren Treffermengen vorkommt und zu einem Gesamttreffer mit neuer Trefferqualität verrechnet werden muss. Hier stehen wieder die erwähnten Verrechnungsmethoden zur Verfügung.

Differenz: Eine der Treffermengen muss als Ausgangsmenge definiert werden. Von dieser werden die anderen Mengen abgezogen.

Symmetrische Differenz: Die Ergebnismenge besteht aus den Objekten, die nur in genau einer Teilmenge enthalten sind (= alles außer dem Schnitt, bei zwei Mengen).

Es können drei unterschiedliche Arten von Gesamttreffern erzeugt werden. Die Auswahl ist insbesondere dann relevant, wenn die Teiltreffer zusätzliche Informationen tragen.

  • Einheitliche Treffer erzeugen, ursprüngliche Treffer als Ursache merken: Es werden neue Treffer erzeugt, die den ursprünglichen Treffer als Ursache enthalten.
  • Ursprüngliche Treffer erweitern: Der ursprüngliche Treffer wird kopiert und erhält einen neuen Qualitätswert. Falls mehrere Treffer für dasselbe semantische Objekt vorliegen, wird ein beliebiger Treffer gewählt.
  • Einheitliche Treffer erzeugen: Es wird ein neuer Treffer erzeugt. Die Eigenschaften des ursprünglichen Treffers gehen verloren.


Teiltreffer zusammenfassen

Bei der Einzelverarbeitung ist es öfters notwendig, eine Gesamtmenge aus Teiltreffern zu erzeugen. Dieses ermöglicht die Komponente „Teiltreffer zusammenfassen“. Diese fasst alle Treffer einer oder mehrerer Teiltreffermengen zusammen. Der Unterschied zu Treffer zusammenfassen liegt darin, dass die Zusammenfassung erst am Ende erfolgt, nicht für jede einzelne Teiltreffermenge. Dies ist insbesondere bei der Berechnung der Qualität relevant, da Treffer zusammenfassen z.B. bei Median falsche Werte liefern würde.



Eine Such-Pipeline kann ein Skript (JavaScript oder KScript) enthalten. Dieses kann auf die Variablen der Such-Pipeline zugreifen. Außerdem kann ein Skript mehrere Parameter an die Such-Pipeline übergeben. Das Ergebnis des Skripts wird als Ergebnis der Komponente verwendet.

Die JavaScript-API sowie KScript sind in separaten Handbüchern beschrieben.


Qualität aus Attributwert übernehmen

Für Treffer können wir den Qualitätswert aus einem Attribut des semantischen Objekts übernehmen. Falls das Objekt nicht genau ein solches Attribut besitzt, wird der Standardwert verwendet. Der Wert sollte zwischen 0 und 1 liegen. 


Gesamtqualität aus gewichteten Qualitäten berechnen

Um die Qualität eines Suchtreffers anzupassen, kann es hilfreich sein, aus einzelnen Teilqualitäten einen Gesamtwert zu berechnen. Die Qualitäten müssen dabei als Zahlenwerte vorliegen. Aus diesen Werten wird eine neue Gesamtqualität berechnet.


Gesamtqualität einer Treffermenge berechnen

Aus den einzelnen Qualitätswerten einer Treffermenge kann man eine Gesamtqualität berechnen.


Qualität beschränken

Treffermengen können wir auf Treffer beschränken, deren Qualitätswert innerhalb vorgegebener Schranken (Minimum und Maximum) liegen. Im Normalfall möchten wir Treffer, die unterhalb einer bestimmten Qualitätsschwelle liegen, ausfiltern.


Trefferanzahl beschränken

Falls die Gesamtzahl einer Treffermenge begrenzt werden soll, können wir die Komponente Trefferanzahl beschränken hinzufügen. Mit der Option Treffer gleicher Qualität nicht zerteilen verhindern wir, dass bei mehreren Treffern mit gleicher Qualität eine willkürliche Auswahl erfolgt, um die Gesamtzahl einzuhalten. Wir erhalten dann mehr Treffer als vorgegeben.

Für einige sehr spezielle Fälle können wir die Treffer auch zufällig auswählen lassen, z.B. wenn wir eine große Menge an Treffern gleicher Qualität haben und eine Vorschau generieren wollen.


Qualität skalieren

Die Qualitätswerte einer Treffermenge kann skaliert werden. Es wird eine neue Treffermenge mit skalierten Qualitätswerten berechnet. Die Berechnung erfolgt ein zwei Schritten:

  1. Die Qualitätswerte der Treffer werden begrenzt. Die Grenzwerte können entweder festgelegt oder berechnet werden. Bei der Berechnung werden der minimale und der maximale Wert der Treffer ermittelt. Falls die Grenzen vorgegeben werden und ein Treffer einen Qualitätswert außerhalb der Grenzwerte hat, wird der Wert auf den Grenzwert beschränkt. Falls man solche Treffer entfernen will, muss man die Komponente Qualität beschränken vorschalten. Beispiel: Abbilden von Prozentwerten auf Schulnoten. 30% ist Durchschnitt, über 90% ist Highscore. Die Werte können innerhalb von 30% bis 90% linear skaliert werden.
  2. Anschließend werden die Qualitätswerte linear skaliert. Treffer mit dem minimalen/maximalen Eingangswert erhalten den minimalen/maximalen skalierten Wert.


Trefferqualität berechnen

Mit Hilfe eines KPath-Ausdrucks wird für einen Treffer ein neuer Treffer mit berechneter Qualität erzeugt. Der KPath-Ausdruck wird ausgehend von der Eingabe berechnet.

1.3.4 Inhaltsmodell "Hit"

Damit für Suchabfragen sowohl Qualität als auch Ursachen mitverarbeitet und transportiert werden können, gibt es das Inhaltsmodell des Typs „Hit“. Ein „Hit“ kann als Container verstanden werden, der das Element inklusive mehrerer Eigenschaften zusammenfasst und temporär für den Kontext zur Verfügung stellt. Die enthaltenen Eigenschaften sind beispielsweise berechnete Treffer-Qualität, Treffer-Ursache, ChangeLog-Eintrag etc.

In Such-Pipelines stehen die Inhaltsmodelle „Hit“ und „Hits“ zur Verfügung. Der Typ „Hits“ ist dabei ein Array aus mehreren „Hit“-Elementen:


Metaattribute der Hits

Außer dem semantischen Element werden in einem Hit folgende Metaattribute transportiert:

  • Treffer-Qualität (quality): Kann in einer Such-Pipeline durch das Setzen einer Qualität einen Wert zwischen 0 und 1 annehmen; die Treffer einer Strukturabfrage enthalten per Default den Wert 1
  • Treffer-Ursache (cause): Bezeichnet das Eingangs-Element, das zum Treffer geführt hat und um welchem Typ es sich handelt
  • Treffer-Ursache (snippet): Bezeichnet den Inhalt bzw. den Suchbegriff, der zum Treffer geführt hat

Detaillierte Informationen zu den Metaattributen sind in der JavaScript-API dokumentiert.

Verwendung von Hits in Such-Pipelines

Wenn in einer Such-Pipeline eine Treffermenge mithilfe einer einfachen Abfrage verarbeitet werden soll, so ist aus Gründen der zum Array zusammengesetzten Treffermenge eine Einzelverarbeitung notwendig: Abfragen können einen einzelnen „Hit“ in Form eines Strings verarbeiten, jedoch keine „Hits“ (= Array). Die Umwandlung eines „Hit“ in einen String kann wiederum durch ein Skript erfolgen, das der einfachen Abfrage vorangestellt ist.

Beispiel-Skript für die Umwandlung eines Hit in einen String: 

function search(input, inputVariables, outputVariables) {

  return input.element().name();


Verwendung von Hits in Tabellen

In der Spaltenelement-Konfiguration einer Tabelle steht die Option "Hits verwenden" zur Verfügung. Diese Option bestimmt, ob für die Anzeige von Suchergebnissen das gesamte Hit-Element (semantisches Element + Metaattribute) weitergereicht werden soll oder nur das semantische Element.

Verarbeitung von Hits in Tabellen per Skript

Wenn die Suchergebnisse per Skript weiterverarbeitet werden sollen, bestimmt die Option "Hits verwenden", ob das Suchergebnis wie ein Hit behandelt werden soll: Das Skript bekommt als JavaScript-Objekt entweder $k.SemanticElement oder $k.Hit zur Verarbeitung weitergereicht.

1.3.5 Die Suche im 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.6 Spezialfälle Volltextsuche 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. Suche mit regulären Ausdrücken

 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, i-views supports the standard also known from the standard known from Perl which, for example, is described in the Wikipedia article for regular expression. Suche in Ordnern

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 Ordner und Registrierung

Neben den Objekten und ihren Eigenschaften bauen wir in einem typischen Projekt auch diverse andere Elemente: wir definieren z.B. Abfragen und Importe/Exporte oder schreiben Skripte für spezielle Funktionen. Alles, was wir bauen und konfigurieren, können wir in Ordnern organisieren.

Die Ordner werden geteilt mit allen anderen, die am Projekt arbeiten. Wenn wir das nicht möchten, können wir Dinge im Privatordner ablegen, etwa für Testzwecke. Dieser ist nur für den jeweiligen Nutzer sichtbar.

Eine spezielle Form des Ordners ist die Sammlung semantischer Objekte, in der wir von Hand Objekte z.B. zur späteren Bearbeitung ablegen können. Dazu können wir sie einfach mit Drag&Drop in den Ordner schieben, zudem gibt es Operationen um z.B. Ergebnislisten in Ordnern festzuhalten. Die Sammlung semantischer Objekte hält lediglich Referenzen auf die Objekte: In dem Moment, in dem wir eines dieser Objekte löschen, ist wird es ebenfalls in der Sammlung gelöscht. Aus Gründen der Performance wird bei Sammlungen semantischer Objekte mit mehr als 100 Einträgen darauf verzichtet, die am besten zum Inhalt passende Tabellenkonfiguration zu ermitteln. Mittels der Kontextmenü-Funktion "Konfiguration der Objektliste bestimmen" können wir das bei Bedarf anfordern.



Abfragen, Skripte etc. können sich gegenseitig aufrufen (eine Abfrage kann in eine andere Abfrage oder in ein Skript eingebaut werden, umgekehrt kann ein Skript von einer Such-Pipeline aus aufgerufen werden). Zu diesem Zweck gibt es Registrierungsschlüssel, mit denen wir Abfragen, Import-/Export-Abbildungen, Skripte und sogar Sammlungen semantischer Objekte und Strukturordner ausstatten können, damit sie anderen Konfigurationen Funktionalität zur Verfügung stellen. Der Registrierungsschlüssel  muss eindeutig sein. Alles, was einen Registrierungsschlüssel hat, wird automatisch in den Ordner Registrierte Objekte aufgenommen bzw. in den seinem Typ entsprechenden Unterordner


Verschieben, Kopieren, Löschen

Nehmen wir an, wir haben in unserem Projekt einen Ordner namens Playlist-Funktionen Dieser enthält vielleicht einen Export, einige Skripte und eine Strukturabfrage ähnliche Songs, die wir in einem REST-Services benutzen wollen. In dem Moment, in dem wir der Strukturabfrage einen Registrierungsschlüssel geben, wird sie im Ordner Registrierte Objekte" (Abschnitt "Technik") aufgenommen. D.h. die Strukturabfrage "ähnliche Songs taucht im Ordner Registrierte Objekt unter Abfrage auf. Sie bleibt dort auch, wenn wir sie aus unserem Projekt-Unterordner Playlist-Funktionen entfernen. Entfernen wir den Registrierungsschlüssel, fällt die Abfrage automatisch aus der Registratur heraus.

Das Grundprinzip beim Löschen bzw. Entfernen: Abfragen, Importe, Skripte können in ein oder mehreren Ordnern gleichzeitig und müssen in mindestens in einem Ordner enthalten sei. Erst wenn wir also z.B. unsere Abfrage aus dem letzten Ordner entfernen, wird sie tatsächlich gelöscht. Nur dann bittet i-views auch um eine Bestätigung der Löschaktion. Das gleiche gilt für das Entfernen des Registrierungsschlüssels.

Wollen wir in einem Schritt die Abfrage löschen, unabhängig davon, in wie vielen Ordnern sie sich findet, so können wir das nur von der Registratur aus.



In den Ordnereinstellungen können wir für Suchergebnisse, Ordner und Objektlisten (Liste der konkreten Objekte im Hauptfenster des Knowledge-Builders bei Selektion eines Objekttyps auf der linken Seite) Mengengrenzen definieren. Automatische Abfrage bis zur Anzahl Objekte gibt an, bis zu welcher Anzahl von Objekte der Ordnerinhalt oder die Objektliste ohne weitere Interaktion durch den Benutzer gezeigt wird. Ist die dort eingestellte Grenze überschritten, bleibt die Liste zunächst leer und in der Statuszeile erscheint die Meldung Abfrage nicht ausgeführt. Suche ausführen ohne Eingabe in die Eingabezeile zeigt alle Objekte. Zumindest bis die zweite Grenze erreicht ist: Maximale Anzahl der Abfrageergebnisse, Maximale Ergebnisanzahl in Objektlisten - hier hohe Werte - ab diesen Werten tatsächlich kein Ergebnis mehr, müssen Abfragen einschränken, z.B. in Objektlisten, indem wir zusätzlich Anfang des Namens im Eingabefeld.

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 Abbildungen von Datenquellen

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

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 Die Objektabbildung

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. Die Attributabbildung / Identifizieren von Objekten

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". Die Relationsabbildung

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. Die Typabbildung

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. Abbildung von Erweiterungen

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

If this setting is applied to an attribute, it ensures that the value from the table overwrites the attribute value of exactly one existing attribute. No new attributes are created with this setting. If the object has more than one attribute value of the selected type, no value is imported.

If you use the “Update” setting for an identifying attribute while using the “Update or create if not available” setting for a corresponding object, the error message “Attribute not found” appears, if the identifying object is not available in i-views.

If “Update” is applied to an object, this setting ensures that all properties of the object can be added or changed by the import. New objects are not created.

Example: Let’s assume we keep a database of our favorite songs. We have just received a list with songs that contain new information. We want to get this information into our database but prevent songs that are not our favorite songs from being imported. We use the “Update” setting to do this.

The song "About A Girl" is already available in the Knowledge Builder.

The import table contains information on the length, rating and creator of the song.

For Song objects we specify that they are supposed to be updated. All attributes, relations and relational targets receive the import setting “Update or create if not available yet.”

The result: The song has been updated and has received new attributes and relations. Already existing properties have been updated (value). 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 mit der Spaltennummer n 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    









Tabellespalten können auch unabhängig von ihrer Spaltennummer referenziert werden, indem eigens definierte Bezeichner verwendet werden. Der Vorteil hierin ist, dass bei einer Änderung der Spalten-Reihenfolge der Importtabelle die Zuordnung nicht verloren geht.

Der Bezeichner für die jeweilige Spalte der Importtabelle wird in die Spalte mit der Überschrift Bezeichner der Spaltendefinitionstabelle eingetragen. Referenziert werden diese Spalten durch Anlegen einer virtuellen Tabellenspalte, die den Bezeichner als Tabellenspalten-Überschrift enthalten (siehe Beispiel 2).


Referenz auf eine Spalte mittels eindeutigem Spalten-Bezeichner name und anschließender Transformierung durch regulären Ausdruck regex.

Die $-Zeichen sind funktioneller Bestandteil der Bezeichner-Syntax.

<$Name$u>'Company #1'COMPANY #1


Beispiel 1: Verwendung von regulären Ausdrücken (Referenz über Spaltennummer)

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.

Beispiel 2: Verwendung individueller Bezeichner (in Kombination mit regulären Ausdrücken)

Im folgenden Beispiel werden die Inhalte der Spalte Company mittels virtueller Spalten in Großbuchstaben transformiert: Spalte 5 verwendet eine Referenz per Spalten-Nummer, Spalte 6 verwendet eine Referenz per Spalten-Bezeichner.


Ein Klick auf die Vorschau zeigt die transformierten Spalteneinträge:

Folgende Abbildung zeigt die Auswirkung von vertauschten Spalten einer Importtabelle: Während bei der alleinigen Verwendung von regulären Ausdrücken (<1u>) die falsche Spalte transformiert wird, bleibt bei Verwendung eines Bezeichners mit nachgelagertem regulären Ausdruck (<$Comp$u>) der Inhalt gleich. Konfiguration weiterer tabellenorientierter Datenquellen


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. Abbildung einer XML-Datei

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 Attributtypen und -formate

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 Das Importieren von Dateien (z.B. Bildern) ist möglich. Dazu muss entweder der absolute Pfad zur Datei angegeben werden oder die zu importierenden Dateien müssen im gleichen (oder einem anzugebenden Unterverzeichnis) liegen wie die Import-Datei.
  • <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 Konfiguration des Exports

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 und -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.5.5 Gelöschte Individuen aus einem Backup wiederherstellen

Der RDF-Export und -Import eignet sich dazu, gelöschte Individuen aus einem Backup-Netz wieder herzustellen. Dazu wie folgt vorgehen:

  1. Das Backup-Netz im Knowledge-Builder öffnen
  2. Einen neuen Ordner anlegen und die wiederherzustellenden Individuen dort ablegen. Hierzu in der Listenansicht der zu übernehmenden Individuen mit Rechtsklick das Kontextmenü öffnen und „Inhalt in neuen Ordner kopieren“ wählen, dabei neuen Ordner als Ablageziel wählen
  3. Per Kontextmenü auf dem neu erstellten Ordner den RDF-Export öffnen
  4. Im Exportdialog einen Dateinamen angeben, die Optionen "URLs verwenden (rdf:about)" und "Frame-URLs verwenden (krdfframe:)" auswählen und den Export ausführen:

    Hinweis: Die Option "KRDF verwenden" bewirkt, dass i-views spezifische Inhalte zusätzlich mit übernommen werden, welche mittels RDF-Syntax nicht vollständig abgebildet werden können.
  5. Knowledge Builder schließen und das Zielnetz im Knowledge Builder öffnen
  6. Im Hauptmenü unter Werkzeuge > RDF > RDF Import den RDF-Import-Dialog öffnen:

  7. Datei auswählen und „Weiter“ drücken:

  8. Im Auswahl-Dialog die Option "Änderungen am Schema erlauben" deaktivieren, „Ordner mit importierten Objekten anlegen" aktivieren:

  9. Import ausführen
  10. Die wiederhergestellten Individuen überprüfen


1.5.6 Ausgewähltes Schema transportieren

Über das Admin-Tool lässt sich das gesamte Schema eines Wissensnetzes mittels RDF-Ex- und Import von einem Wissensnetz in ein anderes übertragen. Möchte man aber nur ausgewählte Typen übertragen, bietet sich die Funktion "Schema in Ordner kopieren" an, welche für alle Typen per Kontextmenü verfügbar ist. Diese Funktion erstellt eine Referenz auf den gewählten Typ zusammen mit allen anderen (Eigenschafts-)Typen, die erforderlich sind, um im Zielnetz den gewählten Typ oder Objekte dieses Typs anlegen zu können.

Hat man alle erforderlichen Informationen in einem Ordner gesammelt kann man diesen analog zur Vorgehensweise im vorangegangen Kapitel exportieren und im Zielnetz importieren. Die Option "Änderungen am Schema erlauben" sollte dann jedoch aktiviert werden.

1.6 Zugriffsrechte und Trigger

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 Die PrĂĽfung von Zugriffsrechten

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]". Die Aktivierung des Rechtesystems

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

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. Der Rechtebaum

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 abgebrochen. 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. Entscheider im Rechtebaum

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. Zusammensetzen von Rechten

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. Positiv-Konfiguration von Rechten

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. Negativ-Konfiguration von Rechten

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. Beispiel: Jeder Benutzer darf selbst erstellte Elemente ändern und löschen

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. Konfiguration von eigenen Operationen

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. Trigger aktivieren

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. Der Triggerbaum

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 einfache Triggerbaum beginnt mit einem Operationsfilter und teilt sich nach dem 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. Er filtert jedoch Attribute und Relationen, die an Objekten des Typs Konzert gespeichert sind. Der Eigenschaftsfilter lässt nur Operationen durch, welche an den Attributen oder Relationen zum Datum, dem Veranstaltungsort oder dem Künstler durchgeführt werden. Treffen diese Bedingungen zu, wird das zugehörige Skript ausgeführt, welches den Namen des Konzertes zusammensetzt.

So würde dieser Trigger Baum in i-views aussehen: Trigger erstellen

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, 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-Aktionen

Trigger-Aktionen dienen dazu, intelligente Operationen in der semantischen Graph-Datenbank durchzuführen, welche beispielsweise Arbeitsabläufe automatisieren oder unterstützen. Sie werden jedoch nur ausgeführt, wenn die Zugriffsituation und die Verknüpfungen im semantischen Netz einen bestimmten Zustand annehmen, der durch den 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 den Aktionstyp aus der Liste 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. Skript 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, batchtool.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. ChangeLog Trigger

Möchte man die Aktivitäten von Nutzern an Objekten überwachen, sollte ein changeLog Trigger eingerichtet werden, auch bekannt als Änderungshistorie.

Dafür muss zunächst ein Zeichenketten-Attribut definiert werden, das den internen Namen „changeLog“ erhält. Dieses changeLog Attribut muss für alle Elemente definiert werden, an denen es Nutzer-Aktivitäten dokumentieren soll.


Durch einen Klick auf „öffnen“, öffnet sich die Tabelle, in der zu sehen ist wann, wer welche Änderung an welchem Wissensnetzelement mit welchem Wert getätigt hat.

Der Trigger muss die Operationsfilter enthalten, die die Änderungshistorie protokollieren soll, und die Elemente, an denen das Attribut zu sehen sein soll.

Das Trigger-Skript sieht wie folgt aus:


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




In einem Netz soll an allen Objekten aus dem Wissensnetz ein changeLog gespeichert werden. An den Objekten sollen Eigenschaften-Modifikationen, -erstellungen und -löschungen protokolliert werden. Es wurde dafür zunächst ein Operationsfilter angelegt, der auf die Operationen „Attribut löschen“, „Attributwert modifizieren“, „Relation erzeugen“, „Relationshälfte erzeugen“ und „Relationshälfte löschen“ reagiert.

Im nächsten Schritt wurde ein Suchfilter definiert, der festlegt, welches die übergeordneten Elemente sind, an denen die Operationen getätigt werden.

Beim Trigger-Skript wurde der Operationsparameter „Übergeordnetes Element“ eingestellt, weil dieser dem Suchfilter entspricht.

Die Trigger-Regeln (Operationsfilter, Suchfilter und Trigger-Skript) sind durch ihre Prüfabfolge wie folgt im Hierarchiebaum verortet:

1.6.3 Filterarten

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

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

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

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

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 Operationsparameter

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. Operationsparameter Zugriffselement

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. Operationsparameter Benutzer

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 Operationsparameter (Ober)typ

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 Operationsparameter Ăśbergeordnetes 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 Operationsparameter Eigenschaft

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 Operationsparameter 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 Operationsparameter Inverser Relationstyp

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 Operationsparameter Relationsziel

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 Operationsparameter Primärelement

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) Operationsparameter Primäres Relationsziel

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 Operationsparameter Kernobjekt

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 Operationsparameter Primäres Kernobjekt

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) Operationsparameter Primäreigenschaft

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 Operationsparameter Ordner

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 Beispiele: Die Verwendung von Operationsparametern

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 Operationen

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). Beispiel: Die Verwendung von Operationsgruppen im Rechtesystem

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 Testumgebung

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. Eine Zugriffssituation testen

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. Testfälle definieren

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-Konfiguration

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 kann so konfiguriert werden, dass wichtige zu ergänzende Eigenschaften gut sichtbar abgefragt werden, wie beispielsweise die Detailseiten von Objekten. Dies ist besonders hilfreich, wenn Daten systematisch erfasst werden sollen.

1.7.1 Konzept

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

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.

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 hierzu ist im Kapitel "Kontext / Verwendung von View-Konfigurationen" beschrieben. Viewkonfiguration-Mapper

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. Erstellung und Aktualisierung von View-Konfigurationen


Im Knowledge-Builder gibt es zwei Stellen, an denen sich eine neue View-Konfiguration erstellen lässt:

1. Wissensnetzelement-orientierte Konfiguration

Die erste Stelle bietet sich an, wenn zu einem bestimmten Objekttyp eine View-Konfiguration erstellt werden soll: Unter dem Reiter "Details" kann die View-Konfiguration zu Detailansichten und Listen bearbeitet werden.

In der angezeigten Hierarchie gibt es Unterpunkt „View-Konfiguration“ mit vier weiteren Unterpunkten.

  • Objekt -> Details: Hier kann die Detailansicht zu Objekten konfiguriert werden.
  • Objekt -> Objektliste: Hier kann die Objektliste konfiguriert werden, die im Knowledge-Builder die Objekte des ausgewählten Typs anzeigt.
  • Typ -> Details: Hier kann die Detailansicht zu Typen konfiguriert werden.
  • Typ -> Objektliste: Hier kann die Objektliste der Untertypen des ausgewählten Typs konfiguriert werden, die im Knowledge-Builder zu sehen ist.

 Am Objekttyp im Reiter „Details“ können View-Konfigurationen für diesen Typ oder Objekte dieses Typs erstellt werden.

Mit einem Klick auf "Neu"  können Sie eine neue View-Konfiguration anlegen. Bei Objektlisten erstellen Sie automatisch eine neue View-Konfiguration des Typs Tabelle. Bei Details, öffnet sich ein Dialog, in dem Sie das gewünschte View-Konfigurationslement auswählen können (siehe dazu Kapitel "View-Konfigurationselemente").

Mit einem Klick auf den Bearbeiten-Button oder einem Doppelklick auf die ausgewählte View-Konfiguration öffnen Sie den Editor, mit dem Sie die Ansicht konfigurieren können.

Hinweis: Unter dem Reiter "Kontext" der jeweiligen Konfiguration wird durch den Eintrag "anwenden in" festgelegt, in welcher Anwendung die Konfiguration angezeigt werden soll:

Anwendungskontext "anwenden in"Resultat
Knowledge-BuilderDie Detailansicht oder die Liste zu einem Typ bzw. Objekt wird im Knowledge-Builder angezeigt.
Viewkonfiguration-MapperDie Detailansicht wird für das Web-Frontend verwendet.

Wenn kein Eintrag zum Anwendungskontext vorhanden ist und die View auch nicht anderweitig einen Anwendungskontext durch Vererbung von einem übergeordneten Element (View oder ein Panel) erhält, dann ist die View nicht zugeordnet und somit deaktiviert.

Sonderfall: Hierarchie + Objektliste

Ein möglicher Anwendungsfall für die Detailansicht des Knowledge-Builders ist das Anzeigen einer domänenspezifischen Hierarchie mit Objektdetails. In diesem Fall muss für für den Anwendungskontext in der Hierarchieansicht "Knowledge-Builder" eingetragen sein und für die Konfiguration der Details wiederum der Konfigurationsname der Hierarchieansicht. Eine anderweitige Vergabe des Anwendungskontextes in dieser Konstellation kann funktionsbedingt zu einem Endloszyklus in der Viewkonfiguration führen.

2. Ansichten-orientiert Konfiguration

Die zweite Stelle bietet sich an, wenn eine Anwendung von Grund auf zu erstellen ist und viele View-Konfigurationen am Stück erstellt werden wollen. Hierzu befinden sich unter TECHNIK > View-Konfiguration > Objekttypen alle View-Konfigurationselemente, die im Wissensnetz in Verwendung sind bzw. für eine View-Konfiguration neu angelegt werden können.

Für das Konfigurieren eines Web-Frontends ist die Panel-Konfiguration unter TECHNIK > View-Konfiguration > Viewkonfiguration-Mapper zu verwenden. Näheres hierzu unter Kapitel 3 "ViewConfig-Mapper".



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. Kontext / Verwendung von View-Konfigurationen

In welchem Kontext ein View-Konfigurations-Element verwendet wird, wird im Eigenschaften-Editor unter dem Menü-Reiter "Kontext" angezeigt.


Im Kontext-Bereich wird definiert für welche Wissensnetzelemente die View-Konfiguration gültig ist und wo, d.h. in welchen Anwendungen bzw. in welchen anderen View-Konfigurationen sie zur Anzeige kommt:

  • "anwenden auf": Hier ist das Wissensnetzelement anzugeben, für das die View verwendet wird. Wenn die View-Konfiguration am Objekttyp definiert wird, wird der Objekttyp automatisch eingetragen. Es können nach Bedarf weitere Objekttypen angegeben werden
    Beispiel: Wenn die View eine Knoten-Kategorie des Net-Navigators ist, dann kann man bei "anwenden auf" den Objekttyp angeben, zu dem die Objekte dargestellt werden sollen.
  • "anwenden auf Untertypen": Wird gewählt, um den Typ selbst und seine Untertypen mit der Anwendung darzustellen.
  • "anwenden in" spezifiziert den Anwendungskontext, d. h. in welcher Anwendung (meistens: Viewkonfiguration-Mapper oder Knowledge-Builder) oder Konfiguration die View angewendet wird.

Ist keine Anwendung als Verwendung der View-Konfiguration eingetragen, so wird die View-Konfiguration nicht angezeigt mit folgenden Ausnahmen. 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. Eine View-Konfiguration wird auch angezeigt, wenn sie Teil eines Panels ist, welches wiederum in einer Anwendung definiert wird.

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.


"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)
  • Weitere Relationen („Tabelle von“, „Kontext von“,Konfiguration für Metaeigenschaften von“, „Aktion von“, ...) zeigen an in welchen Kontexten eine View-Konfiguration verwendet wird. Eine View-Konfiguration kann in beliebig vielen View-Konfigurationen verwendet werden. Die GĂĽltigkeit von View-Konfigurationen

Im Kapitel Die Verwendung von View-Konfigurationen wurde bereits beschrieben, dass es für 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.7.2 MenĂĽs

Menü-Konfigurationen beinhalten Schaltflächen, sog. Aktionen, über welche der Benutzer unterschiedlichste Funktionen ausführen kann.

Die Menüs bedienen hauptsächlich zwei Funktionalitäten beim Umgang mit Aktionen. Zum Einen können mit ihnen Aktionen gegliedert werden, zum Anderen kann festgelegt werden, wo die Menüs zum Einsatz kommen. Im Knowledge-Builder und ViewConfigMapper gibt es viele Orte, an denen die Inhalte von Menüs angezeigt werden, beispielsweise Knöpfe am Kopf eines Editors oder das Kontextmenü an einer einzelnen Eigenschaften. Derzeit lassen sich noch nicht an alle Stellen, an denen Menüs theoretisch möglich sind, Menüs anbringen.

Im Folgenden werden die direkten Einstellungsmöglichkeiten an einem Menü und die bereits existierenden Menüarten und deren Verwendung beschrieben.

Name Wert
Beschriftung Ob die Beschriftung angezeigt wird, richtet sich nach der Menüart und dem Interface, das sich um die Anzeige kümmert.
Ersetzt Standardmenü Dieser Parameter hat bisher nur Auswirkungen auf den Knowledge-Builder. Bei einigen Editoren, wie z.B. für eine Tabelle, werden Standardmenüs angezeigt. Mit Hilfe dieses Parameters können diese ausgeschaltet werden.

Die Menüart beschreibt die Verwendung des Menüs in den einzelnen Komponenten. Die Menüarten werden weiter unten beschrieben.



Name Wert
Standardaktionen hinzufügen

Dieses Icon wird nur angezeigt, wenn Standardaktionen hinzugefügt werden können. Dies ist aktuell bei einer Tabellen- und Suche-Konfiguration möglich.

Diese Funktion bietet die Möglichkeit, beim gesetzten Parameter Ersetzt Standardmenü wieder einige oder alle Standardmenüeinträge zu reaktivieren und die Reihenfolge der einzelnen Aktionen zu ändern.


  • Ist der Parameter Ersetzt Standardmenü nicht gesetzt, so werden die Aktionen, die in den Menüs enthalten sind, der Reihe nach hinten angefügt.
  • Soll die Reihenfolge der Standardaktionen geändert werden, so muss der Parameter Ersetzt Standardmenü gesetzt sein. Anschließend können die Standardaktionen mit der Aktion Standardaktionen hinzufügen ergänzt werden. Die Standardaktionen können nun beliebig sortiert und mit eigenen Aktionen gemischt werden.



Derzeit lassen sich Kontextmenüs für eine Tabellenzeile und einen Objekteditor erweitern oder neu definieren.


In einer beliebigen Top-Konfiguration eines Elementes können unter dem Reiter Menü Menüs angelegt werden. Auch hier kann das Standardmenü durch das Setzen des Parameters Ersetzt Standardmenü ausgeschaltet werden.


Im Kontextmenü für eine Tabellenzeile gibt es zwei Abschnitte. Der erste bezieht sich auf das ausgewählte Element, der zweite bezieht sich auf die Tabelle. Für die beiden Abschnitte gibt es zwei unterschiedliche Konfigurationsorte. Für den ersten Fall muss das Menü für ein Element mit einer beliebigen, am besten neuen Konfiguration verknüpft werden, die wiederum über anwenden in an die Tabelle, die das Kontestmenü anzeigen soll, gehängt wird. Im zweiten Fall kann das Menü direkt an der Tabelle angebracht werden.

ViewConfigMapper Findet derzeit keine Verwendung im ViewConfigMapper.
"label" : "Menü (Kontext)",
"actions" : [{...}],
"type" : "contextMenu"



Findet nur Anwendung in der Startansicht-Konfiguration. Es werden die konfigurierten Aktionen in einer Liste dargestellt.

Werden für die Menüs Beschriftungen vergeben, werden diese mit angezeigt und bieten somit eine Strukturierungsmöglichkeit.


ViewConfigMapper Findet derzeit keine Verwendung im ViewConfigMapper.
"label" : "Menü (Liste)",
"actions" : [{...}],
"type" : "listMenu"


Knowledge-Builder Die Aktionen, die in den Menüs enthalten sind, werden der Reihe nach angefügt. Eine Unterteilung nach Menüs und eine Beschriftung der Menüs werden derzeit nicht berücksichtigt.
ViewConfigMapper Die Aktionen, die in den Menüs enthalten sind, werden der Reihe nach angefügt. Eine Unterteilung nach Menüs und eine Beschriftung der Menüs werden derzeit nicht berücksichtigt.
"label" : "Menü (Werkzeugleiste)",
"actions" : [{...}],
"type" : "toolbar"
1.7.3 Aktionen

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

Mit Hilfe von Aktionen lassen sich Funktionalitäten in der View-Konfiguration spezifizieren.

Im Knowledge-Builder werden die vollständig konfigurierten Aktionen als zusätzliche Schaltflächen angezeigt. Bei einer Selektion wird das enthaltene Skript ausgeführt.

Im Web-Frontend (Viewkonfiguration-Mapper) werden die konfigurierten Aktionen im Allgemeinen als Schaltflächen dargestellt. Aktionen können in einem Menü zusammengefasst oder direkt für eine View-Konfiguration definiert werden.

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

Die Art der Aktion. Die verschiedenen Arten werden weiter unten erklärt. Ein Skript überschreibt die durch die Aktionsart festgelegte Aktion.

ausführen in View
View, in der die Aktion ausgeführt werden soll.
Benachrichtigung Text der in einer Benachrichtigung 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 fort zu setzen.
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 ü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.
Ursprüngliche Position verwenden . Universell anwendbare Aktionen

Universell anwendbare Aktionen können sowohl im Knowledge-Builder als auch per Viewconfiguration-Mapper im Web-Frontend angewendet werden. Hierzu zählen die Aktionsarten "Graphisch darstellen", "Löschen" und "Suchen". Aktionsart "Graphisch darstellen"

Die Aktion "Graphisch darstellen" wird in einer View-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: Aktionsart "Löschen"

Diese Aktionsart löscht das jeweilige Element.

Im Knowledge-Builder ist die Aktionsart "Löschen" für Objektlisten vorkonfiguriert:

Wie jede Konfiguration im Knowledge-Builder kann auch die Standard-Konfiguration durch eine individualisierte Konfiguration ersetzt werden. In diesem Fall findet die Aktionsart "Löschen" ihre Anwendung.

Löschen durch Aktion mit Skript

Im Web-Frontend ist die Aktionsart "Löschen" unpraktikabel, weil danach das gelöschte Element angezeigt wird - also nichts mehr zu sehen ist. Löschen wird daher im Web-Frontend fast immer durch eine Aktion mit Skript realisiert.

Das Skript zum Löschen eines Elements wird unter dem Eintrag "Skript" der Aktion angelegt:

Die Syntax hierzu sieht bspw. folgendermaßen aus:

function onAction(element, context) {

Eine Anwendungsmöglichkeit hierfür ist das Konfigurieren eines Dialog-Panels zum Anlegen neuer Objekte, dessen Abbrechen-Button das temporär erzeugte Objekt wieder löscht.

Zu beachten ist, dass mit diesem Skript keine Aktionsart für die Aktion ausgewählt werden muss, da das Skript die Aktionsart überschreibt. Aktionsart "Suchen"

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

Diese Aktionsarten können ausschließlich für Konfigurationen im Knowledge-Builder verwendet werden.
Hinweis: Ab KB-Version 5.2.2 sind die KB-spezifischen Aktionsarten nur im Reiter "KB" einer Aktion verfügbar. Aktionsart "Aktualisieren"

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). Aktionsart "Drucken"

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. Aktionsart "Handbuch"

Bei dieser Aktion wird das i-views Web-Handbuch im Browser geöffnet.

Im Gegensatz zur Aktionsart "Web-Link" verweist wie die Aktionsart "Handbuch" auf eine vorkonfigurierte Adresse.


Name Wert
URL Voreingestellter Weblink zum i-views Handbuch. Aktionsart "Homepage"

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


Name Wert
URL Link zu einer Webseite Aktionsart "Im Baum anzeigen"

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. Aktionsart "Suchergebnis-Speichern"

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. Aktionsart "Support-Email"

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 E-mail Link Aktionsart "Web-Link"

Die Aktionsart "Web-Link" ist für die Startansicht des KB verwendbar. Der Unterschied zur Aktionsart "Handbuch" besteht darin, dass eine beliebige Web-Adresse als Hyperlink vergeben werden kann.

Hinweis: In späteren KB-Versionen (KB 5.2.2) ist die Aktionsart "Homepage" nur im Reiter "KB" verfügbar.


Name Wert
URL Adresse des Weblinks. Aktionsart "Zuletzt verwendete Objekte"

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. Aktionsart "Neu"

Die Neu-Aktion legt neue Typen oder neue Objekte des Wissensnetzes an. Im Knowledge-Builder findet die Neu-Aktion bspw. in der Menüleiste von Objektlisten Anwendung.

Hinweis: Im Web-Frontend muss anstatt der Neu-Aktion ein Skript angewendet werden. Siehe hierzu das Kapitel "JavaScript-API". Aktionen fĂĽr den Viewconfiguration-Mapper

Die Aktionen für den Viewconfiguration-Mapper können nur für das Web-Frontend verwendet werden und sie sind in unterschiedliche Aktionsarten eingeteilt. Aktionsart "Anzeigen"

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 die neue View.

Mit "Ergebnis anzeigen in Panel" kann bestimmt werden, in welchem Panel die View angezeigt werden soll.

Der "Aktivierungsmodus" bestimmt das Aktualisierungsverhalten der Ansicht:

Anzeige (Active-Flag und Inhalt)

= "Push-Verfahren"

Die View wird bei Beeinflussung durch die Anzeigen-Aktion oder bei jeglicher Änderung des Inhaltes neu berechnet, unabhängig davon ob das Panel aktiviert (= sichtbar) ist oder nicht.
Dieser Modus ist beispielweise sinnvoll beim Aufrufen eines Dialog-Panels.

Aktualisierung (ohne Flag, nur Inhalt)

= "Delta-Load"

Die View wird nur dann neu berechnet, wenn sich der Inhalt ändert:

  • Wenn das Panel erstmalig aufgerufen wird, dann wird die View neu berechnet.
  • Wenn eine View vorhanden ist, dann wird sie auch bei zwischenzeitlichem Aufrufen eines anderen Panels beibehalten. Die View wird für die Dauer der Sitzung solange "abgespeichert", bis sie durch eine Änderung des Inhalts neu berechnet werden muss.

Ein Beispiel hierfür ist die Anzeige eines Graphen: Solange keine Änderungen am Graph vorgenommen werden, wird bei jedem Aufrufen des Graph-Panels der gleiche, unveränderte Graph angezeigt.

Lazy (Lazy-Flag, kein Inhalt)

= "Pull-Verfahren"

Wenn der Inhalt sich ändert, so wird die View solange nicht neu berechnet, bis das Panel aufgerufen wird. Durch das Setzen des Lazy-Flag wird durch einen gesonderten Request die neue View nur bei Aktivierung des Panels nachgeladen.

Ein Beispiel hierfür ist ein Warenkorb: Die Zusammensetzung eines Warenkorbes kann sich ständig ändern, das Anzeigen des Warenkorb-Inhaltes ist jedoch nur zu bestimmten Zeitpunkten wichtig.

Wenn kein Aktivierungsmodus gewählt wurde, dann gilt per Default der Modus "Anzeige (Active-Flag und Inhalt)". Aktionsart "Auswahl"

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. Aktionsart "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. Aktionsart "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. Aktionsart "NN-Pin"

Ü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. Aktionsart "Speichern"

Die Speichern- 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 Speichern-Aktion kann beipielsweise dazu verwendet werden, um die einzelnen Speichern-Buttons mehrerer Edit-Felder in einem Dialog durch einen individualisierten Speichern-Button zu ersetzen. 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 hier 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
  • Skript-Aktion: Das Vorhandensein eines Skriptes an einer Aktion bewirkt automatisch dessen Ausführung, überschreibt also die eingebaute Funktion der jeweiligen Aktionsart. Skripte von Aktionen Skript (onAction)

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. Einzige Ausnahme bildet die "Auswahl"-Aktion - hier entspricht "element" dem ausgewählten Element, ist also identisch mit "context.selectedElement".
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 ist das automatisch der Fall.

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 (actionVisible)
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 (actionEnabled)
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]);
} Skript mit UI-spezifischen Aktionen

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

Nicht selten möchte man Änderungen zusammenfassen, die der Anwender am Wissensnetz durchführt und die sich in mehrere aufeinanderfolgende Aktionen aufteilen. Beispielsweise wird in einer Aktion ein neues Produkt angelegt und in der nächsten Aktion die Eigenschaften des Produkts beschrieben. Ein Abbrechen der zweiten Aktion würde ein Produkt ohne Beschreibung im Wissensnetz hinterlassen. Gewünscht ist ein Verhalten "Alles oder Nichts", das sicherstellt, dass entweder alle zusammengehörigen Aktionen ausgeführt werden oder keine. Weiterhin möchte man sicherstellen, dass andere Anwender die Veränderung am Wissensnetz erst dann sehen, wenn sie abgeschlossen ist. Ein solches Verhalten erzielt man durch Kapselung der Aktionen in einer "Transaktion".

Um eine Sequenz von Aktionen in einer Transaktion zusammenzufassen, markiert man die erste Aktion mit "Transaktion - beginnen" und die abschließende Aktion mit "Transaktion - beenden". Vorsicht: Die Transaktion wird nur dann begonnen, wenn die erste Aktion auch tatsächlich eine Modifikation man Wissensnetz vornimmt. Das Transaktionsende kann auch dynamisch über die Skriptfunktion "setTransactionCommit()" herbeigeführt werden.

Soll die Transaktion abgebrochen werden, kann man dies mittels einer Aktion der Art "Abbrechen" erzielen. Ein Abbruch bedeutet, dass alle bisherigen Veränderungen am Wissensnetz verworfen werden, die innerhalb der Transaktion getätigt wurden. Über die Skriptfunktion "setFailed()" kann ein Abbruch dynamisch herbeigeführt werden.

Da eine Transaktion immer an die Lebensdauer einer Session gekoppelt ist, wird eine Transaktion automatisch abgebrochen, wenn die Session endet, in der die Transaktion gestartet wurde. Öffnet man zu Beginn der Transaktion beispielsweise einen Dialog und wird dieser geschlossen, bevor die Transaktion beendet wurde, dann wird die Transaktion automatisch abgebrochen. Dies gilt nicht für einen Dialog, der während einer bereits laufenden Transaktion geöffnet wird, denn dies erzeugt eine neue Session auf dem Session-Stapel. Auch Dialog-Sequenzen (dem Schließen eines Dialogs folgt direkt das Öffnen des nächsten Dialogs), unterbrechen die Transaktion nicht.

1.7.4 View-Konfigurationselemente

Eine Viewkonfiguration beschreibt, wie Objekte oder Typen dargestellt werden sollen. Im folgenden werden die verschiedenen Elementarten, die der View-Konfiguration zur Verfügung stehen, beschrieben.

Die einzelnen Viewkonfigurationselemente lassen sich teilweise beliebig zusammenstecken. Ebenfalls können die Konfigurationen mehrfach als Unterkonfiguration verwendet werden.

Liste der verschiedenen Detailkonfigurationstypen


Top-Level-Konfiguration Kann folgende Unterkonfiguration enthalten
Alternative  x  beliebig
Eigenschaften  x  Eigenschaft
Gruppe  x  beliebig
Hierarchie  x  beliebig
Skriptgenerierter Inhalt  x  
Statischer Text    
Suche   Tabelle


Einstellungsmöglichkeiten, die alle Detailkonfigurationstypen gemeinsam haben

Name Wert
Konfigurationsname Findet keine Verwendung im Userinterface. Der Ersteller einer Konfiguration hat hier die Möglichkeit einen für ihn verständlichen Namen zu vergeben, um diese Konfiguration später besser wiederfinden und in anderen Konfigurationen wieder verwenden zu können.
Skript für Fenstertitel

Nur zur Verwendung im Knowledge-Builder. Öffnet man ein Objekt beispielsweise per Doppelklick in der Objektliste, öffnet sich ein Fenster mit den Eigenschaften dieses Objektes. Der Titel dieses Fensters kann durch ein Skript bestimmt werden.

Anmerkung: In den folgenden Abschnitten werden die Einstellungsmöglichkeiten für die einzelnen Konfigurationstypen beschrieben. Die obligatorischen Parameter sind fett gedruckt. Alternative

Eine Alternative wird verwendet, um beliebig viele verschiedene alternative Ansichten auf ein Objekt zu konfigurieren. Zwischen den Ansichten kann in der Anwendung mittels Reitern gewechselt werden.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. einer weiteren Alternative eingebettet ist.
hat Default-Alternative Die Unteransicht, die initial selektiert sein soll, kann hier festgelegt werden.


Darstellung in einer Anwendung

Wenn die Ansichten in JSON herausgeschrieben werden,  so werden die einzelnen Unteransichten in einem ARRAY an den KEY alternatives gehängt.

Beispiel einer Alternative in einer Anwendung: Mittels der Reiter kann zwischen den Ansichten "Beispiel", "Branchen" und "Eigene Daten anlegen" gewechselt werden.


Darstellung im Knowledge-Builder

Im Knowledge-Builder werden dem Anwender die verschieden konfigurierten und mit der Alternative verknüpften Ansichten eines Objekts durch Reiter zur Verfügung gestellt.

Beispiel einer Alternative im Knowledge-Builder: Mittels der Reiter kann zwischen der Ansicht "Reiter 1" und der Ansicht "Reiter 2" gewechselt werden.

Konfiguration von Reitern

Wenn eine View-Konfiguration vom Typ "Alternative" erstellt wurde, kann über den Button "Objekte von Objektkonfiguration neu anlegen" ein neuer Reiter hinzugefügt werden.

Meistens empfiehlt es sich, als Reiter den View-Konfigurationstyp "Gruppe" zu verwenden, da sich hierin beliebige andere View-Konfigurationen platzieren lassen. Die Beschriftung der View-Konfiguration ist gleichzeitig auch die Beschriftung des Reiters. Gruppen

Mit Hilfe einer Gruppe lassen sich verschiedene Unterkonfigurationen in einer Ansicht zusammenfassen. Die Unterelemente werden dann der Reihe nach dargestellt. Es gibt jedoch Ausnahmen, die nur für das Front-End gelten: Das Konfigurationselement Eigenschaft kann keine direkte Unterkonfiguration von Gruppe sein. Hierfür braucht es zunächst die Konfiguration Eigenschaften.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.

Darstellung in einer Anwendung

Wird die Ansicht in JSON herausgeschrieben, werden die einzelnen Unteransichten in einem ARRAY an den KEY group angehängt.

Darstellung im Knowledge-Builder

Im Knowledge-Builder wird um eine Gruppe ein Rahmen gezeichnet. Die Ansichten der Unterkonfigurationen werden dann in diesem Rahmen angezeigt.

Eine Gruppe mit folgenden Unterkonfigurationen: der Eigenschaftsliste "Bild und Text", der Eigenschaftsliste "Eigenschaften" und der Suche "Ähnliche Sehenswürdigkeiten" Hierarchie

Der Konfigurationstyp "Hierarchie" stellt Elemente eines semantischen Modells hierarchisch in einer Baumstruktur dar, in der einzelne Äste auf- und zugeklappt werden können.

Es kann entweder mit Relationen oder Relationszielen gearbeitet werden. Der Aufbau der Hierarchie geschieht vom Startelement der View-Konfiguration aus, zu dem zunächst alle untergeordneten Relationen bzw. Objekte und deren Untergeordnete ermittelt werden. Danach werden für jedes Element die übergeordneten Relationen bzw. Objekte ermittelt. Diese Ergebnismenge von Elementen wird dann in der Hierarchie dargestellt.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Skript für Beschriftung Es ist auch möglich durch ein Skript eine Beschriftung festzulegen.
Banner der Hierarchiewurzel anzeigen Betrifft nur den Knowledge-Builder: Banner wird angezeigt.
Aktion (Auswahl) Verweis auf eine Aktion, die beim Anklicken eines Hierarchie-Elements aufgerufen wird.
Detailansicht ausblenden Standardmäßig wird die Detailansicht eines ausgewählten Objektes angezeigt (Knowledge-Builder) oder ausgegeben (json, als subview). Durch Aktivieren dieser Option wird keine Detailansicht angezeigt bzw. ausgegeben.
Skript für Sichtbarkeit  
Unterelemente erzeugen ohne Frage nach Namen Wenn neue Unterelemente in der Hierarchie erzeugt werden, wird standardmäßig gefragt, wie ihr Name lauten soll. Ein Häkchen hier, erzeugt ohne Frage nach Namen namenlose Objekte.
Verbiete manuelles Sortieren Standardmäßig kann der Anwender im Knowledge Builder Elemente dem Schema entsprechend durch Drag&Drop umhängen. Wird diese Option aktiviert, ist dies nicht mehr möglich.

Einstellungsmöglichkeiten für die Sortierung

Name Wert
Absteigend sortieren Steuert, ob auf- oder absteigend sortiert wird. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert.
Primäres Sortierkriterium

Auswahlmöglichkeit für das Kriterium, nach dem die Eigenschaften sortiert werden:

  • Position: Die in der Konfiguration festgelegte Reihenfolge wird verwendet (Default).
  • Wert: Inhalt des Attributes bzw. Anzeigename des Relationszieles wird verwendet.
  • Skript für Sortierung: Das in dem Attribut Skript zur Sortierung hinterlegte Skript wird zur Ermittlung des Sortierkriteriums verwendet.
Sekundäres Sortierkriterium Sortierkriterium für Eigenschaften, die für das primäre Sortierkriterium den gleichen Wert haben. Einstellmöglichkeiten analog zum Primären Sortierkriterium.
Skript für Sortierung Verweis auf ein registriertes Skript, das den Sortierschlüssel für das primäre bzw. sekundäre Sortierkriterium zurückgibt.

Ermittlungsmöglichkeiten der hierarchiebildenden Elemente

Name Ermittlung von ...
Relation (absteigend) Unterelementen
Relation (aufsteigend) Oberelementen
Strukturabfrage (absteigend) Unterelementen
Strukturabfrage (aufsteigend) Oberelementen
Skript (absteigend) Unterelementen
Skript (aufsteigend) Oberelementen

Aktionen und Styles

Es lassen sich sowohl für die gesamte Hierarchie als auch für die einzelnen Knoten Aktionen und Styles anbringen. Ab Version 5.2 kann man auch automatisch Style-Klassen über ein Skript zuweisen lassen.

Darstellung in einer Anwendung

Erst ab Version 4.1 gibt es die JSON-Repräsentation einer Konfiguration vom Typ Hierarchie.

Darstellung im Knowledge-Builder

In der Detail-Anzeige eines Elements wird im linken Bereich eine Hierarchie eingeblendet. Im rechten Bereich wird das Element mit einer View-Konfiguration ohne Hierarchie angezeigt. Diese View-Konfiguration muss eigens definiert werden und unter Verwendung >> anwenden in muss der Konfigurationsname der Hierarchie angegeben werden. Die Subkonfiguration lässt sich alternativ auch direkt an der Hierarchie unter Subkonfiguration angeben.


  • Elemente werden in Hierarchien immer mit ihrem Namen repräsentiert. Es ist nicht möglich etwas anderes als den Namen oder zusätzlich zum Namen Informationen direkt in der Hierarchie anzuzeigen. 
  • Die Werte aller Eigenschaften, die für die Hierarchiebildung ausgefüllt werden können, sind Relationen.
  • Die einzelnen Attribute wie z.B. Relation - absteigend können mehrfach vergeben werden.
  • Für jeden Attributtyp werden die Relation oder Relationen ermittelt und aufgesammelt. Sind verschiedene Attributtypen angegeben, wird mit den Teilmengen eine Schnittmenge gebildet.

Beispiel - Anwendungsfall

Typischerweise werden Hierarchien verwendet, um Ober-/Unterthema-Relationen oder Teil-von-Relationen darzustellen.

1. Hierarchiebildende Relation

Die direkteste Variante. Die Relationen, die die Hierarchie bilden, werden eingetragen.

2. Hierarchiebildende Strukturabfrage

Die Relationen lassen sich ebenfalls über eine Strukturabfrage ermitteln.

3. Hierarchiebildendes Skript

Auch durch ein Skript lassen sich die möglichen hierarchiebildenden Relationen aufsammeln. Es bekommt das aktuelle Element als Parameter übergeben und muss eine Menge an Relationen zurückgeben. Statt auf Relationen kann man aber auch auf Elementen arbeiten.

Skript hat Oberthema

function relationsOf(element)
    return element.relations('hatOberthema');
function targetsOf (element) 
    return element.relationTargets('hatOberthema');
} Baum

Ebenso wie die "Hierarchie" dient der "Baum" der Konfiguration einer hierarchischen Baumstruktur. Im Gegensatz zur Hierarchie kann ein Baum auch statische Knoten enthalten. Es ist somit möglich, einen Baum ohne ein Wissensnetz-Ausgangselement zu bilden. Ein weiterer Unterschied besteht darin, dass die Unterknoten eines "Baums" verschiedenartig konfiguriert sein können, während sich alle Knoten einer "Hierarchie" für ein gegebenes Wissensnetzelement gleichartig verhalten.

Die Baumkonfiguration kennt grundsätzlich zwei Arten von Knoten:

  • Statischer Hierarchieknoten: Knoten dieses Typs sind immer vorhanden, sofern eine Verbindung zur Baumwurzel existiert. Über die Relation "Kontextelement" kann der Knoten optional an ein Wissensnetzelement gebunden werden. Achtung: Der oberste Knoten des Baums ist immer statisch und immer unsichtbar.
  • Hierarchie-Knotenmuster: Dieser Typ kann pro Ebene mehrere Knoten ausbilden. Je Relationsziel, welches sich vom Element des übergeordneten Knotens ausgehend erreichen lässt, wird ein Knoten ausgebildet. Über Setzen der Eigenschaft "Transitiv" können mehrere Ebenen ausgebildet werden. Durch das Setzen der Eigenschaft "anwenden auf", kann eingeschränkt werden, auf welche Elementtypen das Knotenmuster anwendbar ist - ansonsten kann das Knotenmuster auf alle Elemente angewendet werden, die im Ziel-Gültigkeitsbereich der konfigurierten Relationen liegen.

Analog zur "Hierarchie" kann die Sortierung der Baumknoten konfiguriert werden. Diese Konfiguration wirkt allerdings nicht für den Baum global sondern je Knotenkonfiguration für dessen Unterknoten.

Schließlich sind angezeigtes Bild und Beschriftung pro Knotentyp wahlweise direkt oder per Skript konfigurierbar. Eigenschaften

Die Konfiguration Eigenschaften ist eine Liste von einzelnen Eigenschaften. Die Unterkonfigurationen können ausschließlich vom Typ Eigenschaft sein, welche jeweils mit einem Attribut oder einer Relation eines Wissensnetz-Objekts oder -Typs verknüpft ist.


Name Wert
Beschriftung Anzeigename der Sammlung von Eigenschaften. Ist keine Beschriftung angegeben wird im Knowledge-Builder die Zeichenkette 'Eigenschaften' verwendet.
Skript für Beschriftung Alternativ kann der Anzeigename auch über ein Skript ermittelt werden.
Skript für Sichtbarkeit Steuerung der Sichtbarkeit der Eigenschaften durch ein Skript.
Initial ausgeklappt

Ist diese Konfiguration z.B. als Metakonfiguration eingehängt, kann mit diesem Parameter bestimmt werden, ob diese beim Öffnen des Knowledge-Builder-Editors bereits ausgeklappt sein soll.

Hinweis: Das Web-Frontend stellt die betroffene Metaeigenschaft nicht dar, wenn der Haken hier nicht gesetzt ist.

Einstellungsmöglichkeiten für die Sortierung

Name Wert
Absteigend sortieren Steuert, ob auf- oder absteigend sortiert wird. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert.
Primäres Sortierkriterium

Auswahlmöglichkeit für das Kriterium, nach dem die Eigenschaften sortiert werden:

  • Position: Die in der Konfiguration festgelegte Reihenfolge wird verwendet (Default).
  • Wert: Inhalt des Attributes bzw. Anzeigename des Relationszieles wird verwendet.
  • Skript zur Sortierung: Das in dem Attribut Skript zur Sortierung hinterlegte Skript wird zur Ermittlung des Sortierkriteriums verwendet.
Sekundäres Sortierkriterium Sortierkriterium für Eigenschaften, die für das primäre Sortierkriterium den gleichen Wert haben. Einstellmöglichkeiten analog zum Primären Sortierkriterium.
Skript zur Sortierung Verweis auf ein registriertes Skript, das den Sortierschlüssel für das primäre bzw. sekundäre Sortierkriterium zurückgibt.

Darstellung in Anwendungen

Die Ansichten der Konfiguration einzelner Eigenschafts-Elemente werden beim Herausschreiben im JSON-Format in einem ARRAY abgelegt und mit dem KEY properties angehängt.

Darstellung im Knowledge-Builder

Die in der Konfiguration eingestellte Beschriftung wird prominent angezeigt. Ihm folgen die Ansichten der konfigurierten Eigenschaften.


Meta-Eigenschaften werden mit dem gleichen Vorgehen angehängt. Eigenschaft

Mit der View-Konfiguration Eigenschaft können einzelne Attribute oder Relationen definiert werden, die in einer Eigenschaften-Liste angezeigt werden sollen. Es kann auch eine abstrakte Eigenschaft benutzt werden, die eine Menge von Eigenschaften zusammenfasst.


Name Wert
Absteigend sortieren Steuert, ob die Eigenschaften auf- oder absteigend nach ihrem Namen sortiert werden. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert.

Steht in zwei Fällen zur Verfügung:

1. Die Eigenschaft ist eine Relation:

Auswahlmöglichkeit für die Darstellung der Beschriftung eines Relationsziels. Diese Einstellungsmöglichkeit steht nur dann zur Verfügung, wenn die Einstellung Relationszielansicht den Wert Auswahl oder Relationsstruktur hat.

2. Die Eigenschaft ist ein Datei-Attribut:

Auswahlmöglichkeit für die Darstellung des Wertes eines Datei-Attributs.


  • Symbol (topicIcon): Icon des Relationsziels/die Datei als Icon
  • Symbol und Zeichenkette
  • Zeichenkette (Namensattribut): Name des Relationsziels/Name der Datei
Beschriftung Anzeigename der Eigenschaft. Ist keine Beschriftung angegeben wird der Name des Eigenschaftstyps ausgegeben.
Eigenschaft Verknüpfung zu einem Eigenschaftstyp, der angezeigt werden soll.
Skript für virtuelle Eigenschaften

Alternativ zu 'Eigenschaft': Skript zur Berechnung anzuzeigender Werte.

Durch Setzen des Meta-Flags "Automatisch aktualisieren", erreicht man im KB eine automatische Aktualisierung, wenn sich ein Wert, auf dessen Basis die Berechnung erfolgte, verändert. Vorsicht: das Setzen des Flags kann sich - abhängig vom Skript - signifikant auf die Performance auswirken.

Einblendung des Relationsziels

Steht nur bei Relationen zur Verfügung.

Standardmäßig wird lediglich der Name des Relationsziels angezeigt. Wird der Name angeklickt, öffnet sich das Relationsziel in einem weiteren Editor.

Wird hingegen die Option Einblendung des Relationsziels gewählt, werden die Relationsziele direkt angezeigt, d.h. nicht nur ihr Name, sondern alle ihre Eigenschaften.

Einblendung zusätzlicher Eigenschaften

Nur bei der Ansicht zum Bearbeiten von Objekten relevant: Ist diese Option gesetzt, wird zu der Eigenschaft eine weitere Eigenschaft eingeblendet, sodass diese bequem und schnell ausgefüllt werden kann. Die Eigenschaft muss mehrfach vorkommen dürfen.

Einblendung neuer Eigenschaften

Nur bei der Ansicht zum Bearbeiten von Objekten relevant: Ist diese Option gesetzt, wird die Eigenschaft nur dann eingeblendet, wenn die Eigenschaft noch nicht angelegt wurde. So kann sie bequem und schnell ausgefüllt werden und wird nicht so leicht vergessen.


Nur bei der Ansicht zum Bearbeiten von Objekten relevant: Mit dieser Option kann eine Verknüpfung zur einer Abfrage angelegt werden, die entscheidet, ob diese Konfiguration angezeigt wird. Die Abfrage wird mit dem Objekt dieser Eigenschaft gefüllt. Nur, wenn die Abfrage ein Ergebnis enthält, wird die Eigenschaft zum Bearbeiten angezeigt.
Konfiguration für eingebettete Metaeigenschaften

Angabe der Konfiguration, die verwendet werden soll, um Metaeigenschaften anzuzeigen. Die Metaeigenschaften werden eingebettet, d.h. hinter dem Wert der Eigenschaft angezeigt. Der Name des Eigenschafttyps wird nicht angezeigt.

Konfiguration für Metaeigenschaften

Angabe der Konfiguration, die verwendet werden soll, um Metaeigenschaften anzuzeigen. Die Metaeigenschaften werden unter dem Wert der Eigenschaft angezeigt.

Für die Anzeige im Web-Frontend müssen die Eigenschaften mit den Metas auf "initial ausgeklappt" eingestellt sein.


Wird als Eigenschaft eine Relation gewählt, kann mit diesem Parameter die Ansicht der Relationsziele definiert werden:

  • Auswahl: Alle Relationsziele werden aufgelistet und mit einer vorangestellten Checkbox angezeigt. Bei bestehenden Relationen ist die CheckBox mit einem Häkchen versehen.
  • Drop Down: Diese Einstellung ist nur sinnvoll, wenn die Relation nur einmal vorkommen darf. Es wird eine Drop Down-Liste mit allen möglichen Relationszielen zur Auswahl angezeigt.
  • Relationsstruktur: Alle Relationsziele werden im linken Bereich aufgelistet, ähnlich einer Hierarchie. Im rechten Bereich ist dann die Detailansicht des selektierten Relationsziels zu sehen. Diese Ansicht kommt nur zur Geltung, wenn die Konfiguration direkt einer Top-Level-Konfiguration untergeordnet ist.
  • Tabelle: Tabellenansicht der Relationen. Die Tabellenansicht kann nicht im Knowledge-Builder angewendet werden. Für die Tabellenansicht muss die Einstellung Tabelle ausgefüllt werden.
  • Tabelle (Relationsziele): Tabellenansicht der Relationsziele. Diese Tabelle kann im Knowledge-Builder angewendet werden.
Skript für Beschriftung Die Beschriftung kann durch ein hier angegebenes Skript ermittelt werden.
Skript für Relationszielbezeichner

Über dieses Skript kann für Relationen gesteuert werden, wie das Relationszeil dargestellt wird. Wenn kein Skript eingetragen ist, wird der Objektname des Relationsziels zur Darstellung verwendet.

Anwendungsbeispiel: Eine Person gehört zu einer Abteilung mit Namen 'Abt. IV'. Durch ein passendes Skript kann erreicht werden, dass in der Anzeige bei der Person statt 'Abt. IV' die Angabe 'Stadtverwaltung Darmstadt, Abt. IV' erscheint.

Skript für Sortierung Anhand des Skriptes wird ein Wert, nach dem sortiert wird, ermittelt. Siehe Beispiel unten.
Suche zur Zielauswahl Die Suche bestimmt, welche Wissensnetzelemente als mögliche Relationsziele angeboten werden. Zur Konfiguration der Suche, siehe auch Kapitel Suchen/Abfragen.
Tabelle Steht nur zur Verfügung, wenn Relationszielansicht den Wert Tabelle, bzw. Tabelle (Relationsziele) hat und ist dann obligatorisch. Die hier angegebene Tabellenkonfiguration gibt an, welche Eigenschaften der  Relationsziele tabellarisch ausgegeben werden sollen. Um das Relationsziel anzuzeigen muss mindestens sein Name in der Tabelle konfiguriert werden. Zur Konfiguration einer Tabelle, siehe Kapitel Tabelle.

Beispiel für Skript für Sortierung

Vorbedingung: An allen Eigenschaften kann das Attribut sortKey angebracht werden.

function sortKey(element)
    if (element instanceof $k.Property)
        var attribute = element.attribute('sortKey')
        if (attribute)
            return attribute.value();
    if (element instanceof $k.Domain)
        var attribute = element.type().attribute('sortKey');	
        if (attribute)
            return attribute.value();
    return undefined;

Eigenschaftsanzeige einer Person

Konfiguration einer Eigenschaft

Eine Eigenschaft kann nur als Teil einer Eigenschaftenliste konfiguriert werden. Es ist in Ordnung, wenn die Liste nur eine Eigenschaft enthält.

In diesem Beispiel enthält die Eigenschaften-View-Konfiguration bereits die Eigenschaft "Name". Eine zweite Eigenschaft wird angelegt, wenn bei "Eigenschaft" (orange markiert) ein Attribut oder eine Relation ausgewählt wird.


Beim Attributtyp Name ist für sortKey der Wert 3 eingetragen, daher steht dieser vorläufige Wert am Ende der Liste. Edit

Dieser Konfigurationstyp wird benutzt um Attribute und Relationen einer Eigenschaften-Konfiguration editierbar zu machen. Dazu wird er dem jeweiligen Eigenschaften-Element übergeordnet. Neben einem Knopf zum Speichern der Änderungen, wird neben jeder Eigenschaft, bei der dies möglich ist, ein Löschen-Knopf angezeigt.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Editiermodus umschaltbar Wird diese Option ausgewählt, werden die Eigenschaften zunächst nur als normale Liste angezeigt. Zusätzlich wird jedoch ein Schalter angeboten, mit dem man zwischen der normalem und der Editieransicht umschalten kann.
Nur benutzerdefinierte Schaltflächen Ist diese Option gesetzt, wird der Speichern-Knopf nicht angezeigt. Tabelle

Tabellen können als Unterkonfiguration für die Ergebnisanzeige von Abfragen des Konfigurationstyps "Suche" oder als eigenständige Konfiguration zur Darstellung der Objektlisten im Knowledge-Builder verwendet werden.

Eine Tabelle listet konkrete Objekte, Eigenschaften oder Untertypen eines bestimmten Typs auf. Ob alle Objekte, Eigenschaften oder Untertypen oder nur eine Auswahl angezeigt werden, lässt sich über die Eingabe in den Spaltenköpfen steuern. Mit den eingegebenen Werten wird eine Strukturabfrage nach passenden Objekten, Eigenschaften oder Untertypen ausgeführt und das Ergebnis tabellarisch dargestellt. Außerdem kann bei Objektlisten nach Eingabe von Werten in die Spaltenköpfe ein neues Objekt, ein neuer Eigenschaftswert oder ein neuer Untertyp mit den ausgefüllten Eigenschaften erzeugt werden.

Bestandteile der Konfiguration Tabelle sind Spaltenkonfigurationen. Diese wiederum beinhalten Spaltenelemente. Diese Aufteilung dient der Trennung von spaltenrelevanten Eigenschaften, wie Reihenfolge und Benennung der Spalte in der Tabelle, und der Zuordnung, welche Inhalte in der Spalte angezeigt werden sollen. Spaltenelemente wiederum erlauben die Zuordnung von Eigenschaften, zusätzlich können Skript-Bausteine und Strukturabfrage-Bausteine eingebettet werden.

Seit Version 5.1. lassen sich in eine Tabellen-Konfiguration nicht nur Spaltenkonfigurationen einfügen, sondern auch weitere Tabellen. Dies bietet die Möglichkeit Spalten, die öfter Verwendung finden, in einer Tabellen-Konfiguration zusammenfassen und diese komplett in eine andere Tabelle einzuhängen. Bei der Ermittlung der Gesamttabelle werden die Zwischen-Tabellen entfernt. Es gibt nur eine Ebene von Spalten.

Die hierarchische Darstellung aller Unterkonfigurationselemente der Tabellenkonfiguration weist eine Menü-Zeile auf, die wie folgt mit Aktionen belegt ist:

  •  Neues Unterelement anlegen und verknüpfen.
  •  Bereits vorhandene mögliche Unterelemente durchsuchen und verknüpfen
  •  Verknüpfung wieder löschen. Das Unterelement bleibt dabei als Objekt erhalten und kann in anderen Konfigurationen wieder verwendet werden.
  •  Gewähltes Unterelement komplett löschen. Falls es in anderen Konfigurationen verwendet wird, öffnet sich vor der Löschung eine Warnung, die alle vorhandenen Verknüpfungen aufzeigt.
  • Gewähltes Unterelement in der Liste nach oben schieben.
  • Gewähltes Unterelement in der Liste nach unten schieben.
  •  Aktualisierung. Erst nach einer Aktualisierung werden alle Änderungen für die Anwendungen übernommen.


Beispiel einer einfachen Tabellenkonfiguration

Zu einer Liste von Sehenswürdigkeiten soll der Ort, an dem sie sich befinden, Themen, mit denen sie zu tun haben und Reisen, bei denen sie besucht werden in einer Tabelle zu sehen sein. Nicht zu vergessen ist das Namensattribut, durch das die Sehenswürdigkeiten in der ersten Spalte repräsentiert werden.


Einstellungsmöglichkeiten (Tabelle)

Name Wert
Anzahl Zeilen (Page size) Gibt an, wie viele Zeilen auf einer Seite angezeigt werden sollen. Standardwert: 20
Keine automatische Suche Es wird keine automatische Suche durchgeführt.
Namenlose Unterelemente erlauben Namenlose Unterelemente werden ebenfalls angezeigt.
Ohne Sortierung Es findet keine Sortierung statt. Standardverhalten: es wird nach der ersten Spalte sortiert.

Durch Angabe einer Ganzzahl lässt sich steuern an welcher Stelle, falls mehreren Konfigurationen vom Typ Tabelle angezeigt werden sollen, die aktuelle Konfiguration angezeigt wird.

Die Sortierung wird nach zwei Kriterien durchgeführt, die in der folgenden Reihenfolge überprüft werden:

  1. Attribut Reihenfolge vorhanden, wenn ja, dann wird dieses als Sortierkriterium verwendet, wenn nein, werden erst die Konfigurationen für Typen und dann die für Objekte angezeigt.
  2. Sortierung nach Anzeigename

Aktionen und Styles

Aktionen und Styles lassen sich für die gesamte Tabelle, aber auch für Zeilen festlegen.


Wo die Tabelle zur Verwendung kommt, wird auf dem Reiter Verwendung angegeben.

Unter anwenden auf wird der Objekttyp angegeben, auf den die Tabelle angewendet werden soll. Tabellen können in anderen View-Konfigurationen wieder verwendet werden. Falls die Tabelle Baustein einer anderen View-Konfiguration ist, wird dies unter [inverse] anwenden in angezeigt.

Die Eigenschaft anwenden in verweist auf eine Anwendung. Mehrere Verknüpfungen sind möglich.


  • Soll die Tabelle im Knowledge-Builder rechts im Hauptfenster bei der Navigation durch die Ordnerstruktur verwendet werden, dann muss die Tabellenkonfiguration mit dem entsprechenden Ordnerstrukturelement verknüpft sein.
  • Sollen mögliche Relationsziele im Knowledge-Builder tabellarisch dargestellt werden, dann muss die Tabelle mit der Anwendung Knowledge-Builder verknüpft sein.

Tabellen / Objektslisten im Knowledge-Builder

Für die Konfiguration der tabellarische Darstellung von Objekten oder Typen im Knowledge-Builder findet sich im Reiter Details beim jeweiligen Typen der Abschnitt View-Konfiguration -> Objekt/Typ -> Objektliste. Das Erstellen und Pflegen der Tabellen-Konfiguration wird am Beispiel der Objekte des Typs Thema erläutert.

Objekte vom Typ Thema bieten selbst als zusätzliche Eigenschaften Synonym und die Relation ist Thema von an. Diese Eigenschaften, zusammen mit dem Namen des Themas sollen die Bestandteile der zu bauenden Tabelle ergeben.

Der Typ Thema wird bearbeitet, in der Ansicht wird der Reiter Details gewählt und hier der Punkt View-Konfiguration -> Objekt -> Objektliste angeklickt.

Noch wurde keine Tabellenkonfiguration mit diesem Typ verknüpft. Durch Klicken auf den Knopf Neu wird eine neue, leere Konfiguration erzeugt. Diese kann dann selektiert und wie oben beschrieben bearbeitet werden.

Einstellungsmöglichkeiten für die Sortierung

Name Wert
Absteigend sortieren Steuert, ob auf- oder absteigend sortiert wird. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert.
Primäres Sortierkriterium

Auswahlmöglichkeit für das Kriterium, nach dem die Eigenschaften sortiert werden:

  • Position: Die in der Konfiguration festgelegte Reihenfolge wird verwendet (Default).
  • Wert: Inhalt des Attributes bzw. Anzeigename des Relationszieles wird verwendet.
  • Skript zur Sortierung: Das in dem Attribut Skript zur Sortierung hinterlegte Skript wird zur Ermittlung des Sortierkriteriums verwendet.
Sekundäres Sortierkriterium Sortierkriterium für Eigenschaften, die für das primäre Sortierkriterium den gleichen Wert haben. Einstellmöglichkeiten analog zum Primären Sortierkriterium
Skript zur Sortierung Verweis auf ein registriertes Skript, das den Sortierschlüssel für das primäre bzw. sekundäre Sortierkriterium zurückgibt. Spaltenkonfigurationen

Wie bereits erwähnt, tragen Spaltenkonfigurationen Eigenschaften, die der Festlegung der Darstellung und des Verhaltens der Spalte in der Tabelle dienen. Erst wenn Eigenschaften an den in der Spaltenkonfiguration enthaltenen Spaltenelementen konfiguriert werden, wird die Spalte angezeigt.


Name Wert

Wird in der Titelzeile der Spalte angezeigt. Hierbei ist zu beachten, dass Beschriftung der Anzeige in der Tabelle dient, die Spaltenkonfiguration aber zusätzlich noch das Attribut Konfigurationsname enthält. Dieser Name dient allein der Verwaltung und dem Auffinden der Konfiguration in der semantischen Graph-Datenbank und wird nicht angezeigt oder ausgegeben.

Breite der Spalte (%) Für die Breite der Spalte wird hier ein prozentualer Wert erwartet (für 60% muss also "60" eingegeben werden).
Nicht anzeigen Ist dieser Wert gesetzt, wird die komplette Spalte nicht angezeigt. Dies dient dazu z.B. eine Suche mit den Werten dieser Spalte durchzuführen. Der Anwender soll aber nicht die Möglichkeit haben Veränderungen an dieser Spalte vorzunehmen.
Obligatorisch für Abfrage Ist dieser Wert gesetzt, muss die Spalte ausgefüllt sein, um suchen zu dürfen.
Sortierpriorität Nach der Spalte mit Sortierpriorität 1 wird primär sortiert. Bei gleichen Werten wird nach der Spalte mit der nächst höheren Sortierpriorität sortiert usw. Die Standardsortierreihenfolge ist aufsteigend. Um absteigend zu sortieren negiert man die Sortierpriorität oder setzt das Meta-Attribut "Absteigend sortieren".
Standard-Operator Operator, der initial bei der Suche für einen Suchtext angewendet wird.
Suchtext Initial kann eine Spalte mit einem Suchtext versehen werden.


Spaltenkonfiguration für die Spalte Name Spaltenelemente

Ein Spaltenelement dient der Zuweisung, welche Inhalte eine Tabellenspalte darstellen soll und wie dies zu geschehen hat. Es können entweder an den semantischen Objekten definierte Eigenschaften wie Attribute und Relationen spezifiziert oder Strukturabfrage-Bausteine oder Skript-Bausteine verwendet werden.


Name Wert


(obligatorisch oder Skript)

Verknüpfung zu einem Eigenschaftstyp, der angezeigt werden soll.


(obligatorisch oder Eigenschaft)

Ausführen des Skripts cellValues zur Ermittlung der Werte, die angezeigt werden sollen.
Nicht anzeigen Über dieses boolesche Attribut kann gesteuert werden, ob Werte der ausgewählten Eigenschaft angezeigt werden sollen. Standardmäßig werden alle Eigenschaften angezeigt.
Nicht anlegen

Dieses Attribut steuert, ob diese Eigenschaft beim Erzeugen eines neuen Objekts erzeugt werden soll, falls das entsprechende Eingabefeld der Spalte einen Wert enthält. Standardmäßig werden neue Eigenschaften erzeugt.

Nicht suchen

Hier kann eingestellt werden, dass die konfigurierte Eigenschaft nicht in die Suche übernommen wird. D.h. eingegebene Suchwerte werden nicht über diese Eigenschaft gesucht.

Achtung: Wenn alle Spaltenelemente einer Spalte auf "Nicht suchen" geschaltet werden, hat dies denselben Effekt wie "Nicht anzeigen"!

Hervorhebung Hier können für das Anzeigen von Werten Formatierungsvorgaben gemacht werden, zur Wahl steht derzeit nur Unterstreichen.
Hits verwenden Standardmäßig werden Objekte erzeugt. Möchte man allerdings in dem Skript cellValues die Hits weiterverarbeiten, muss Hits verwenden eingeschaltet werden.

Derzeit steht nur die Alternative Drop down zur Verfügung. Wird diese ausgewählt, so werden die möglichen Werte, die sich für die Filterung in der Tabelle für diese Spalte eintragen lassen, aus den möglichen Relationszielen gemäß Schema als Dropdown-Liste zusammengestellt, so dass ein möglicher Wert schnell spezifiziert werden kann. Dies empfiehlt sich für überschaubare Mengen an möglichen Relationszielen.

Anmerkung: Dieser Parameter steht nur zur Verfügung, wenn eine Eigenschaft vom Typ Relation gewählt wurde.

Es ist möglich für eine Spaltenkonfiguration mehrere Spaltenelemente zu definieren. Das ist z.B. dann sinnvoll, wenn mehrere Attribute in der Suche berücksichtigt werden sollen wie beispielsweise das Attribut Name und Synonym, aber nur eines davon angezeigt werden soll.


Im ersten Spaltenelement der Spaltenkonfiguration Name wurde das Attribut Name hinterlegt.

Auf der zweiten Spalte wurde im Spaltenelement die Beziehung ist Thema von hinterlegt.

Auf der dritten Spalte wurde im Spaltenelement der Strukturabfrage-Baustein transitive Beziehungskette vom Thema nach oben hinterlegt.

Hinterlegte Struktur-Abfrage

Um Werte aus dem Eingabefeld der Spalte übernehmen zu können, muss die hinterlegte Strukturabfrage konfigurierte Parameter haben. Es können mehrere Parameter angebracht werden, diese sind beim Auswerten der Strukturabfrage alle mit demselben Wert belegt.

Vorsicht: Hier liegt ein Unterschied zu sonstigen Fällen, in denen die Strukturabfrage verwendet wird. Normalerweise bestimmt das Ausgangsobjekt (in diesem Fall wäre dies "Thema") die Ergebnisse, hier sind es jedoch die Objekte oder Eigenschaften, an denen der Parameter angebracht ist (in diesem Fall das Namensattribut).

Der in der Spalte gezeigte Wert ist, wenn keine weiteren Anpassungen vorgenommen werden, der Wert des zum Filtern verwendeten Attributes. Wenn sich der angezeigte Wert nicht aus dem zur Filterung verwendeten Attribut ergibt, so gibt es zwei Möglichkeiten:

  • der Bezeichner "renderTarget" kann an Relationszielen angebracht werden. Die hiermit markierten Objekte werden als Spaltenwert in der Tabelle angezeigt.
    "renderTarget" bewirkt außerdem, dass bei einer Ausgabe über die JavaScript API die Eigenschaften zur Darstellung als Link mit ausgegeben werden.
  • der Bezeichner "renderProperty" kann an Attributen angebracht werden. Die hiermit markierte Eigenschaften werden als Spaltenwerte in der Tabellenspalte angezeigt.

Wird der Suchbaustein nicht zur Filterung verwendet, so muss das anzuzeigende Element mittels renderTarget oder renderProperty bestimmt werden!

Die Strukturabfragen, die in den Baustein des Spaltenelements eingefügt werden, können aus einer Liste bereits registrierter Strukturabfragen ausgewählt werden, sie können aber auch für genau diesen Baustein neu angelegt werden, was auch die Vergabe eines Registrierungsschlüssels mit sich bringt. Die Eigenschaft Nicht anlegen hat auf Spalten, die mit einem Strukturabfrage-Baustein belegt sind, keine Wirkung.

Auf die vierte Spalte wurde ein Script-Baustein abgebildet

Es sollen die Verantwortlichen für die Objekte, mit denen das in der Tabelle gelistete Thema mit ist Thema von verknüpft ist, angezeigt werden. Wie bei der Strukturabfrage kann das zugeordnete Skript aus einer Liste von bereits registrierten Skripten ausgewählt oder aber im Dialog neu angelegt (und registriert) werden. Der Skript-Editor öffnet sich nach Klicken auf den Skript-Baustein-Namen.

 * Returns matching elements for colum search value "objectListArgument"
*  Note: "elements" may be undefined if no partial query result is available. 
 * Return undefined if the script cannot provide any partial result itself.
function filter(elements, queryParameters, objectListArgument) {
    return elements;

// Returns cell values for the given element
function cellValues(element, queryParameters) {
    var result = new Array();
    var firstTargets = element.relationTargets("istThemaVon") ;
    if ( firstTargets.length == 0 ) { return result ;
    else {
        for (var i = 0; i < firstTargets.length; i++) {
        var secondTargets = firstTargets[i].relationTargets("hatVerantwortlichen");
        for (var j = 0; j < secondTargets.length; j++) {
    return result.join(', ');

In diesem Fall ist die Sprache des Skriptbausteins JavaScript. Hier müssen zwei Teile gepflegt werden, der obere Teil dient der Filterung aller Elemente der Tabelle anhand des in der Spalte eingetragenen Wertes objectListArgument, der zweite Teil gibt an, wie für ein Element ein auszugebender Wert berechnet wird. Der erste Teil ist im Moment nicht ausgeführt. Zu beiden Teilen wird ein Code-Muster beim Erzeugen eingefügt, auf das beim Erstellen aufgebaut werden kann.

Wenn KScript als Sprache im Skript-Baustein gewählt wurde, um die Ausgabe einer Spalte zu steuern, dann muss das ausgewählte (registrierte) Skript zu jedem Objekt, das eine Zeile bildet, einen Rückgabewert für die Spalte liefern.

Da in KScript im Prinzip nur eine Ausgabe vorgesehen ist, wurde für die Filterung folgende Konvention getroffen:

Wenn es in dem ausgewählten Skript eine Funktion mit Namen objectListScriptResults und einem deklarierten Parameter gibt, so wird diese Funktion mit dem Argument der zugehörigen Sucheingabe aufgerufen, um die Menge der passenden Objekte zurückzuliefern. Die Funktion wird auf dem Wurzelbegriff oder der bisherigen Treffermenge als Ausgangsobjekt aufgerufen - je nach dem, wie die Suche am besten gelöst werden kann. Damit diese Variante wirklich effizient wird, ist es empfehlenswert, die Sucheingabe entsprechend auszuwerten und mit dem Ergebnis eine registrierte Strukturabfrage aufzurufen, um deren Ergebnis an die Objektliste weiterzuleiten. Suche

Mit dem View-Konfigurationselement "Suche" können dem Nutzer Suchmöglichkeiten für das Wissensnetz eingerichtet werden. Die Suche kann entweder eine vordefinierte Suche mit Parametern sein oder eine Suchfeld-Eingabemaske für den Nutzer.

Die "Suche" kann als Unterkonfiguration einer Alternative oder einer Gruppe ausgewählt werden. Eine beliebige Abfrage ist hier obligatorisch, deren Ergebnisse angezeigt werden. Auch Suchen zur Benutzereingabe können konfiguriert werden; für die View-Konfiguration wird hier anstatt dem Konfigurationslement "Suche" (Objektkonfiguration) das Konfigurationselement "Suchfeld-Ansicht" verwendet. Beispiele für die Panel-Konfiguration für das Web-Frontend finden sich hierfür in Kapitel 3 "ViewConfig-Mapper".

Wenn eine Suche mit Facetten konfiguriert werden soll, dann ist bei der Panel-Beeinflussung die Wirkungskette zu beachten:
Suchfeld-Ansicht --> Facette --> Suchergebnis.


Name Wert

Hier kann die Suche ausgewählt werden, die sofort bei der Anzeige des Konfigurationselements ausgeführt wird. Das semantische Objekt, für welches die View-Konfiguration angezeigt wird, kann als Zugriffselement in der Abfrage verwendet werden.


Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.


Hier wird eine Tabellenkonfiguration angegeben, die zur Darstellung des Suchergebnisses dient.

Skript für Beschriftung

Die Beschriftung lässt sich alternativ auch über ein Skript ermitteln.

Skript für Sichtbarkeit

Über ein Skript lässt sich steuern, ob das Konfigurationselement angezeigt werden soll.

Skript für Tabellenkonfiguration

Die Tabelle kann auch über ein Skript ermittelt werden.

Einstellungsmöglichkeiten für eine Abfrage

Die folgenden Parameter werden als Meta-Eigenschaften für eine Abfrage gepflegt.

Name Wert
Parametername Angabe eines Parameternamens, wie er in der Abfrage verwendet wird.

Einstellungsmöglichkeiten für einen Parameternamen

Die folgenden Parameter werden als Meta-Eigenschaften für einen Parameternamen gepflegt:

Name Wert
Skript Das Skript parameterValue wird zur Ermittlung des Suchwertes für den angegebenen Parameternamen verwendet.

Angabe über den Weg der Wertermittlung

Skript: Der Wert wird aus dem Skript ermittelt und darf nicht von einem Benutzer überschrieben werden.

Skript, überschreibbar: Das Skript ermittelt Wert. Der Benutzer darf überschreiben.

Benutzereingabe: Keine Skriptauswertung. Nur Eingabe durch einen Benutzer.

Typ xsd-Typ
Beschriftung Beim Herausschreiben nach JSON landet dieser Wert in label.

Darstellung in einer Anwendung

Eine Ausgabe von Suchergebnissen erfolgt standardmäßig in einer Tabelle.

In diesem Beispiel werden Suchergebnisse als Tabellen-View mit dem Style renderMode "mediaList" ausgegeben. Der renderMode "mediaList" wandelt die typische Tabellenansicht in eine ansehnliche Liste mit Icon und Link auf die Objekte um. Zusätzliche Eigenschaften des Objektes könenn angegeben werden (hier der Ort der Sehenswürdigkeit).

Darstellung im Knowledge-Builder

Die Ergebnisse einer beliebigen Abfrage werden im Knowledge-Builder stets in einer Objektliste angezeigt.


In der View-Konfiguration werden die Reiter "Eigenschaften" und "Bekannte" definiert. "Bekannte" ist ein Konfigurationselement des Typs "Suche. Unter "Abfrage" kann eine Suche ausgewählt oder direkt neu angelegt werden.

Definition der Suche

Das Ergebnis der Abfrage wird im Reiter "Bekannte" bei Objekten des Typs "Person" im Knowledge-Builder angezeigt.

Statt eines einzelnen Konfigurationselements, lassen sich Suchen auch in mehrere seperate Konfigurationen aufteilen. Suchfeld-Ansicht

Standarddarstellung eines Suchfeldes.

Dieses Konfigurationselement bietet eine separate Eingabemaske um Suchparameter für eine Abfrage eingeben zu können.

Name Wert
Abfrage Hier kann eine Abfrage festgelegt werden. Wird am Suchfeld keine Abfrage definiert, dann bestimmt das Suchfeld nur Parameter. Diese können dann über Panel-Beeinflussung an ein oder mehrere Suchergebnisansichten weitergeleitet werden.
Parametername Angabe eines Parameternamens, wie er in der Abfrage verwendet wird.
Beschriftung Hier kann eine Beschriftung für die Elementkonfiguration angegeben werden.
Skript für Beschriftung Alternativ lässt sich die Beschriftung auch über eine Skript ermitteln.

Einstellungsmöglichkeiten für Parameternamen

Die folgenden Parameter werden als Meta-Eigenschaften für einen Parameternamen gepflegt:

Name Wert
Skript Das Skript parameterValue wird zur Ermittlung des Suchwertes für den angegebenen Parameternamen verwendet.

Angabe über den Weg der Wertermittlung

Skript: Der Wert wird aus dem Skript ermittelt und darf nicht von einem Benutzer überschrieben werden.

Skript, überschreibbar: Das Skript ermittelt Wert. Der Benutzer darf überschreiben.

Benutzereingabe: Keine Skriptauswertung. Nur Eingabe durch einen Benutzer.

Typ Datentyp des Parameters.
Beschriftung Beim Herausschreiben nach JSON landet dieser Wert in label.
Reihenfolge Mehrere Parameter können hier eine Reihenfolge zugewiesen bekommen. Facetten-Ansicht


Für facettierte Suchen bietet dieses Konfigurationselement eine separate Ansicht für die Facettenauswahl.


Name Wert
Beschriftung Hier kann eine Beschriftung für die Elementkonfiguration angegeben werden.
Skript für Beschriftung Alternativ lässt sich die Beschriftung auch über eine Skript ermitteln.
Abfrage Hier kann eine Abfrage festgelegt werden.

Um für die Facetten-Ansicht die zu filternden Eigenschaften festzulegen, sind in einer untergeordneten Konfiguration einzelne Facetten hinzuzufügen.


Um die Ergebnismenge einer Suche einschränken zu können, lassen sich Facetten auf Beziehungsziele definieren. Facetten-Konfigurationselemente können einer Suche-Konfiguration untergeordnet werden.

Mit der Aktion Facette neu anlegen oder Facette hinzufügen wird eine Facette zur der Suche-Konfiguration hinzugefügt.

Es können natürlich mehrere Facetten an eine Suche-Konfiguration angebracht werden. Da sich keine Synergieeffekte bei der Facettenberechnung untereinander ergeben, verlängert sich dadurch jedoch der Berechnungsvorgang.

An einer Facetten-Konfiguration stehen folgende Einstellungsmöglichkeiten zur Verfügung.


Name Wert
Beschriftung Idealerweise ist die Beschriftung angegeben. Ist dieser Wert nicht gesetzt, wird der Name des Eingangsobjektes der Abfrage verwendet.
Abfrage zur Elterntermermittlung

Soll eine Term-Hierarchie gebildet werden, muss durch diese Abfrage definiert werden, wie sich Eltern-Kind-Elemente finden. Das Eingangsobjekt ist dabei das Kind-Element. Der Bezeichner parentTerm kennzeichnet das Eltern-Element.

Anmerkung: Alle Terme, die eine Hierarchie bilden sollen, müssen durch die Abfrage an der Facetten-Konfiguration gefunden werden.

Abfrage zur Termermittlung
Diese Abfrage ist obligatorisch. Sie wird benötigt um die Terme für eine Facette zu ermitteln. Das Eingangsobjekt ist vom Typ gleich den Suchergebnissen der Suche, die in der Suche-Konfiguration definiert ist. Die zu findenden Terme sind durch den Bezeichner term gekennzeichnet.
Ausblenden ab Anzahl von Termen .
Kindterme initial anzeigen Standardmäßig werden bei einer Hierarchie die Kindelemente erst angezeigt, wenn das dazugehörige Elternelement ausgewählt wurde. Wird dieses Flag gesetzt, werden initial alle Kindelemente mit ausgeliefert.
Leere Terme anzeigen Standardmäßig werden Terme, die keine Anzahl haben, nicht eingeblendet. Durch setzen dieses Flags werden auch diese angezeigt.
Maximale Anzahl an Termen Hier kann die Anzahl der Terme festgelegt werden, die angezeigt werden sollen. Standardmäßig werden immer alle Terme dargestellt.
Term-Anzahl nicht anzeigen Dieses Flag muss gesetzt werden, wenn die Anzahl nicht mit angezeigt werden soll.
Termoperator Sollen die Suchergebnisse auf alle Terme zutreffend sein (und) oder nur auf (mindestens) einen Term zutreffen (oder) .

Hier stehen folgende Einstellungsmöglichkeiten zur Verfügung:

  • Dynamisch:Die Wertebereiche der Terme werden automatisch ermittelt. Die Werte, die zur Termbildung verwendet werden, müssen mit dem Parameter termValue versehen sein. Mit dem Parameter Maximale Anzahl an Termen lässt sich festlegen, wie viel Terme ausgebildet werden.
  • Statisch:Es müssen alle Terme, die angezeigt werden sollen, für sich konfiguriert werden. Es muss für jeden Term eine Suche angelegt werden, die die möglichen Treffer in der Hauptsuche beschreibt.

Wird keine Termart ausgewählt (Standardverhalten), werden die Terme anhand der Abfrage an der Facetten-Konfiguration ermittelt. In der Abfrage können nur Relationsziele als mögliche Terme ausgebildet werden.

Terme Absteigend sortieren Standardmäßig werden die Namen oder die Anzahlen aufsteigend sortiert. Mit diesem Flag lässt sich die Sortierung umdrehen.
Terme nach Anzahl sortieren Standardmäßig werden die Terme nach dem Namen sortiert. Durch das setzen dieses Flags werden die Terme nach der Anzahl der Vorkommnisse in der Treffermenge sortiert. Suchergebnis-Ansicht

Dieses Konfigurationselement beinhaltet eine separate Ergebnisansicht einer Suche.

Name Wert

Hier kann eine Suchabfrage ausgewählt werden, die beim Anzeigen der Konfiguration ausgeführt wird.

Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Skript für Beschriftung Alternativ kann die Beschriftung kann auch über ein Skript ermittelt werden.
Tabelle Hier wird eine Tabellenkonfiguration ausgewählt, die zur Darstellung der Suchergebnisse dient.
Skript für Tabellenkonfiguration Alternativ kann die Tabellenkonfiguration über ein Skript generiert werden. Graph

In einem Graph werden die Inhalte der semantischen Datenbank mit ihren Objekten und Verbindungen graphisch dargestellt (siehe Knowledge-Builder > Grundlagen > Graph-Editor).


Name Wert
Beschriftung Eine Beschriftung wird nur ausgegeben, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Skript für Beschriftung Ein Skript, welches die Beschriftung zurückliefert.
Graph-Konfiguration Hier wird ein Graph-Konfigurations-Objekt festgelegt.
Legende ausblenden Legt fest ob die Legende zu den Knotentypen angezeigt werden soll.
Breite / Höhe Legt die Breite und Höhe des Konfigurationselements, entweder prozentual oder pixelgenau, fest.
Skript für Sichtbarkeit In einem hier referenzierten Skript lässt sich die Sichtbarkeit des Konfigurationselements festlegen.
Strukturabfrage für Startelemente Eine Abfrage, welche die anzuzeigenden Objekte ermittelt. Graph-Konfiguration

Die Graph-Konfiguration ermöglicht es nur bestimmte Typen und Relationen im Graphen anzuzeigen. So kann verhindert werden, dass unerwünschte Typen und Relationen im Graphen zu sehen sind. Die Graph-Konfiguration kann ebenfalls über JavaScript-Funktionen angefragt werden. Sie findet beispielsweise Verwendung im Net-Navigator.

Einer Graph-Konfiguration werden Knotenkategorie-Elemente untergeordnet.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. einer weiteren Alternative eingebettet ist.
maximale Pfadlänge .
Schritte bis Knotenausblendung . Knotenkategorie

Knotenkategorien werden Graph-Konfigurationen untergeordnet.

Ihnen werden Verknüpfung-Elemente untergeordnet.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. einer weiteren Alternative eingebettet ist.
Erweiterungen initial anzeigen .
Farbe Farbgebung der Knoten dieser Kategorie
In Legende anzeigen Immer, Bei Bedarf oder Nie
Knotengröße .
Nur das Icon malen . VerknĂĽpfung

Verknüpfungen sind was genau?

Sie werden einer Knotenkategorie untergeordnet.


Name Wert
Abfrage für Verknüpfung .
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. einer weiteren Alternative eingebettet ist.
Bevorzugt ausklappen .
Farbe .
Initial ausgeklappt .
Relation .
Skript für Beschriftung Hier lässt sich ein Skript referenzieren welches die Beschriftung ermittelt.
Skript für Verknüpfung Über ein hier referenziertes Skript lässt sich die Verknüpfung festlegen. Text

Dieses Konfigurationselement gibt einen einfachen Text aus. Dieser wird entweder fest konfiguriert oder über ein Skript ermittelt.


Name Wert
Beschriftung Eine Beschriftung wird nur ausgegeben, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Skript für Beschriftung Ein Skript, welches die Beschriftung zurückliefert.
Text Text, der ausgegeben werden soll.
Skript für Text Ein Skript, welches den anzuzeigenden Text zurückliefert. Bild

Mit Hilfe dieses Konfigurationselements kann eine statische Grafik eingebunden werden.

Name Wert
Beschriftung Eine Beschriftung wird nur ausgegeben, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Skript für Beschriftung Alternativ kann hiermit die Beschriftung durch ein Skript ermittelt werden.
Bild Die Bilddatei, welche ausgegeben werden soll.
Skript für Bild Alternativ kann die Grafik durch ein Skript zurückgegeben werden.
Breite / Höhe Skaliert die Bilddatei auf die angegebenen Maße.
Skript für Sichtbarkeit Durch ein Skript lässt sich bestimmen ob die Grafik angezeigt werden soll. Skriptgenerierter View/HTML

Skriptgenerierte View

Eine mit Hilfe eines im Wissensnetz hinterlegten Skripts erstellte Sicht. Dieses ist in Javascript geschrieben und kann ein eigenes Template (ein Ractive.js "Partial") verwenden. Hierüber lassen sich komplexe Sichten erstellen, die über die Funktionalitäten der Standard-View-Konfigurationen hinaus gehen.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Skript Skript zur Generierung der View.
Skript für Sichtbarkeit Skript zum Ermitteln der Sichtbarkeit.
Skript für Beschriftung Skript zum ermitteln der Beschriftung.
viewType Name des Partials.

Skriptgeneriertes HTML

Diese View-Konfiguration zeigt ein HTML-Fragment an, welches mit Hilfe eines im Wissensnetz hinterlegten Skripts generiert wird. Hierin wird über die Javascript-API von i-views auf Wissensnetz-Elemente und ihre Eigenschaften zugegriffen und über ein XML-Writer-Objekt eine HTML Struktur erzeugt und mit Daten befüllt.


Name Wert
Beschriftung Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist.
Skript Skript zur Generierung einer HTML-Ausgabe.
Skript für Sichtbarkeit Skript zum Ermitteln der Sichtbarkeit.
Skript für Beschriftung Skript zum ermitteln der Beschriftung.

Beispiel für ein Skript, das eine einfache HTML-Ausgabe erzeugt:

function render(element, document) {
  var writer = document.xmlWriter();


</div> Label

Mit der Label-Konfiguration kann beispielsweise die Beschriftung einer Webseite oder die Beschriftung einer Tabelle konfiguriert werden. Im Knowledge-Builder werden die Label-Konfigurationen unter der Kategorie „Nachgeordnete Konfiguration“ verwaltet.
Label finden im Fenstertitel-Panel Verwendung; hierzu muss ein neues Objekt unter „Label-Konfiguration“ angelegt werden:

Unter „Beschriftung“ und „Bild“ können dann die Einträge vorgenommen werden, die sich später auf dem Browser-Tab der Webseite wiederfinden:

Hinweis: Im Knowledge-Builder wird das View-Konfigurationselement ("Label") standardgemäß mit "Label - Objekt" betitelt. Wenn unter "Beschriftung" eine Zeichenkette eingetragen wird, so erscheint diese als Elementname des View-Konfigurationselements. Wenn ein Konfigurationsname ("Beschriftung") vergeben wird, so erscheint dieser als Elementname. Konfigurationsnamen sollten generell vergeben werden, damit Konfigurationselemente wiedergefunden und besser voneinander unterschieden werden können.

Bezüglich des Web-Frontends, welches durch den Viewkonfiguration-Mapper erzeugt wird, entspricht dies dem Element <title> in der Sektion <head>:

Ein Vergleich zeigt die unterschiedlichen Zustände der Webseite ohne Label (Titel = Pfad der Webseite) oder mit Label (Titel = Beschriftung):

1.7.5 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 normalerweise genau ein Startelement (ein Objekt oder einen Typ) bei ihrer Aktivierung, welches sie an ihre Unterkonfigurationen weiter geben. Panels, die View-Konfigurationen enthalten, welche eine Menge von Objekten anzeigen (Tabelle, Facetten-Auswahl, Graph), können auch eine Menge von Startelementen verarbeiten.

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 eins 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
Aktionsergebnisse anzeigen 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) Ansicht-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.

Nicht überschreibbar durch äußeres Kontextelement

Wenn diese Option aktiviert ist, wird immer das konfigurierte Kontextelement verwendet. Die Beeinflussung durch andere Panels hat dann keine Auswirkung.

Falls kein Kontextelement konfugiert ist, bleibt das Kontextelement leer.

Skript für Kontextelement

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

Es können auch mehrere Elemente als Kontextelement zurück geliefert werden.

Die Option "Nicht überschreibbar durch äußeres Kontextelement" 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.6 Sessions

Eine Session im Sinne der View-Konfiguration dient als temporärer Speicher für variable Werte, der innerhalb von Skripten der View-Konfiguration gelesen und beschrieben werden kann. Auf diese Weise kann der aktuelle Zustand einer Anwendung abgebildet werden.

Sessions bilden einen Stapel. Die erste Session besteht automatisch für die gesamte Dauer der Web-Session - also vom Moment zu dem die Anwendung aufgerufen wird, bis zum Schließen des jeweiligen Browser-Fensters. Diese erste Session kann immer mit der Funktion "$k.Session.main()" erreicht werden.

Das Öffnen eines Dialogs erzeugt eine neue Session auf dem Stapel. Das Schließen des Dialogs entfernt die zugehörige Session vom Stapel.

Das Aktivieren von Panels mit der Markierung "Session-Grenze" erzeugt auch eine neue Session auf dem Stapel, deren Lebensdauer bis zum Deaktivieren des Panels andauert.

Die oberste Session des Stapels erreicht man mit der Funktion "$k.Session.current()".

1.7.7 Knowledge-Builder-Konfiguration

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

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. Die Standard-Ordnerstruktur

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. Konfiguration der Ordnerstruktur

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

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. Für gewöhnlich werden zu diesem Zweck gewöhnliche Abfragen und nicht etwa Strukturabfragen verwendet.

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. Hierzu muss bei "anwenden auf Relation" die Relation eingetragen werden, bei der die Relationszielsuche angewendet werden soll. Die Eigenschaften "anwenden auf Ziel" und "anwenden in" werden ab Version 5.2 nicht mehr berücksichtigt.

Achtung! Die hier beschriebene Relationszielsuche kann so nur im Knowledge Builder angewendet werden. Soll eine spezifische Relationsauswahl mit einer speziell konfigurierten Tabelle im Frontend eingesetzt werden, muss dafür der Relationszielfilter verwendet werden. Die Beschreibung dazu ist im Kapitel Relationszielfilter zu finden. Startansicht

Mit der Konfiguration Startansicht (KB) (zu finden als Reiter im View-Konfiguration-Bereich) lässt sich definieren, welches Hintergrundbild und welche Aktionen auf dem Startbildschirm im Knowledge-Builder auf der rechten Seite angezeigt werden sollen. Die Anzeige lässt sich jederzeit durch Deselektion (Klick 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 Standardwerte, falls eine Eigenschaft fehlt. 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 Suchfeld

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. Suchfeldkonfiguration fĂĽr Administratoren

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. Suchfeldkonfiguration fĂĽr Anwender

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

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 oder des Knowledge-Builders verknüpft werden können, wird im Folgenden erläutert.

Zunächst muss das Element der View-Konfiguration ausgewählt werden, mit dem ein oder mehrere Style-Elemente verknüpft werden sollen. Fast jeder View-Konfigurations-Typ hat einen "Styles"-Reiter. Dort kann entweder ein neues Style-Element definiert oder ein bereits vorhandenes Style-Element verknüpft werden. Wenn ein neues Style-Element definiert wird, muss diesem zuerst ein Konfigurationsnamen gegeben werden. Auf der rechten Seite des Editors kann daraufhin die Konfiguration vorgenommen werden.

Ein Style-Element kann mit beliebig vielen Style-Eigenschaften befüllt werden. Die Style-Eigenschaften sind auf mehrere Reiter aufgteilt, die in den folgenden Unterkapiteln beschrieben sind.


Nicht alle Eigenschaften eines Styles ergeben für alle Konfigurationen Sinn. Die Tabellen der folgenden Unterkapitel führen darum noch die Spalte "Konfigurationstyp", welcher zeigt, welcher View-Konfigurationstyp von der jeweiligen Eigenschaft unterstützt wird. Der Effekt wird in der letzten Spalte beschrieben. Style-Eigenschaften in Anwendungen und im Knowledge-Builder

Der Reiter "Konfiguration" eines Style-Elements ist in diesem Kapitel beschrieben und enthält die Style-Eigenschaften, die sowohl im Knowledge-Builder als auch im Viewkonfiguration-Mapper verwendet werden. 


Style-Eigenschaft Konfigurationstyp Effekt
Baumansicht Gruppe Elemente der Gruppe als Baum darstellen. Standard ist nein, d.h. die Gruppenelemente werden nebeneinander oder untereinander angezeigt.
Höhe Eigenschaft Höhe in Zeilen bei Zeichenkettenattributen
Höhe Gruppe Höhe eines Gruppenelements in Pixeln bei nebeneinander dargestellten Gruppenelementen.
Skript für Aktivierung Alle Der Style kann über ein Skript abhängig vom aktiven Element aktiviert werden.
Vertikale Anordnung Gruppe Elemente der Gruppe nebeneinander darstellen. Standard ist untereinander anzeigen. Style-Eigenschaften in Anwendungen

Der Reiter "Viewconfiguration-Mapper" wird nur angezeigt, wenn die Komponente "Viewconfiguration-Mapper" installiert ist. Die verfügbaren Style-Eigenschaften für diese Komponente sind im Kapitel Style des Viewconfig-Mapper (Kaiptel 3) enthalten. Style-Eigenschaften im Knowledge-Builder

Der Reiter "KB" eines Style-Elements ist in diesem Kapitel beschrieben und enthält die Style-Eigenschaften, die nur im Knowledge-Builder verwendet werden.


Style-Eigenschaft Konfigurationstyp Effekt
Banner anzeigen Objektkonfiguration

Banner mit Namen des Objekts und Schaltflächen zur Bearbeitung anzeigen. Standard ist nein.

Editorbreite (Pixel) Eigenschaft Breite in Pixeln einer Eigenschaft
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).

Verwende Knöpfe Eigenschaft (nur Relationen!)  
Vorschau anzeigen Tabelle Steuert, ob unterhalb der Tabelle ein Editor angezeigt wird.


1.7.9 Detektorsystem zur Ermittlung der View-Konfiguration

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.8 JavaScript-API
1.8.1 EinfĂĽhrung

The JavaScript-API is a server-side API for accessing a semantic net. The API is used in triggers, REST services, reports etc. API-Referenz

The API reference is available here:

http://documentation.i-views.com/ Der 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. Mit semantischen Elementen arbeiten

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

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" }



Transaktionen, wie oben beschrieben, dürfen nicht geschachtelt werden. Es gibt allerdings Fälle, in denen eine Schachtelung nicht vermeidbar ist, weil beispielsweise eine Skriptfunktion sowohl von Funktionen aufgerufen wird, die bereits in einer Transaktion gekapselt sind als auch von Funktionen, für die das nicht gilt. Hier kann eine sogenannte "optimistische Transaktion" eingesetzt werden. Dieses Konstrukt verwendet die äußere Transaktion - sofern vorhanden, oder startet einen neue Transaktion.

$k.optimisticTransaction(function() {
	return $k.Registry.type("Article").createInstance();

Solche Konstruktionen sollten vermieden werden, weil eine Transaktion eine sinnvolle Arbeitseinheit darstellt, welche ganz oder gar nicht ausgeführt wird. Entweder ist die eingebettete für sich alleine sinnvoll und vollständig oder nicht.

Achtung: Eine Fehlerbehandlungsfunktion bei Fehlschlag der optimistischen Transaktion steht nicht zur Verfügung. Sofern eine äußere Transaktion existiert, wird bei Fehlschlag deren Fehlerbehandlung ausgeführt. Elemente modifizieren Elemente anlegen
// 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"); Attribute hinzufügen und ändern

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"); Relationen hinzufĂĽgen

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]); Elemente löschen

Any element can be deleted with the remove() function:


This also deletes all properties of the element.

1.8.2 Beispiele Abfragen

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")); Zur Laufzeit generierte Abfragen

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

Mögliche Operatoren sind:

containsPhrase  Enthält Phrase
covers  enthält
distance  Abstand
equal == Gleich
equalBy  Entspricht
equalCardinality  Kardinalität gleich
equalGeo  Gleich (Geo)
equalMaxCardinality  Kardinalität kleiner gleich
equalMinCardinality  Kardinalität größer gleich
equalPresentTime  gleich jetzt (Gegenwart)
equalsTopicOneWay  filtern mit
fulltext  Enthält Zeichenkette
greater > Grösser als
greaterOrEqual >= Grösser/Gleich
greaterOverlaps  überschneidet von oben
greaterPresentTime  nach jetzt (Zukunft)
isCoveredBy  ist enthalten in
less < Kleiner als
lessOrEqual <= Kleiner/Gleich
lessOverlaps  überschneidet von unten
lessPresentTime  vor jetzt (Vergangenheit)
notEqual != Ungleich
overlaps  überschneidet
range  Zwischen
regexEqual  Regulärer Ausdruck
regexFulltext  Enthält Zeichenkette (Regulärer Ausdruck)
unmodifiedEqual  Exakt gleich
words  Enthält Zeichenkette Elemente anlegen und ändern

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) {
} E-Mails versenden

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 structures can also be generated using the view configuration; this is possible for individual objects as well as for lists of objects.

In the most straightforward case, an object is converted to JSON using the standard configuration without additional context:

var data = element.renderJSON();

All structures defined by the configuration are then converted to JSON:

    "viewType" : "fieldSet",
    "label" : “Bern",
    "elementType" : "instance",
    "modNum" : 26,
    "elementId" : "ID17361_141538476",
    "type" : {
        "elementType" : "instance",
        "typeId" : "ID10336_319205877",
        "internalName" : "City",
        "typeName" : “City"
    "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" : “AlternativeName/Synonym",
                "elementType" : "attribute",
                "internalName" : "alternativeName",
                "attributeType" : "string",
                "rdf-id" : "alternativeName",
                "viewId" : "ID20839_64952366",
                "typeId" : "ID4900_79689320",
                "minOccurrences" : 0
        }, {
            "values" : [{
                    "target" : {
                        "typeId" : "ID10336_493550611",
                        "label" : “Museum of Fine Arts Bern",
                        "elementId" : "ID17362_205182965"
                    "propertyId" : "ID17361_395925739"
                }, {
                    "target" : {
                        "typeId" : "ID10336_493550611",
                        "label" : “Swiss National Library",
                        "elementId" : "ID20401_126870015"
                    "propertyId" : "ID17361_9264966"
            "schema" : {
                "targetDomains" : [{
                        "elementType" : "instance",
                        "typeId" : "ID10336_493550611",
                        "internalName" : "point_of_interest",
                        "typeName" : “Point of interest"
                "label" : “contains point of interest",
                "elementType" : "relation",
                "internalName" : "contains_poi",
                "viewId" : "ID20840_182208894",
                "typeId" : "ID2052_332207092",
                "minOccurrences" : 0

You can also define a context in the form of an application or configuration object. A suitable configuration for this context is then selected. The application “Android” is specified in the following example:

var application =  $k.Registry.elementAtValue("viewconfig.configurationName", "Android");
var data = element.renderJSON(application);

However, it is also possible to specify a configuration and let this configuration convert the element. To do so, you generate a $k.ViewConfiguration from the configuration object.

var configurationElement = $k.Registry.elementAtValue("viewconfig.configurationName", “Android Article Configuration”);
var data = $k.ViewConfiguration.from(configurationElement).renderJSON(element);

Since the JSON structure is rather extensive, you can also leave out certain properties in the conversion by specifying the keys as additional parameters:

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" : “City"
    "properties": [
            "values": [
                    "value": "Bern"
            "schema": {
                "elementType": "attribute",
                "label": "Name",
                "internalName": "name",
                "attributeType": "string",
                "maxOccurrences": 1
            "schema": {
                "elementType": "attribute",
                "label": “AlternativeName/Synonym",
                "internalName": "alternativeName",
                "attributeType": "string"
            "values": [
                    "target": {
                        "label": “Museum of Fine Arts Bern",
                        "elementId": "ID17362_205182965"
                    "target": {
                        "label": “Swiss national library",
                        "elementId": "ID20401_126870015"
            "schema": {
                "elementType": "relation",
                "targetDomains": [
                        "elementType": "instance",
                        "internalName": "point_of_interest",
                        "typeName" : “Point of interest"
                "label": “contains point of interest",
                "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 Module Module definieren

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")
	}}); Module verwenden

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 Debuggen im 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 API-Erweiterungen Zusätzliche Funktionen

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(); Eigene Prototypen definieren

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 Konfiguration

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 Ressourcen

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 Methoden

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 Resourcen

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.
Optional kann über den Parameter "allowRedirect" festgelegt werden, das Blobs nicht direkt vom Blobservice geholt werden dürfen (Fixed-Value: false).

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.
ObjectListPrintTemplate ResourceWithFilename 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 Ressourcen 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 Berichte und Drucken

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 Druckvorlagen erstellen

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. RTF-Vorlagen erstellen

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 ODT-Dokumente (OpenOffice) erstellen

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. DOCX-Dokumente (Microsoft Word) erstellen

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 Druckvorlagen fĂĽr Listen erstellen

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 Dokumentformatkonvertierung mit 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


1.11 Tagging

Die Tagging-Komponente ermöglicht es, Objekte aus dem Wissensnetz (Personen, Themen usw.) in Dokumenten zu finden oder neu anzulegen.

Für das Tagging benötigt man

  • eine konfigurierte Tagging-Komponente im Wissensnetz
  • eine Tagging-Software (Intrafind, OpenNLP), die potentielle Objekte in einem Text findet

Das Tagging erfolgt in drei Schritten

  1. Der zu taggende Text eines Dokuments wird bestimmt (z.B. der Wert eines Textattributs)
  2. Der Text wird an die Tagging-Software weitergereicht, die den Text analysiert und eine Reihe von Tags liefert
  3. Anhand der Konfiguration werden für jedes Tag vorhandene Objekte im Wissensnetz gesucht und potentiell auch neue Objekte angelegt. Die Objekte werden mit dem Dokument per Relation verknüpft.
1.11.1 Konfiguration

Für das Tagging wird die gleichnamige Komponente benötigt, die im Admin-Tool hinzugefügt werden kann. Diese richtet das benötigte Schema ein.

Anschließend kann im Knowledge-Builder unter "Technik" > "Tagging" die Konfiguration vorgenommen werden.

Jede Tagging-Konfiguration besteht aus

  • einer Schnittstellen-Konfiguration der zu verwendenden Tagging-Software (intrafind, OpenNLP)
  • der Konfiguration der Text-Extraktion, die den zu taggenden Text eines Dokuments ermittelt
  • Tag-Konfigurationen, die bestimmen, wie Objekte im Wissensnetz gefunden, angelegt und verknüpft werden Tagging-Konfiguration

Die Tagging-Konfiguration bündelt alle Informationen, die man für das Tagging benötigt.

Zwingend erforderlich ist es, die zu verwendende Tagger-Schnittstelle anzugeben.

Die Angabe der zu verwendenden Text-Extraktion ist optional. Alternativ kann diese auch dynamisch ermittelt werden (siehe das dazugehörige Unterkapitel).

Weiterhin kann ein Anpassungs-Skript angebeben werden, mit dem Einfluss auf das Tagging genommen werden kann. Zusätzliche Anpassungen können auch bei den Konfigurationen für Tags und für Text-Extraktion vorgenommen werden.

Neu angelegte Anpassungs-Skripte enthalten auskommentierte Funktionsrümpfe. Um diese zu aktivieren braucht man nur die Kommentarzeichen zu entfernen. Schnittstellen-Konfiguration

Die Intrafind-Schnittstelle hat folgende Einstellungen:

KonfigurationsnameFrei wählbarer Name
ParameterWird über die Schnittstelle an Intrafind weitergegeben, steuert das Tagging
URLURL des Intrafind-Taggers

Bei OpenNLP wird neben dem optionalen Namen nur die URL des REST-Services benötigt.

Die Schnittstelle "Interner Tagger" ist nur zu Testzwecken / interne Demos gedacht, bei denen man kein externes System anbinden möchte. Dieser Tagger hat keinerlei Anspruch, sinnvolle Ergebnisse zu liefern. Text-Extraktion

Wenn der zu taggende Text nicht dynamisch ermittelt wird, weil z.B. nur der Text eines ganz bestimmten Attributtyps oder der Text eines Dokuments extrahiert werden soll, muss eine Text-Extraktion konfiguriert werden.

Diese Konfiguration kann unter dem Reiter "Text-Extraktion" hinzugefügt werden.

KonfigurationsnameFrei wählbarer Name
anwenden aufObjekt-Typ, für den diese Konfiguration gilt. Wird verwendet, wenn bei einer Tagging-Konfiguration keine explizite Text-Extraktion vorgegeben wird.
Skript zur TextextraktionOptionales Skript zur Bestimmung des Texts

Um die zu taggenden Attributtypen anzugeben, werden der Text-Extraktion ein oder mehrere (auf der linken Seite hierarchisch geordnete) Textteil-Extraktionen hinzugefügt. In jeder Textteil-Extraktion wird unter "extrahiert Text aus" der zu taggende Attributtyp hinterlegt.

Als Textteil-Extraktionen können neben Zeichenketten auch Blobs verwendet werden. Aus diesen wird der Text extrahiert und an die Tagging-Schnittstelle weitergereicht. Dazu muss im Client (Bridge oder KB) die Textextraktion konfiguriert werden (siehe Kapitel i-views-Dienste > Text-Extraktion).

Das optionale Skript hat drei Argumente

textDocument$k.TextDocumentAusgabe des zu taggenden Texts
element$k.SemanticElementDas Element, dessen Text extrahiert werden soll
attributes$k.Attribute []Array der Attribute des Elements. Es werden die Attribute gemäß der Konfiguration aufgesammelt.

Folgendes Beispiel schreibt die Werte der Attribute hintereinander:

function extractText(textDocument, element, attributes)
    attributes.forEach(function(attribute) {
} Tagtypen

Die Konfiguration eines Tagtyps definiert, wie Objekte im Wissensnetz gefunden, angelegt und verknüpft werden sollen. Dazu kann man für jeden von der Tagging-Schnittstelle bereitgestellten Tagtyp eine eigene Konfiguration angeben. Eine neue Konfiguration kann man bei der Tagging-Konfiguration in der Hierarchie-Ansicht auf der linken Seite anlegen.

Standardmäßig liefern die Schnittstellen folgende Tagtypen:

IntrafindPersonName, Location, TFIDF

Ein Tagkonfiguration kann für einen oder mehrere Tagtypen gelten.

Die Konfiguration bietet folgende Einstellungen:

Anpassungs-SkriptSkript, um in das Tagging einzugreifen. Das Template enthält eine Reihe auskommentierter Funktionen, die aktiviert werden können.
anwenden aufTyp im Wissensnetz, der dem Tagtyp entspricht. Falls Objekte gesucht/angelegt werden sollen und keine weiteren Konfigurationsangaben gemacht wurden, wird dieser Typ verwendet.
KonfigurationsnameFrei wählbarer Name
Suche nach vorhandenen Objekten

Suche, die als Eingabe den Text des Tags als Parameter searchString erhält und ein passendes Objekt im Wissensnetz sucht.

Es können mehrere Suchen angegeben werden, um z.B. die einzelnen Suchen kompakter zu halten.

Es ist Aufgabe der Suche, bei mehreren Suchtreffern den geeigneten Treffer zu liefern. Falls mehrere Treffer mit unterschiedlicher Qualität gefunden werden, wird der Treffer mit der besten Qualität verwendet. Falls sich kein bester Treffer bestimmen lässt wird kein Objekt zugeordnet.

Tag-Objekte automatisch anlegen

Falls kein Objekt gefunden wurde und diese Option aktiviert wurde, werden neue Objekt angelegt.

Es ist darauf zu achten, dass die Suche nach vorhandenen Objekten diese findet, da ansonsten bei jedem Tagging neue Objekte entstehen.

Falls kein Anpassungsskript hier eingreift wird ein Objekt vom bei "anwenden auf" angegeben Typ angelegt und als dessen Name der Text des Tags gesetzt.

Tag-RelationstypMit diesem Relationstyp werden Dokumente mit den durch den Tagger gefundenen Objekten verknüpft.
TagtypDie oben angegeben Tagtypen. Falls kein Tagtyp definiert ist gilt die Konfiguration für alle Arten von Tags.
Verwendet ExportHier kann eine Export-Konfiguration angegeben werden, mittels der sich alle Tags des Typs oder eine Untermenge davon exportieren lassen. Details hierzu im nächsten Abschnitt. Export der bekannten Tags

Um in einem Tagging-Service, z.B. Intrafind, Information aus dem Netz zu hinterlegen gibt es eine Export-Möglichkeit. Derzeit wird diese nur für Intrafind unterstützt und hat dort folgendes Verhalten:

Es lassen sich eine oder mehrere Listen generieren, die dann bei der Tagging-Schnittstelle abgelegt werden. Jeder Listen-Export ordnet den zu exportierenden Wissensnetz-Elementen benennende Attribute (z.B. Name, Synonym) zu. Diese Benennungen sucht der  Tagger dann in Texten und kann das passende Wissensnetz-Element dazu liefern. Beispielsweise lässt sich so die Liste der bekannten Organisationen exportieren und der Tagger kann diese zuverlässig identifizieren.

Der Intrafind Listen-Export wird für jeden Tagtyp konfiguriert und wird auch von der Tagtyp-Konfiguration beeinflusst. Allgemeine Konfigurationsoptionen:

KonfigurationsnameFrei wählbarer Name
Benennendes Attribut(optional) Attribut, das das Objekt identifiziert. Mehrfache Angabe möglich. Wenn kein Attribut angegeben ist, wird standardmäßig das Namensattribut exportiert.
Objektfilter(optional) Hier lässt sich eine Suche angeben, die die Menge der Objekte spezifiziert. Wenn keine Suche angeben ist, werden alle Typen die in der Tagtyp-Konfiguration mittels anwenden auf zugeordnet sind exportiert.

Intrafind spezifische Matching Optionen. Diese beeinflussen direkt das Verhalten des Tagging-Services:

Groß-/Kleinschreibung beachtenStandardmäßig wird case-insensitiv gematcht. Hier lässt sich die case-sensitivität aktivieren.
Diakritika (Umlaute etc) ignorieren[vermutlich] Mittels dieser Option werden Zeichen mit Accents oder Umlauten ignoriert, z.B. Geräte matcht auch Gerate.
Phonetisch matchen[vermutlich] Auch z.B. "Photographie" mit "Fotografie" matchen.
Sprachabhängig matchen

Diese Option schaltet die linguistische Verarbeitung der übergebenen Benennungen ein. Hierbei ist es wichtig, dass die Daten korrekt nach Sprache im Wissensnetz gepflegt sind, da jede Sprache mit einer ihr eigenen Linguistik verarbeitet werden muss. Ăśberlappungsfiltergruppe

Es kann vorkommen, dass der Tagger zu einer Textstelle mehrere Tags liefert. In manchen Fällen will man diese Überlappung bewusst zulassen und mehrere Tags anzeigen.

Das Verhalten der Überlappungsfiltergruppe ist wie folgt:

  • Alle Tagtypen die in einer solcher Gruppe zusammengefasst sind, müssen überlappungsfrei sein
  • Innerhalb einer Gruppe lässt sich über ein Skript eine Priorisierung angeben, um die Entscheidung, welcher Tag am Ende angezeigt wird, zu beeinflussen
  • Um Überlappungen zuzulassen müssen mind. zwei solcher Gruppen existieren
  • Alle Tagtypen ohne Gruppe werden in der "default"-Überlappungsfiltergruppe zusammengefasst

Priorisierung mit Skript

 * When there are conflicting tags (e.g. overlapping), this function can influence the conflict resolution by building a sort key.
 * The sortOrder compares the array from left to right, lower numbers are sorted before higher ones. Thus, if something larger should have a higher priority, it needs to be negated.
 * e.g.: [-1, 3] < [0, 0] < [1, -3] < [1, -2]
 * @param {$k.Tag[]} tags
 * @param {$k.TaggingContext} taggingContext
 * @returns {integer[]} an array of numbers that is used to sort the conflicting tags.
function tagSortOrder(tag, taggingContext)
    var smallestSpanReducer = function(minPos, span){return Math.min(minPos, span.start)};
    var positionMinimum = tag.spans().reduce(smallestSpanReducer, Number.MAX_VALUE);
    return [-tag.tagTypePriority(), -tag.canonicalText().length,  positionMinimum ];

Das Skript muss eine Liste von Integern zurückgeben, wobei das erste Element dieser Liste den höchsten Einfluss hat. Im Prinzip funktioniert es wie bei der Sortierung nach mehreren Spalten, also das zweite Element wird nur dann hinzugezogen, wenn im Ersten der gleiche Wert vorliegt.


Wenn kein Skript angegeben ist, oder der Tagtyp in der impliziten "default"-Gruppe gruppiert ist, dann wird folgende Priorisierung angewendet:

  • Reihenfolge der Tagtypen - höhere Priorität zuerst
  • Längere Tags bevorzugt
  • Position innerhalb der Überlappung (also bei "eine rote Wand" wird "eine rote" vor "rote Wand" bevorzugt, weil es weiter vorn steht)

Vergleiche auch das Skript-Template.

1.11.2 View-Konfiguration

Zur Anzeige sind zwei Views verfügbar:

  • Markup-View
  • Tag-Liste

Der Markup-View ist sowohl im Knowledge-Builder als auch im ViewConfig-Mapper verwendbar. Der View kann überall dort verwendet werden, wo auch andere Views wie z.B. Eigenschaften oder Hierarchien eingesetzt werden können.

Im Knowledge-Builder hat der View bereits einen fest eingebauten Tag-Button. Im ViewConfig-Mapper gibt es eine eingebaute Aktionsart "Tag", die man auch in einem eigenen Button verwenden kann.

Die Tag-Liste ist nur im ViewConfig-Mapper verfügbar und ist dort Inhalt eines Panels (z.B. als Subkonfiguration eines Panels mit festangelegter Ansicht). Falls man in einem anderen Panel einen Markup-View mit Tag-Buttons konfiguriert hat, sollte man dessen Panel per Relation "beeinflusst" mit dem Tag-Listen-Panel verknüpfen, damit nach dem Tagging die Tagliste aktualisiert wird.

Beide Views haben die obligatorische Konfigurationseinstellung "Verwendet Tagging-Konfiguration", die den View mit der Tagging-Konfiguration verbindet. Debug Log

Der KB kann Debug-Informationen während des Tagging-Vorgangs ausgeben. Die Informationen werden auf den #tagging-Channel geschrieben (Doku zu Channel siehe Handbuch) und können z.B. in eine Datei ausgeleitet werden.

Dazu eine .txt-Datei im Verzeichnis vom KB anlegen und zu „kb.ini“ umbenennen. Dann folgenden Inhalt einfügen:


Damit erhält man eine „tagging.log“-Datei, in welcher die Tags, die Intrafind zu den Tagtypen findet, einzusehen sind. So kann nachvollzogen werden, welche Strings von Intrafind als Tag vorgeschlagen werden und ebenfalls über welchen Tagtypen (z.B. signifterm/tfidf oder Organization) diese gefunden werden.

1.11.3 Taggen per Script

Taggen ist auch per Script möglich. Dazu erstellt man ein Objekt vom Typ $k.TaggingConfiguration.

Mit der Funktion tag(context) wird das Tagging durchgeführt. Das Tagging wird durch ein Objekt vom Typ $k.TaggingContext gesteuert. Dieses muss bei jedem Aufruf von tag() neu erstellt werden, da es zustandsbehaftet ist. Das TaggingConfiguration-Objekt ist zustandslos und kann wiederverwendet werden.

var document = $k.Registry.elementAtValue("RDF-ID", "opennlp-testdocument");
var configElement = $k.Registry.elementAtValue("tagging.name", "opennlp tagger config");
var tagger = $k.TaggingConfiguration.from(configElement);
var context = new $k.TaggingContext();
$k.out.print("Found " + context.tags().length + " tags");
1.11.4 Benötigte Software

Der Intrafind-Tagger muss separat erworben und installiert werden.

Die OpenNLP-Anbindung erfolgt über eine von i-views bereitgestellte REST-Schnittstelle zu OpenNLP.

1.12 EntwicklungsunterstĂĽtzung
1.12.1 Dev-Tools

Es stehen verschiedene Tools zur Verfügung um die Entwicklung zu erleichtern.

  • i-views-Plugin: Bietet Unterstützung für Jetbrains Produkte. Dazu gehört die Synchronisierung von Quelldateien, KJavascript- und KPath-Unterstützung.


1.12.2 Dev-Service

Der Knowledge-Builder bietet die Möglichkeit, Zugriff aus externen Anwendungen zu ermöglichen. Dies ermöglicht z.B. die Synchronisierung mit Entwicklungsumgebungen oder das öffnen bestimmter Elemente einer Applikation aus dem Browser.

Hierfür muss im Knowledge-Builder der Dev-Service gestartet werden. Dazu ruft man zunächst die Einstellungen auf und geht dann im Reiter Persönlich auf Dev-Tools. Hier lässt sich nun ein Port angeben unter denen der Dienst erreichbar sein soll. Über die nebenstehenden Schaltflächen kann der Dienst manuell gestartet und angehalten werden. Ist die Checkbox "Automatisch starten" gesetzt, wird der Service automatisch mit dem Knowledge-Builder gestartet.

Hat der Knowledge-Builder eine INI-Datei (der Standardname ist "kb.ini") kann er die Einstellungen dauerhaft speichern. In der INI-Datei können die Einstellungen aber auch von Hand eingetragen werden:

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 Serververwaltung

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