When using k-infinity, databases work the way people think: simple, agile and flexible. That is why in k-infinity many things are different than relational databases: we do not work with tables and keys, but with objects and the relationships between them. Modelling of the data is visual and oriented towards examples so that we can also share it with users from the specialist departments.
With k-infinity we do not set-up pure data storage but intelligent data networks which already contain a lot of business logic and with which the behaviour of our application may, to a large extent, be defined. To this end we use inheritance, mechanisms for conclusions and for the definition of views, along with a multitude of search processes which k-infinity has to offer.
Our central tool is the knowledge builder, one of the core components of k-infinity. Using the knowledge builder we can:
All these functions are the subject of this documentation. One continuous example is a semantic network surrounding music, bands, songs, etc.
The basic components of modelling within k-infinity are:
Examples for specific objects are John Lennon, the Beatles, Liverpool, the concert in Litherland Town Hall, the football world cup in Mexico in 1970, the leaning tower of Pisa, etc.:
We can link these specific objects together through relationships: "John Lennon is a member of the Beatles", "The Beatles perform a concert in Litherland Town Hall".
Additionally, we have introduced four types here: specific objects always have a type, e.g. the type of persons, type of the cities, the events or the bands – types which you may freely define in your data model.
The main window of k-infinity: on the left-hand side the types of objects, on the right-hand side the respective, specific objects – here we can also see that the types of the k-infinity networks are within a hierarchy. You will find out more about the type of hierarchy in the next paragraph.
Even the relationships have different types: between John Lennon and the Beatles there is the relationship "is member of"; between the Beatles and their concert the relationship could be called "performed at" – if we want to generalise more, "participates in" is perhaps a more practical type of relationship.
The same applies for attributes: in the case of a person these may be the name or the date of birth. Specific persons (objects of the type 'person') may then have name, date of birth, place of birth, address, colour of eyes, etc. Events may have a location and a time span. Attributes and relations are always defined with the object itself.
We can finely or less finely divide types of objects: we can put the football world cup in 1970 into the same basket as all the other events (the book fair in 2015, the Woodstock festival, etc.), then we only have one type called "event" or we differentiate between sport events, fairs, exhibitions, music events, etc. Of course, we can divide all these types of events even finer: sport events may, for example, be differentiated by the types of sports (a football match, a basket ball match, a bike race, a boxing match).
In this manner we obtain a hierarchy of supertypes and subtypes:
The hierarchy is transitive: when we ask k-infinity about all events, not only all specific objects are shown which are of type event, but also all sports events and all bike races, boxing matches and football matches. Hence, since the type "boxing match" is not only a subtype of "sport event", k-infinity will reject a direct supertype / subtype relationship between event and boxing match – with a note that this connection is already known.
The hierarchical structure does not necessarily have to have the structure of a tree – a type of object may also have several upper types. However, an object may only have one type of object.
If we then wish to join the aspects of a concert and major event we cannot do this in the specific concert with Paul McCartney because we need the type of object "stadium concert" in order to do this:
Type hierarchy with multiple inheritance
The affiliation of specific objects with a type of object is also expressed as a relation in k-infinity and may as such be queried:
When do we differentiate between types at all? Types do not only differ in icon and colour – their properties are also defined in the types and when queried, the types can also easily be filtered. The inheritance plays a major role in all these questions: properties are inherited, icons and colours are inherited and when, in a query, we say that we wish to see events, all objects of the subtypes are also shown in the results.
Inheritance makes it possible to define types of relations (and types of attributes) further up in the hierarchy of the object type and hence use them for different types of objects (e.g. for bands and other organisations.
Creating specific objects
Specific objects (in the knowledge builder they are called "instances") may be created everywhere within the knowledge builder where types of objects can be seen. Based on the types of objects, objects can be newly created via the context menus.
An object can be created by means of the button "new" and using the named entered
In the main window below the header there is the list of specific objects already available. In order that objects cannot inadvertently be created twice, the name of the object can be keyed into the search button in the header. The search does not, by default, differentiate between upper and lower case and the search term may be cut off left and right (supplement by placeholders "*" and "?"):
Editing objects
After entering and confirming the name of the object, further details for the object created may be keyed into the editor. The object may be assigned attributes, relations and extensions by using the respective buttons.
When editing an object we can, in addition to linking it to another object, also generate the target of the link if the object does not already exist.
For example, members of a music band are documented completely. Via the relation, we want to link the member Ringo Starr with the object "The Beatles". If it is not yet clear whether the object Ringo Starr is already documented in k-infinity you can use the search button to ascertain this,
or via the icon button, select 'Choose relation target' from a searchable list with all feasible targets of relation.
Deleting the relation has a member may be accomplished in two different ways:
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.
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:
In order to display objects in the graph editor there are different options:
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.
Within the graph editor more operations may be carried out via the context menu by using a right mouse click on the object. Partly, this context menu offers the same functions as the form editor but it also contains more graph editor specific components.
This context menu provides the following functions:
Selection of several nodes
Nodes may be marked in the graph editor – either by a mouse click (Shift key for repeated selection) or by making a box around the nodes to be marked with the mouse. Using the options "select all" and "select nothing", all or no nodes will be marked in the graph editor. Marked nodes are characterised by a red circle.
The following actions are available for several marked nodes:
The graph editor has both a menu bar and context menus which can be invoked from a node or a relation using the right mouse button. Actions from the menu bar are related to the entire graph editor or to marked nodes, actions from a context menu are related to a selected node or a relation.
The context menu for relations in the graph editor may be invoked by using a right mouse click on the relation:
Das Menü „Ansicht“ stellt viele weitere Funktionen für die graphische Darstellung von Objekten und Objekttypen zur Verfügung:
Voreinstellungen: Öffnet das Menü für globale Einstellungen (auch zugänglich im globalen Einstellungsfenster - Registerkarte „Persönlich“ - Graph). Hier kann eingestellt werden, ob Attribute, Relationen und Erweiterungen in einem kleinen Mouse-over-Fenster über dem Objekt erscheinen sollen und wie viele Knoten sich im Graph-Editor maximal in einem Schritt einblenden lassen.
Hintergrund ändern: Hier kann die Farbe des Hintergrunds geändert oder ein eigenes Bild als Hintergrund eingefügt werden.
Knoten automatisch ausblenden: Blendet automatisch überschüssige Knoten aus, sobald mehr als die gewünschte Anzahl an Knoten sichtbar ist. Die Anzahl kann im Eingabefeld „max. Knoten“ in der Symbolleiste eingestellt werden.
Knoten automatisch positionieren: Führt für neu eingeblendete Knoten automatisch die Layoutfunktion auf.
Beschreibungen fixieren: Mit dieser Option sind die Namen aller Relationen immer sichtbar, nicht nur beim Roll-over mit der Maus. Alternativ kann gezielt im Kontextmenü einer Relation deren Beschreibung fixiert werden.
Interne Namen anzeigen: Blendet an Typknoten die internen Namen der Typen ein.
Ausgeblendete Kanten wieder darstellen: Alle Kanten, die per Kontext-Menü ausgeblendet wurden, werden wieder angezeigt.
Kanten automatisch wieder abblenden: Die Kanten werden abgeblendet.
Das Fenster des Graph-Editors und das Hauptfenster des Knowledge-Builders stellen noch weitere Menüpunkte zur Verfügung, die bei der Modellierung eine Hilfestellung bieten können.
Links im Fenster des Graph-Editoren befindet sich die Legende der Objekttypen.
Diese Legende zeigt die Objekttypen zu den konkreten Objekten auf der rechten Seite.
Durch Drag&Drop eines Eintrags aus der Legende in die Zeichenfläche können Sie ein neues konkretes Objekt des entsprechenden Typs erzeugen.
Über das Kontextmenü auf den Legendeneinträgen können alle konkreten Objekte dieses Typs aus der Darstellung ausgeblendet werden. Hier lassen sich auch Legendeneinträge „festhalten“, und neue Objekttypen in die Legende aufnehmen (unabhängig davon, ob konkrete Objekte von diesem Typ in der Darstellung vertreten sind).
Max Knoten: Wenn ein Knoten/Objekt viele Nachbarobjekte hat, ist es oft nicht sinnvoll, alle beim Klick auf den Anfasser gleich einzublenden. Hierfür kann an zwei Stellen eine maximale Anzahl einzublendender Knoten definiert werden.
Wird der Anfasser zur Einblendung der Nachbarobjekte angeklickt, erscheint anstelle der Objekte eine Auswahlliste.
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.
The principle of the type hierarchy was already presented in Chapter 1.2. If new types are to be created this is always done as a subtype of a type which already exists. Creating subtypes can be carried out either via the context menu Create -> Subtype
or in the main window using the tab "Subtypes" above the search field and the tab "new":
Changing the type hierarchy
In order to change the type hierarchy we have the tree of object types in the main window and the graph editor.
In the hierarchy tree of the object editor we will find the option "Removing supertype x from y" in the context menu.
Using this option we can remove the currently selected object type from its position in the hierarchy of the object types and with drag & drop we can move an object type to another branch of the hierarchy. If we hold down the Ctrl key when using the drag & drop function the object type will not be moved but additionally assigned to another object type. What still applies is: the hierarchy of the object type allows multiple assignments and inheritance.
Configuring object types with properties
In the simplest case we define relations and attributes with an object type such as "band" or "person" and thus make them available for the specific objects of this type. (For example the year and location the band was established, date of birth and gender of people, location and date of events.)
If the object type for which the properties are defined has more subtypes the principle of inheritance will take effect: properties are now also available for the specific objects of the subtypes. Example: as a subtype of an organisation, a band inherits the possibility of having people as members. As a subtype of "person or band" the band inherits the possibility of taking part in events:
The editor for the object type "band" with directly defined and inherited relations there.
With a specific object the inherited properties are available without further ado and the difference goes without notice.
Defining relations
When dealing with relations, the following basic principle governs at k-infinity: a relation cannot only be unidirectional. If we know of a relation for the specific person "John Lennon" to be "is a member of the band The Beatles" it then implies for the Beatles the contents "it has a member called John Lennon". These two directions cannot be separated. Therefore, k-infinity demands from us the types of source and target of the relations when creating new relation types – in our example that would be person and band as well as differing names: "is member of" and "has member".
Hence the relation is defined and can now be moved between objects using drag & drop.
Defining attributes
When defining new attribute types, k-infinity needs, above all, the technical data type as well as the name. The following technical data types are available:
Type of data | What do the values look like? | Example (music network) |
Attribute | abstract attribute, without an attribute rating |
|
Selection | freely definable selection list | design of a music instrument (hollowbody, fretless, etc.) |
Boolean | »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 | 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 |
Integer | numerical value without decimal places | runtime of a music title in seconds |
Geographical position | geographical coordinates in WGS84 format | location of an event |
Band | without attribute rating, serves as a medium for meta attributes to be grouped |
|
Internet link | link on a URL | website of a band |
Interval | date interval: interval of numbers, character string, time or date | period of time between the production of an album and its publication |
Password | 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 | 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.
Relation types and attribute types (in brief property types) are always properties of specific objects.
Creating a new relation type
Via the button "add relation" in the object editor the editor starts to create a new relation type.
Editor for creating a new relation type (see also Chapter 2.1 Defining types)
Name of new relation: names for relation types may be chosen freely within k-infinity but should be selected under the premise of a comprehensible data model. The following convention may be of help for this: the name of the relation is phrased in such a manner that the structure [name of the source object] [relation name] [name of the target object] results in a comprehensible sentence:
[John Lennon] [is a member of] [The Beatles]
Furthermore it is helpful when the opposite direction (inverse relation) takes on the word selection of the main direction: "has a member / is a member of".
Domain: here we define by which object types the relation has to be created: one object type forms the source of the relation and another object type the target. The tareget object type, in turn, forms the definition area of the inverse relation. To simplify matters, when creating you may only enter one object type at this stage. Afterwards, further object types may be defined in the editor for the relation type (see below).
Creating new attribute types
Via the button "define new attribute" in the object editor the editor starts to create a new attribute type:
Two-tier dialogue for creating a new attribute type
In the left-hand window the format of the attribute type is defined (date, floating point number, character string, etc.) After selecting and confirming the attribute type it can be further specified with the name of the attribute in the subsequent dialogue.
Supertype: here it is defined at what level in the hierarchy the attribute type should be placed.
May have multiple occurences: attributes may occur once or more than once, depending on the attribute type: a person only has one date of birth but may, for example, have several academic titles at the same time (e.g. doctor, professor and honorary consul).
Editing the details
The dialogues for creating new attribute types and relation types are reduced views of the editors for attribute types and relation types. To edit details of attributes and relations, editors with an enhanced scope of functions have to be started.
You can reach these two editors via a listing of the attributes and relations in the tab "Schema" in the object editor:
Alternatively, you can access them via the hierarchy tree in the left-hand side of the main window. The editors are started by a right mouse click on the relation or attribute in the context menu to be edited then clicking on "edit".
Below we can see the details of the definition of properties using the editor for the relation type as an example (the definition of attribute type is on of the subsets):
Defined for: here we can retroactively change with which object type the relation can be created. Relations may be defined between several objects and thus have several sources and targets.
Hence we can, for example, allow both persons and authors of songs in bands to be in the model or assigned to another location – even when they do not have a mutual super type. Using the button "Add" we can add more object types. Using the button "Remove" we can deprive the selected object type and all its objects from the possibility of taking on this relation.
"Change..." enables the replacement of an object type. Relations which already exist will then be deleted from the system. If there are any relations to be deleted a confirmation dialogue will appear prior to the implementation of the change.
Target: here you can retroactively change to which object types the relation can be drawn. In order to change the target of the object type you have to change to the inverse relation type: the button for changing has the name of the inverse relation type. After clicking on the button the inverse relation will appear in the editor and can be edited in the same manner as the previous relation.
Abstract: when we wish to define a relation which only serves for grouping but which is not characterised by specific properties, we define it as "abstract".
Example: if the relation "writes the song" is defined as abstract this means that when we create songs and their relation to artists or bands we can only give specific details (who wrote the text, who wrote the music). The unspecific relation "writes the song" cannot be created in the specific data, instead it can only be queried.
May have multiple occurences: it is a feature of relations whether they may occur more than once. Example: the relation "has a place of birth" may only occur once for each person, while, for example, the relation "is a member of" may occur several times for each person. Thus, logical contents may be modelled precisely. As an example of this, persons who are musicians can only have one place of birth (also at the same time) but be a member of several bands. Whether the relation may occur more than once will be stated independently for both directions of the relation: a person can only be born in one place but this place could be the place of birth for several people.
This option can only be switched off if the relation does not occur more than once in the actual database. If it does occur more than once the system cannot automatically decide which relation is to be removed.
Mix-In / unidirectional relation: see Chapter 2.4.1 Enhancements.
Main direction: each relation has an opposite direction. In the core both directions are of the same value but there are two places where it is helpful to define a main direction:
In k-infinity you can make changes to the runtime of the model:
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.
Since k-infinity always ensures that the objects and properties are in accordance with the model, deleting an object type or, where necessary, an operation has far-reaching consequences: when an object type is deleted, all its specific objects are also deleted – analogue to the relation and attribute types.
In this process, k-infinity always provides information on the consequences of an operation. If an object has to be deleted, k-infinity lists all properties which will thus be removed in the confirmation dialogue of the delete operation:
k-infinity controls where, by the change, objects, relations or attributes become lost. The user is made aware of the consequences of the deletion.
Not only the deletion, but also conversion or change of the hierarchy type may have its consequences. For example, when objects have properties which no longer comply with the model after a change in type or change in the inheritance.
Let us assume that we delete the relation "is supertype of" between "event" and "concert" and thus remove the object type "concert" and all its subtypes from the inheritance hierarchy of event to add them to "work", for example. In this case, k-infinity draws our attention to the fact that the "has participants" relations of the specific concerts would be omitted. This relation is defined in "event" and would thus no longer apply to the concerts.
There are possibilities for preventing the omission of relations as a result of model changes. If an object type has to move within the type hierarchy, for example, the model of the affected relation has to be adapted prior to this.
For example, if "concert" is to be located under "work" within the hierarchy and no longer under "event". To this end, the relation "has participants" will be assigned to a second source: that can be either the object type concert itself or the new item "work". The relation will hence not be lost.
k-infinity pays particular attention to the type hierarchy. If we delete a type from the middle of the hierarchy or remove a super/sub relation type, k-infinity then closes the gap which has ensued and puts back the types which have lost their supertypes into the type hierarchy to the extent that they keep its properties as far as possible.
Special functions
Changing type: objects already in the knowledge network may be moved to objects of another type. For example, if the object type "event" differentiates to "sports event" and "concert". If there are already objects of the type sports event or concert in the knowledge network, they may be selected from the list in the main window and quite simply moved to a new, more suitable object type using drag & drop.
Alternatively, we can find more information in the context menu under the item "edit".
Select type: using this operation we can assign a property to an object.
Reselect relation target: in relations this does not only apply to the source, but also the relation target.
Convert subtypes to specific objects (and vice versa): the border between object types and specific objects is, in many cases, obvious but not always. Instead of setting up only one object type called "musical direction" as in the case of our sample project, we could have set up an entire type hierarchy of musical directions (we decided against this in this network because the musical directions classify so many different things such as bands, albums and songs and therefore they do not provide any good types). It may happen, however, that we change our minds in the middle of the modelling. For this reason, there is the possibility of changing subtypes into specific objects and specific objects into subtypes. Any relations which may already exist will be lost in the process if they do not match the new model.
Converting the relation: source and target of the relation will remain the same, only the relation type will be converted.
Converting the attribute: source/object will remain the same but it will be assigned to another attribute type:
When converting the individual relations we are usually quicker when we delete these and replace them with another one. However, it may happen that meta properties are attached to the properties which we do not want to lose. On the other hand, the converting operations are also available for all properties of a type or a selection thereof. A prerequisite is, of course, that the new relation or attribute type is also defined for the source and target objects.
If changes are made to the model, consideration should always be given to the fact that restoring a previous condition may only be carried out by installing a backup. Analogue to the related databases there is no "reverse" function.
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.
As a further means of modelling, k-infinity offers the possibility of enhancing objects.
For example, if a person performs the role of a guitarist in a band but plays another kind of instrument in another band. In addition, the person exercises the role of the composer.
The fact that one person can play different roles in a knowledge network may be regulated via a special form of a object type. This may not contain any objects, but enhance objects from another object type (e.g. in this case "person"). For this purpose, the object type "role" is implemented into the knowledge network, for example and the different roles created for persons as subtypes: guitarist, composer, singer, bassist, etc. In order that these "role object types" may enhance objects this function will be defined in the editor for the object type by checking the box "type can extend objects":
Enhancements are displayed in the graph editor as a blue dotted line:
As a result of this enhancement we have achieved several things simultaneously:
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.
A special form of the relation is the shortcut relation. Hidden behind this is the possibility to shorten several relations already available and defined and which are present in the semantic graph database in a connected row by means of a suitable relation. In this manner the system can, to a certain extent, draw a direct conclusion from A to B from an object A in the semantic graph database which is connected to an object B via several nodes.
For example, a band publishes a recording media in a certain style of music, ergo this style of music can likewise be assigned to this band:
In the form editor the inferred relation path is defined via the relations "is author of" and "has style".
In the queries the shortcut relation can be used like any other relation as well.
In the current version of k-infinity it is recommended that several nodes and edges be queried via search modules as a result of the improved overview in the structured queries.
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.
The attributes "character string", "data file attribute" and" selection" may be created multilingually. In the case of the character string attribute and data files, several character strings may then be entered for an attribute:
With data file attributes several images (e.g. with labels in other languages) may be uploaded analogically. In the case of selection attributes all selection options are deposited in the attribute definition; here it doesn't matter in which language the selection for the specific object is made.
All other attributes are depicted in the same manner in all languages, e.g. Boolean attributes, integers or URLs.
If the image deviates in other languages attributes adapt their image automatically, depending on the language: for example, dates according to European spelling day|month|year are shown in US format month|day|year.
In k-infinity separate attributes are not simply deposited for values in other languages, instead they remain as a separate layer for an attribute with language variations. You don't have to bother about the management of different languages when developing an application, but only the desired language for the respective query:
In k-infinity preferred alternative languages can be defined: if there is no attribute value, e.g. a descriptive text in the queried language the missing text can be shown in other languages if they are available. The order of sequence of the alternative languages may also be defined.
Multilingual settings are, for example, used in search.
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.
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.
Interaction
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.
Ein Hauptzweck der Strukturabfragen ist, in Anwendungen zu einem bestimmten Kontext Informationen zu liefern. Die Strukturabfrage aus dem letzten Abschnitt kann z.B. dem Endnutzer in einem Musikportal zu einem Thema wie Liebe, Drogen, Gewalt usw. eine Liste aller Künstler oder Bands generieren, die das Thema in ihren Liedern behandeln.
Dazu wird die Strukturabfrage in der Regel über ihren Registrierungsschlüssel in einen REST-Service eingebaut. Das Thema, für das sich der Nutzer gerade interessiert, geben wir der Abfrage mit seiner ID als Parameter mit.
Beispielszenario: Ein Nutzer sucht durch Eingabe eines Suchstrings nach einem Thema. Es liegt also keine ID vor, sondern nur einen String anhand dessen das Thema identifiziert werden soll. Dabei soll aber im Suchergebnis gleich angezeigt werden, welche Bands Songs zu dem Thema geschrieben haben. Zu diesem Zweck kann eine Strukturabfrage als eine Komponente in eine Such-Pipeline eingebaut werden - hinter die Abfrage, die den Suchstring verarbeitet.
Strukturabfragen sind unter anderem deshalb ein zentrales Werkzeug innerhalb von k-infinity, weil auch die Bedingungen für Rechte und Trigger mit Strukturabfragen formuliert werden: Angenommen es wird in einem Musikportal nur Künstlern und Bands erlaubt, Kommentare zu hinterlassen. Im Rechtesystem lässt sich entsprechend formulieren, dass nur Künstler und Bands, die zu einem bestimmten Thema mindestens einen Song geschrieben haben, zu diesem Thema Kommentare hinterlassen dürfen. Strukturabfragen können auch in Exporten benutzt werden, um zu bestimmen, welche Objekte exportiert werden soll.
Alle diese Verwendungen haben eines gemeinsam: wir sind nur an qualitativen, keinen gewichteten Aussagen interessiert. Das ist die Domäne der Strukturabfragen gegenüber den Such-Pipelines.
Nicht zuletzt sind Strukturabfragen auch Hilfsmittel für uns Knowledge-Engineers. Mit ihnen können wir uns einen Überblick über das Netz verschaffen und Reports sowie To-do-Listen zusammenstellen. Beispielfragen, die mithilfe von Strukturabfargen beantwortet werden können, sind:
Für diese Verwendung ist es sinnvoll, die Strukturabfragen in Ordnern organisieren zu können.
One main purpose of the structured queries lies in the applications for a certain context to provide information. The structured query in the last paragraph may generate, for the user, a list of all artists or bands in a music portal who deal with the topics of love, drugs, violence, etc. in their songs.
For this purpose, a REST service is usually implemented via their registration key. The topic in which the user is interested just now is the one we enter into the query with his ID as a parameter.
The following is an example of this scenario: a user searches for a topic by entering a search string according to a topic. There is therefore no ID, but only a string on the basis of which the topic should be identified. Thereby, the search results should show which bands wrote songs on this topic. For this purpose, a structured query can be installed in a search pipeline as a component – behind the query which processes the search string.
Therefore, structured queries are, among other things, a central tool within k-infinity because the conditions for rights and trigger are also phrased using the structured queries: assuming only artists and bands are allowed to leave comments within a music portal. With the rights management it may be stated that only artists and bands who have written at least one song on a certain topic are allowed to leave their comments on this topic. Structured queries may also be used in exports in order to determine which objects are to be exported.
All these applications have one thing in common: we are only interested in qualitative, not weighted statements. That is the domain of the structured queries in comparison to the search pipelines.
Last but not least, structured queries are also tools for us knowledge engineers. With them we can obtain an overview of the network and compile reports as well as to-do lists:
For this application it makes sense to be able to organise structured queries into folders.
Implement
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.
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.
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
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.
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:
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).
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").
Search macros: other structured queries but also other searches can be integrated into structured queries as macros. In doing so, there is the possibility of outsourcing repeating, partial queries into your own macros and thus adapting the behaviour at a central location when changing the model. A macro can be integrated into each condition line.
An example from our music network: from bands to all their achievements, no matter whether they are albums, songs which are directly assigned to the band or songs on the albums of the bands. We need these partial queries more frequently, for example in a structured query which returns the bands to a certain mood. We start this query with a type condition - we are looking for bands - and integrate the pre-defined module as a condition for these bands:
The objects which return those which are integrated into the structured query as macros have, of course, to match the condition with which they are linked from the point of view of their type. With the aid of the identifier function, the query (from the "invoking" query) can still be continued with additional conditions. In our case the albums and songs from where the macro query originates are defined by the invoking query: namely albums and songs with the mood "aggressive". Integrating the search macro into the structured query is carried out through the menu "Query structure". Under structured query macro (registered) there is a selection list with all the registered macros.
Simple search: using the search mode "simple search" the results of a simple search or a search pipeline may serve as input for a structured query. Each respective simple search can be selected by means of the selection symbol. The input box contains the search entry for the simple search. Further conditions can enable a simple search to be filtered further, for example.
Cardinality condition: a search for attributes or relations without its own conditions may be carried out with a cardinality operator (characterised by a hash tag #). You may use the cardinality greater than or equal to, less than or equal to and equal. The normal equal operator of the relation or attribute condition corresponds to greater than or equal to 1.
We have thus covered everything we can find within the menu "Query structure":
The type condition
The beginning of the structured query determines which objects should appear as the results. To do this you click on the type icon for the first condition and select "Choose type" in the menu, the input mask then starts in which the name of the object can be entered.
Alternatively, you can simply overwrite the text behind the type icon with the name of the object.
In the second step the relation condition is added. For example, a search is made for the place of origin of a band and "has location" is set as a relation condition. The target type of the relation is added automatically which, however, can also be changed (if, for example, the "has location" relation for countries, cities and regions applies but we only wish to have the cities).
There are further functions available for a type condition. In the item for this there is the item "Schema" in the general condition menu which we can reach via the button : several types of conditions are defined consecutively what is interpreted by "or" in the query. For example, we search for works or events on a particular style of music as follows:
We can just search for types of objects instead of specific objects or both at the same time by checking the boxes "Subtypes" and "Instances" in the menu "Schema".
This is what the condition looks like when a search is made for both specific works as well as subtypes of the work (albums and songs).
Without inheritance: normally, the inheritance starts automatically with all types of conditions of the structured query. If a search is made for events in which bands play a certain style of music, all subtypes of events are then incorporated into the search and then we are provided with indoor concerts, club concerts, festivals, etc. In the vast majority of cases this is exactly what is desired. For exceptions there is the possibility of switching off the inheritance and restrict the search to direct objects of the type event, i.e. by excluding the subtypes of objects.
Operators for the comparison of attribute values
Attributes may also play a role as conditions for structured queries. For example, if it does not suffice to only identify objects which show an exact predefined value or the value entered as a parameter. For instance, bands which were founded after 2005 or songs which are more or less 3 minutes long or songs which contain the word "planet" in their title. These require comparison operators. The type of comparison operators which k-infinity offers us depends on the technical data type of the attribute:
Comparison operators for dates and quantities
The comparison operator Exactly equal constitutes a special case: the index filter is switched off and a search can be made after the special character * which is normally used as a wildcard.
The comparison operator Between requires spelling of the parameter value with a hyphen, e.g. "10.1.2005 - 20.1.2005".
The comparison operator Distance requires spelling of the parameter value with a tilde, e.g. "15.1.2005 ~ 5" – i.e. on 15.1.2005 plus/minus 5 days.
Comparison operators for character strings
Comparative value results from the script: attribute value conditions may be removed from partial searches and replaced by a script and attribute condition. The results of the script are then used as a comparative value for the attribute value condition, e.g. if the comparison operators do not suffice for a specific query.
Identifying objects
The structured query provides several options for identifying objects within the knowledge network. To simplify matters, the previous examples often defined the objects. This type of manual determination may, in practice, be of help in testing structured queries or determining a (replaceable) default for a parameter entry.
At this point we have already become familiar with the combination with the name attribute which can, of course, be any random attribute. In the menu item "Identify" we will find some more options for defining starting points for the structured query:
Access right parameter: the results of the query may be made dependent on the application context. This particularly applies in connection with the configuration of rights and triggers when, generally speaking, only "user" is usable.
Script: the objects to be entered at this point are defined by the results of the script.
Semantic element with ID: you may also determine an object via its internal ID. This condition is normally only used in connection with parameters and the use of the REST interface.
In folder: using the search mode "in folder" the contents of a collection of semantic objects can be entered into a structured query as input. The selection symbol will enable you to select a folder within the work folder hierarchy. The objects of a collection are filtered with respect to all other conditions (including conditions for terms).
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?
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.
Placeholder/wildcard
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:
The option "Always wildcards" works as if we had actually attached an asterisk in front and/or behind. Behind automatic wildcards there is an escalation strategy: in the case of automatic placeholders, a search is made first with the exact user entry. If this does not deliver any results a search will be made with a placeholders, depending on which placeholders have been set. With the option prefix or substring there is once again a chronological order: in this case you look for the prefix first (by attaching a wildcard) and, if you still can't find anything, you make a search for a substring (by means of a prefix and attaching a wildcard).
If you are allowed to attach placeholders in your search you can state in the box minimal number of characters how many characters the search entry must show to actually add the placeholders. By entering 0 this condition is deactivated. This is particularly important if we set up a type ahead search.
With the weighting factor for wildcards you can adapt the hit quality to the extent that the use of placeholders will result in a lower quality. In this manner we can, if we want to give the hits a ranking, express the uncertainty contained in the placeholders with a lower ranking.
If the option "No wildcards" is selected the search entry will not be changed. The individual placeholder settings will then not be available.
The user can, of course, him/herself use placeholders in the search entry and these can be included in the search.
Apply query syntax: when the box for the option "Apply query syntax" has been checked a simplified form of the analysis of the search input is used in which, for example, the words "and" and "or" and "not" no longer have a steering effect. Nevertheless, in order to be able to define how the hits for the tokens should be compiled, the default operator can be switched to "#and" or "#or". What applies to all linking operators is the fact that they do not refer to values of individual attributes, but to the result objects (depending on whether "hits only for attributes" has been set). A hit for online AND system thus delivers semantic objects which have a matching attribute for both online and the system (which is not necessarily the same).
Filtering: simple searches, full-text searches and also some of the specialised searches may be filtered according to the types of objects. In the example described in the last paragraph we made sure that the search results only included persons and bands. Attributes which do not match a possible filtering are depicted in red bold print within the search configuration dialogue. In our case this could be an attribute "review", for example, which is only defined for albums.
Translated attributes: in the case of translated attributes we can neither select a translation, nor have the language dynamically defined. Search for multilingual attributes, then in the active language or in all languages, depending on whether the option "in all languages" is checked.
Query output: a maximum query output may be defined by entering the maximum number in the "results" box. This checkbox will then limit the query output and the mechanism can be activated or deactivated. By entering the number in the output the checkbox will automatically be activated. Caution: if the number is exceeded no output will be shown!
Server-based search: generally speaking, each search can also be carried out as a server-based search. The prerequisite for this is that an associated job client is running. This option can be used when it can foreseen that very many users will make search queries. By outsourcing certain searches to external servers, the k-Infinity server will be disburdened.
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.
If we want to view or search through longer texts word by word, e.g. description attributes we recommended the use of full-text index. What does something like that look like?
The full-text index records all terms/words which occur within a portfolio of texts so that k-infinity can quickly and easily look up where a particular word can be found in which texts (and in which part of the text).
"Texts", however, are not usually separate documents within k-infinity, but the character string attributes which have to be searched through. Their full-text indexing is a prerequisite for the fact that these attributes are offered in the search configuration.
Even full-text indexing concerns the deviations between the exact sequence of characters within the text and the text which is entered in the index and which can hence be retrieved accordingly. An example of this: a message from the German music scene:
In this example we find a small part of the filter and word demarcation operations which are typically used for setting up a full-text index:
Word demarcation / tokenizing: often in punctuation such as exclamation marks are placed directly on the last word of the sentence without a space in between. In the full-text index, however, we want to include the entry {tour}, not {tour!} – hardly anyone will search for the latter. For this purpose, when setting up the full-text index we have to be able to specify that certain characters do not belong to the word. The decision is not always so easy: In a character string such as "Cuddle-Classic" which occurs in a text we have to decide whether we want to include it as an entry in the full-text index or as {cuddle} and {classic}. In the first instance our message will then only be found if an exact search is made for "Cuddle-Classic" or, for example, "*uddle-c*", in the second instance for all "classic" searches.
What we will probably keep together in spite of the occurrence of punctuation, i.e. exclude from tokenizing, are abbreviations: when AC/DC come to Germany o.i.t. (only in transit) it is probably better to have the abbreviation in the index instead of the individual letters.
Filter: by using filter operations we can both modify words when they are included in the full-text index and also completely suppress their inclusion. Known: stop words, at this point we can maintain a list. Moreover, we probably do not want individual words (Bela B.) to be in the index like this – the likelihood of confusion is too great. Using other filters we can restore words to their basic forms or define replacement lists for individual characters (e.g. in order to eliminate accents). Other filters, in turn, clear the text of XML tags.
We can set all this in the admin tool under "index configuration". We can then assign these configurations (in the knowledge builder or in the admin tool) to the character string attributes. The index configuration is organised in such a manner that filtering can take place before the word demarcation and after the word demarcation.
The full-text search does not affect the wildcard automatism of the other queries but the user may, of course, provide his input with wildcards.
Search pipelines enable individual components to be combined to complex queries. Single components perform operations in the process, e.g.:
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.
Example
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.
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:
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%.
Weighted relation/attribute
Based on semantic objects we can, in this step, traverse the graph and assemble relation targets or attributes. For this purpose we have to specify the relation or attribute type.
Caution: outputs are only for the assembled targets and no longer for the output quantity. If these have to be displayed we have to later summarise the input and output hits.
In traversing a relation the weighting of the hits can be influenced. Let us assume that we want to semantically expand the "output mood" of our search with "sub moods", but this indirection is to suppress into a ranking: links to bands which extend via the sub moods should not count as strong as links via an output mood. To this end we can, for example, allocate a general value of 0.5 to the relation route and calculate or multiply it with the input weight. Then the sub moods added to this step will only count half as much as the direct ones.
Instead of specifying a general weight for the route of a relation we can also read the value from the meta property for the basic type of floating point number of the relation selected. if this attribute is not available or none was configured the standard value will be used. The value should range between 0 and 1. The generation of hits may be configured in detail: for relations a new hit can also optionally be created for the relation source (instead of for the relation target).
If a relation has been selected as a property and hits for relation targets are created we can also optionally pursue the relation transitively. The value of the quality decreases with each step until it falls below the threshold value. If an object has more relations than specified for a maximum fan-out these relations will not be pursued. The higher the attenuation factor, the more the value of the quality decreases.
Structured query
Using structured query components we can either search for semantic objects / move from an existing quantity to other objects (as with the weighted relation) or filter an amount.
When we search for objects we enter our number of outputs from one of the previous steps into the search via the name of the parameter. (In general: within the expert search, variables of the search pipeline such as a search string can be referenced via parameters). In this case the input remains empty.
In contrast, for filtering we specify an amount of objects. All objects which match the search condition are included in the output. Objects which do not match the search condition may, as an option, be saved in another variable (rest).
We can either define the structured query into the components ad hoc or use an existing structured query.
Caution: when an existing search has been selected a copy is created and any changes we make to the structured query for the purpose of the search pipeline result in changes for all other applications as well.
Query
Using the component "search", you can initiate simple searches, full-text searches and other search pipelines. Simple searches and full-text searches are provided with a character string, e.g. with the search string: this is a parameter which is available in all search pipelines to process the user input. The amount of hits for the search invoked is conveyed to the output of this component.
By linking search pipelines to other search pipelines we can combine frequently occurring sub-steps. Several parameters and entire hit lists can be conveyed to other search pipelines. Using linked search pipelines we can also exchange several parameters, i.e. in the linked search we can access the output from each sub-step of the surrounding search and vice versa. When we go to "selected parameters" we can re-name them if we want to use a hit list from the linked search but have already used the name. Alternatively, we can simply adopt some of the parameters from the linked search in order to avoid such conflicts.
Merge hits
This component enables us to merge several hits lists from different, previous steps. The following methods are available for merging:
Union: all hits which occur in at least one of the amounts are displayed as output.
Intersection: only hits which occur in all quantities are displayed as output.
In the case of union amounts and overlap it may happen that a semantic object occurs in several hit lists and then has to be calculated as an overall hit with new hit quality. For this purpose we again have the aforementioned methods of calculation available.
Difference: one of the hit lists has to be defined as the output quantity. The other quantities are subtracted from this.
Symmetric difference: The output quantity comprises objects which are only contained in an exact partial quantity (= everything except for the average of two quantities).
Three different types of overall hits can be created. The selection is then particularly relevant when the partial hits contain additional information.
Merge partial hits
In individual processing it is often necessary to create an overall amount of partial hits. This enables the component "merging partial hits". This merges all hits of one or several partial hit quantities. The difference between merging hits is that the merge does not take place until the end and not for each single quantity of partial hits. This is particularly relevant for the calculation of the quality because merging hits, e.g. in median would provide false ratings.
Script
A search pipeline may contain a script (Javascript or Kscript). This can access the variables of the search pipeline. Moreover, a script can convey several parameters to the search pipeline. The output of the script is used as the output of the component.
The Javascript API and KScript are described in separate manuals.
Set quality from attribute value
We can adopt the quality rating from an attribute of the semantic object for hits. If the object does not have this exact attribute the standard rating is used. The rating should range from 0 and 1.
Compute quality from weighted qualities
In order to adapt the quality of a search hit it may be helpful to calculate an overall rating from individual sub-qualities, whereby the qualities have to be available as numerical values. The new overall quality is calculated from these values.
Compute overall quality of hits
You can calculate the overall quality of a hit list from the quality ratings of each hit list.
Filter quality
We can limit hit lists to hits whose quality rating lies within the predefined limits (minimum and maximum). Normally, we like to filter out hits which are below a certain quality threshold.
Limit number of hits
If the overall number of hits within a hit list is to be limited we can add the component "limit number of hits". Using the option "do not split hits of the same quality" we prevent an arbitrary selection from being made from hits of the same quality in order to maintain the overall number. We then receive more hits than predefined.
In some very special cases we can also randomly select the hits, e.g. when we have a large amount of hits of the same quality and want to generate a preview.
Scale quality
The quality ratings of a hit list can be scaled. A new hit list with scaled quality ratings is calculated and the calculation follows in two steps:
Compute hits quality
With the aid of a KPath printout a new hit with calculated quality will be created for a hit. The KPath printout is calculated on the basis of the input.
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.
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.
Regular expressions are a powerful means of searching through databases for complex search expressions, depending on the task concerned.
Search with regular expressions | hit |
The [CF]all | the call, the fall |
Car. | cars |
Car.* | cars, caravans, Carmen, etc. |
[^R]oom | doom, loom, etc. (but not room) |
As search inputs, k-infinity supports the standard also known from the standard known from Perl which, for example, is described in the Wikipedia article for regular expression.
The search in folders is carried out in names of folders and their contents:
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.
Along with the objects and their properties we also create diverse other elements in a typical project: for example, we define queries and imports/exports or write scripts for special functions. We can organise everything which we create and configure in folders.
The folders are shared with all others who are working on the project. If we do not wish to do this we can deposit things in a private folder, e.g. for test purposes. This is only visible for the respective user.
A special form of the folder is the collection of semantic objects in which we can save objects manually by drag & drop for processing at a later date. To do this, we can simply push them into the folder using drag & drop and additionally there are operations for keeping output lists in folders. The collection of semantic objects merely keeps references on the objects: at that point in time when we delete one of these objects it will also be deleted in the collection.
Registration
Queries, scripts, etc. may be mutually invoked (a query may be setup in another query or in a script; conversely a script may be invoked from a search pipeline). For this purpose, there are registration keys with which can equip queries, import/export illustrations, scripts and even collections of semantic objects and structured folders to enable them to provide other configurations with functionality. The registration key has to be clear. Everything which a registration key contains will automatically be adopted in the folder "registered objects" or in a sub folder of this type.
Shift, copy, delete
Let us assume we have a folder named "playlist functions" in our project. This would perhaps contain an export, some scripts and a structured query "similar songs" which we want to use in a REST services. At that point in time when we give the structured query a registration key it will be adopted in the folder "registered objects" (paragraph "technology"). I.e. the structured query "similar songs" will appear in the folder "registered objects" under "query". It will also stay there when we remove it from our project sub-folder "playlist functions". If we remove the registration key the query will automatically disappear from the registry.
The basic principle when deleting or removing: queries, imports and scripts may be contained in one or several folders simultaneously and must be in at least one folder. Not until we remove our query from the last folder will it actually be deleted. Only then does k-infinity also request a confirmation of the deletion action. The same applies to the removal of the registration key.
If we wish to delete the query in one step, regardless of in how many folders it is located, we can only do this from the registry.
Folder settings
In the folder settings we can define quantitative limits for search outputs, folders and object lists (lists of the specific objects in the main window of the knowledge builder by selecting an object type on the left-hand side). Automatic query up to the number of objects specifies up to what number of objects the contents of the folders are shown without any further interaction by the user. If the limit set there is exceeded, the list will first remain empty and in the status bar the message "query not implemented" will appear. Carrying out a search without any input in the input bar shows all objects. At least until the second limit is reached: maximum number of query outputs, maximum number of outputs in lists of objects – in this instance high values – after these values no more output in fact, queries have to restrict, e.g. in lists of objects in which we also have the beginning of the name in the input box.
Mit den Abbildungen von Datenquellen können wir Daten aus strukturierten Quellen in k-infinity importieren und Objekte und ihre Eigenschaften in strukturierter Form exportieren. Die Quellen können Excel/CSV-Tabellen, Datenbanken oder XML-Strukturen sein.
Die Funktionen für den Import und Export decken sich größtenteils und sind daher alle in einem Editor verfügbar. Um auf die Funktionen für den Import und Export zugreifen zu können, muss zunächst ein Ordner (z.B. der Arbeitsordner) ausgewählt werden. Dort kann über die Schaltfläche "Neue Abbildung einer Datenquelle" eine Datenquelle ausgewählt werden, aus der importiert, bzw. in die exportiert werden soll.
Alternativ findet man die Schaltfläche auch im Reiter "TECHNIK" unter "Registrierte Objekte" -> "Abbildungen von Datenquellen".
Folgende Schnittstellen und Dateiformate stehen für den Import und Export zur Verfügung:
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.
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.
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.
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.
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.
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".
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.
Auch Typen können importiert und exportiert werden. Nehmen wir beispielhaft an, wir wollten die Genres der Songs als Typen importieren.
Um einen neuen Typen abzubilden, wählen wir den Button "Neue Typabbildung".
Daraufhin müssen wir den Obertyp der neu anzulegenden Typen angeben, in unserem Beispiel wäre der Obertyp "Song":
Anschließend müssen wir angeben, aus welcher Spalte der importierten Tabelle der Name unserer neuen Typen entnommen werden soll:
Schließlich müssen wir unter dem Reiter "Import" noch angeben, dass unsere neuen Typen nicht abstrakt sein sollen:
Wenn wir nun die entsprechenden Songs ihren neuen Typen zuordnen wollen, müssen wir die Systemrelation "hat Objekt" verwenden. In älteren Versionen von k-infinity heißt diese Relation "hat Individuum". Als Ziel wählen wir alle Objekte von Song (inkl. der Untertypen) aus, die sich über das Attribut Name entsprechend der Spalte Songtitel definieren.
Importieren wir nun diese Abbildung erhalten wir das gewünschte Ergebnis. Die Songs, die bereits in der semantischen Graph-Datenbank vorhanden sind, werden durch die Import-Einstellung "Aktualisieren oder neu anlegen wenn noch nicht vorhanden" berücksichtigt und unter ihren neuen entsprechenden Typ geschoben, sodass kein Objekt doppelt angelegt wird (siehe Kapitel Einstellungen des Import-Verhaltens). Zur Erinnerung: Ein konkretes Objekt kann nicht mehreren Typen gleichzeitig angehören.
Es gibt noch einen Spezialfall. Angenommen, wir haben eine Tabelle, in der in einer Spalte verschiedene Typen vorkommen, dann können wir auch dies in unseren Importeinstellungen abbilden.
Dazu wählen wir die Abbildung der Objekte aus, denen wir die Untertypen zuordnen wollen (in diesem Fall "Objekte von Ort") und wählen dann unter dem Reiter "Optionen" den entsprechenden Obertyp aus.
Wichtig ist auch hier wieder nicht zu vergessen, unter dem Reiter "Import" festzulegen, dass der Typ nicht abstrakt sein soll, damit konkrete Objekte angelegt werden können.
Vorsicht: Angenommen, Liverpool existiert bereits im Wissensnetz, ist jedoch dem Typ "Ort" zugeordnet, da dieser bis zu diesem Zeitpunkt noch keine Untertypen wie "Stadt" und "Land" besessen hat. In diesem Fall wird Liverpool nicht unter dem Typ Stadt neu angelegt. Begründung: die Objekte des Typs Ort werden lediglich über das Namensattribut identifiziert, nicht jedoch über den Untertyp.
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 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:
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.
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 |
Aktualisieren | 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. |
Löschen | 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.
Wird diese Einstellung bei einem Attribut angewendet, sorgt sie dafür, dass der Wert aus der Tabelle den Attributwert genau eines bereits existierenden Attributs überschreibt. Mit dieser Einstellung werden keine neuen Attribute angelegt. Falls das Objekt mehr als einen Attributwert des ausgewählten Typs hat, wird kein Wert importiert.
Verwendet man die Einstellung "Aktualisieren" bei einem identifizierenden Attribut, während man bei dem dazugehörigen Objekt die Einstellung "Aktualisieren oder neu anlegen, wenn nicht vorhanden" verwendet, erscheint die Fehlermeldung "Attribut nicht gefunden", wenn das identifizierende Attribut nicht in k-infinity vorhanden ist.
Wird "Aktualisieren" bei einem Objekt angewendet, sorgt die Einstellung dafür, dass alle Eigenschaften des Objekts durch den Import hinzugefügt, bzw. geändert werden können. Neue Objekte werden nicht angelegt.
Beispiel: Angenommen wir führen eine Datenbank mit unseren Lieblings-Songs. Nun haben wir eine Liste mit Songs, die neue Informationen, enthalten. Wir wollen diese Informationen in unsere Datenbank bringen, gleichzeitig aber nicht, dass Songs importiert werden, die nicht zu unseren Lieblings-Songs gehören. Hierfür verwenden wir die Einstellung "Aktualisieren".
Der Song "About A Girl" ist bereits im Knowledge-Builder vorhanden.
Die Import-Tabelle enthält Angaben zu Dauer, Wertung und Autor des Songs.
Wir legen für Objekte von Song fest, dass sie aktualisiert werden sollen. Alle Attribute, Relationen und Relationsziele erhalten die Import-Einstellung "Aktualisieren oder neu anlegen wenn noch nicht vorhanden".
Das Ergebnis: Der Song wurde aktualisiert und hat nun neue Attribute und Relationen erhalten. Bereits vorhandene Eigenschaften wurden aktualisiert (Wertung).
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.
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.
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.
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.
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.
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.
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.
Die Import-Einstellung "Synchronisieren" ist mit Vorsicht zu genießen, denn sie betrifft als einzige Import-Einstellung nicht nur die Objekte und Eigenschaften in k-infinity, die in ihren Werten mit denen der Import-Tabelle übereinstimmen, sondern darüber hinaus alle Elemente des gleichen Typs in k-infinity. Wenn man eine Import-Tabelle mit k-infinity synchronisiert, bedeutet das prinzipiell, dass das Ergebnis in k-infinity nach dem Import exakt so aussehen soll wie in der Tabelle.
Wenn Objekte eines Typs synchronisiert werden, werden alle Objekte dieses Typs gelöscht, die nicht in der Import-Tabelle vorkommen. Die Objekte, die vorkommen, werden aktualisiert und die Objekte, die nicht in k-infinity vorkommen, werden neu angelegt.
Beispiel: Wir wollen die Musikmessen in k-infinity (links) mit einer Tabelle mit den Messen und ihrem Datum (rechts) synchronisieren:
Für die Objekte des Typs Messe wählen wir die Import-Einstellung "Synchronisieren", für die einzelnen Attribute Name und Messedatum wird die Import-Einstellung "Aktualisieren oder neu anlegen, wenn nicht vorhanden" verwendet:
Das Attribut Name ist das identifizierende Attribut von Messe. Für das Objekt Musikmesse 2015 fehlt der Name in der Import-Tabelle. Importieren wir die Tabelle so, erhalten wir dazu eine Fehlermeldung:
Nach dem Import sehen wir nun, dass durch den Import zwei Objekte entfallen sind, die keine Entsprechung in der Import-Tabelle hatten. Das Datum bei Musikmesse 2016 wurde aktualisiert:
Wenn Attribute synchronisiert werden gilt folgendes: Wenn ein bestehendes Attribut durch einen Import keinen Wert erhält, wird es für das entsprechende Objekt der Import-Tabelle gelöscht. Wenn das bestehende Attribut einen anderen Wert hat als in der Import-Tabelle, wird es aktualisiert, auch dann, wenn es mehrmals vorkommen darf. Wenn das Attribut noch nicht vorhanden ist, wird es neu angelegt.
Wenn Relationen synchronisiert werden, und sie erhalten keinen Wert werden sie für das entsprechende Objekt gelöscht. Wenn die bestehende Relation einen anderen Wert hat, als in der Import-Tabelle, wird sie aktualisiert. Sollte es das Zielobjekt noch nicht in der Datenbank geben, wird es neu angelegt, vorausgesetzt, das Zielobjekt hat eine entsprechende Import-Einstellung zugewiesen bekommen. Kann das Zielobjekt nicht neu angelegt werden, da hier beispielsweise die Import-Einstellung "Aktualisieren" zugewiesen wurde erscheint eine Fehlermeldung, die uns mitteilt, dass das Zielobjekt nicht gefunden wurde und es wird nicht neu angelegt.
Bei Abbildungen von Datenbank-Queries sind die Spalten, die zum Import zur Verfügung stehen, durch die Datenbanktabellen bzw. durch das Select-Statement vorgegeben. Beim Abbilden von Dateien können die Spalten mit der Schaltfläche "Aus Datenquelle lesen" aus der Datei übernommen werden. Man kann sie aber auch von Hand angeben. Dann hat man die Wahl, ob man eine Standard-Spalte oder eine virtuelle Eigenschaft anlegen möchte.
Will man aus der semantischen Graph-Datenbank exportieren, muss man die Spalten von Hand eingeben. Es können nur Standard-Spalten, nicht jedoch virtuelle Spalten exportiert werden.
Virtuelle Tabellenspalte / Virtuelle Eigenschaft
Virtuelle Spalten sind zusätzliche Spalten, die es erlauben die Inhalte, die wir in einer Spalte der zu importierenden Tabelle vorfinden, mit regulären Ausdrücken zu transformieren. Beispiel: Nehmen wir an in unserer Import-Tabelle steht bei den Jahreszahlen immer ein a.d. dahinter. Das können wir bereinigen, indem wir eine virtuelle Spalte anlegen, die aus der Spalte Jahr nur die ersten 4 Zeichen übernimmt.
Auch beim Export können wir virtuelle Eigenschaften definieren.
Den reguläre Ausdruck schreiben wir dabei einfach in die Spaltenüberschrift (in den Namen der Spalte). Dabei werden Teilzeichenketten, die in spitze Klammern <...> eingeschlossen sind, nach den folgenden Regeln ersetzt, wobei n, n1, n2, ... für die Inhalte anderer Tabellenspalten stehen.
Ausdruck | Beschreibung | Beispiel | Eingabe | Ausgabe |
<np> | Druckausgabe des Inhalts von Spalte n | Treffer: <1p>
| 1 (integer)
'keine' | 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 | <1c3-6>
<1c3>
<1c3-> | 'Spalten' | alte
ten
alten |
<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. | <1m0[0-9]>hi
<1m$>test | 01
123
(leer)
123 | hi
(leer)
test
(leer) |
<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 | 01
123 | (leer)
hallo
|
<neregex> | Selektiert alle Treffer von regex aus dem Inhalt von Spalte n. Einzeltreffer sind im Ergebnis durch Komma voneinander getrennt. | <1eL+>
<1e\d\d\d\d> | HELLO WORLD
02.10.2001 | LL,L
2001 |
<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' | <1f#,0.00>
<1fd/m/y>
<1fdd/mmm> | 3,1412
1234,5
1. Mai 1935
1. Mai 1935 | 3,14
1.234,50
1/5/1935
01/Mai |
Beispiele
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.
Datenbanken
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.
host:port_databaseName
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.
Encoding
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.
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.
Das Prinzip von XML-Dateien ist, die unterschiedlichen Angaben zu einem Datensatz über Tags (<>) explizit zu machen (nicht über Tabellenspalten). Dementsprechend sind Tags auch die Grundlage der Abbildung beim Import von XML-Strukturen in k-infinity.
Ein Beispiel: Nehmen wir an, unsere Liste von Songs liegt als XML-Datei vor:
<?xml version="1.0" encoding="ISO-8859-1"?> <Inhalt> <Album type="Oldie"> <Title>Revolver</Title> <Song nr="1"> <Title>Eleanor Rigby</Title> <lengthSec>127</lengthSec> <Interpret>The Beatles</Interpret> <Thema>Mental illness</Thema> <Mood>Dreamy</Mood> <Mood>Reflective</Mood> </Song> [...] </Album> [...] </Inhalt>
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:
//Album[@type="Oldie"]/Song
Erklärung im Einzelnen:
//Album | Selektiert alle Alben, wobei es keine Rolle spielt, wo sie sich im Dokument befinden. |
Album[@type="Oldie"] | Selektiert alle Alben vom Typ "Oldie" |
Album/Song | Selektiert 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.
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.
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.
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:
Eine häufig auftretende Aufgabe einer Attributabbildung ist der Import bestimmter Daten von konkreten Objekten, beispielsweise von Personen: Telefonnummer, Geburtsdatum etc.
Beim Import von Attributen, für die k-infinity ein bestimmtes Format verwendet (z.B. Datum), müssen die Einträge der zu importierenden Spalte in einer Form vorliegen, die von k-infinity unterstützt wird. Beispielsweise kann in ein Attributfeld vom Typ Datum keine Zeichenkette der Form ‚abcde... ‘ importiert werden; in einem solchen Fall wird für das entsprechende Objekt kein Wert importiert.
Die folgende Tabelle listet die von k-infinity unterstützten Formate beim Import von Attributen auf. Ein Tabellenwert ‚ja‘ oder ‚1‘ wird also beispielsweise korrekt als boolescher Attributwert (bei einem entsprechend definierten Attribut) importiert, ein Wert wie ‚ein‘ oder ähnliches hingegen nicht.
Attribut | Unterstützte Werte-Formate |
Auswahl | Die Abbildung der Import- auf die Attributwerte kann über den Reiter "Wertzuweisung" konfiguriert werden. |
Boolesch | Die Abbildung der Import- auf die Attributwerte kann über den Reiter "Wertzuweisung" konfiguriert werden. |
Datei | Import nicht möglich. |
Datum |
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. |
Ganzzahl |
|
Internet-Verknüpfung | Jede beliebige URL möglich. |
Uhrzeit | <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.
Der Export von Daten aus einer semantischen Graph-Datenbank in eine Tabelle wird in demselben Editor wie der Import und ganz analog vorbereitet:
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:
RDF ist ein Standardformat für semantische Datenmodelle. Mit dem RDF-Import und -Export können wir die Daten der semantischen Graph-Datenbank mit anderen Anwendungen austauschen, aber auch Daten von einem k-infinity-Wissensnetz in ein anderes transportieren.
Beim RDF-Export wird das gesamte Wissensnetz in eine RDF-Datei ausgeleitet. Der RDF-Import dagegen ist interaktiv und selektiv. D.h. wir können sowohl auf Schema-Ebene als auch bei den einzelnen Objekten und Eigenschaften angeben, was importiert werden soll und was nicht.
Abgleich der Objekte aus RDF mit den existierenden Objekten im semantischen Netz
Wenn die RDF-Daten aus demselben Schema stammen, wie das Netz in das sie importiert werden - z.B. aus einer Sicherungskopie - dann ordnet der RDF-Import Objekte und Objekttypen automatisch anhand ihrer ID zu. In den Import-Einstellungen können wir wie bei den Tabellen- und XML-Importen nun bestimmen z.B. existierende Objekte durch den Import aktualisiert werden sollen, ob neue angelegt werden etc.
Wenn die Daten aus einer anderen Quelle kommen, ist die Default-Einstellung der Import in ein eigenes Subnetz. Wir können aber auch diese externen Informationen in unseren Bestand integrieren - durch manuelle Zuordnungen mit der Abbilden-auf-Funktion im Mapping-Interface.
Daneben gibt es einige globale Einstellungen: Möchten wir überhaupt Änderungen am Schema erlauben? Erlauben wir es, dass Eigenschaften mehrfach angelegt werden? Schließlich werden alle Schema-Änderungen auf einem separaten Reiter angezeigt.
In diesem Abschnitt wird die Prüfung von Zugriffsrechten und Trigger behandelt:
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.
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:
Das Rechtesystem von k-infinity zeichnet sich durch einen hohen Grad an Flexibilität aus. Es kann auf verschiedene Erfordernisse eines Projektes zielgenau konfiguriert werden. Durch die Definition von Regeln im Rechtebaum bestehend aus einzelnen Filtern und Entscheidern, entsteht ein netzspezifische Konfiguration des Rechtesystems. Es gibt vielfältige Möglichkeiten diese Regeln für das Rechtesystem zusammenzusetzen, wodurch hoch differenzierte Rechte erzeugt werden. Es ist nicht möglich, alle möglichen Kombinationen von Konfigurationen aufzulisten; hier muss eine Beratung für den Einzelfall stattfinden.
Wie funktioniert das Rechtesystem?
Zugriffsrechte im System werden immer dann geprüft, wenn durch einen Nutzer eine Operation auf die Daten vorgenommen wird. Die grundsätzlichen Operationen sind:
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:
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]".
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
Vor der Aktivierung des Rechtesystems heißt der Ordner Rechte (deaktiviert). Wurde das Rechtesystem aktiviert heißt der Ordner Rechte. Durch eine Deaktivierung des Rechtesystem, werden keine Prüfungen der Zugriffsrechte mehr durchgeführt. Die definierten Regeln im Rechtebaum bleiben aber erhalten und werden bei einer erneuten Aktivierung des Rechtesystems wieder verwendet.
Beachte: Greift man vom Web-Frontend aus ohne spezielle Anmeldung auf ein Element zu, wird die unter Standard Web-Benutzer angegebene Person verwendet. Gewöhnlich legt man hier eine Scheinperson namens "anonymous" oder "Gast" an.
Damit das Rechtesystem auch im Knowledge-Builder funktioniert, muss der Benutzer-Accounts des Knowledge-Builders mit einem Objekt aus dem semantischen Modell verknüpft werden. Der Benutzer-Account kann nur mit Objekten des Typs verknüpft werden, der bei der Aktivierung des Rechtesystems im Feld Benutzertyp angegeben wurde.
Die Verknüpfung ist für die Verwendung des Operationsparameter Benutzer bei Suchfiltern bzw. bei für die Verwendung des Zugriffsparameters Benutzer bei Strukturabfragen generell notwendig, wenn das Rechtesystem bzw. die Suche nicht in einer Anwendung sondern im Knowledge-Builder selbst ausgeführt.
Anleitung für die Verknüpfung von Knowledge-Builder Nutzern mit Objekten des Personen Typs
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.
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:
Die Reihenfolge der Teilbäume ist also ausschlaggebend bei der Erstellung des Rechtebaumes. Die Reihenfolge der Bedingungen in einem Teilbaum dagegen (ob wir zuerst die Operation und dann die Eigenschaft prüfen oder umgekehrt) ist beliebig.
Für die Definition eines Teilbaumes des Rechtebaumes, ist es nicht unbedingt notwendig alle Filterarten zu verwenden. Ein Teilbaum besteht aus mindestens einem Filter und einem Entscheider. Eine Ausnahme ist der letzte Teilbaum der i.d.R. nur aus einem Entscheider besteht, der alle restlichen Operationen erlaubt (die vorher im Rechtebaum nicht verboten wurden) bzw. alle restlichen Operationen verbietet (die vorher im Rechtebaum nicht erlaubt wurden).
Beispiel: Rechtebaum
In dieses einfache Beispiel zeigt einen Rechtebaum bestehend aus einem Rechteteilbaum und einen Default-Entscheider, der alles erlaubt:
Im dem Rechteast wird das Löschen oder Modifizieren von den Attributen Name, Dauer und Erscheinungsdatum verboten. Dafür wird ein Operationsfilter verwendet, der die Operationen Löschen oder Modifizieren als Bedingung hat. Nur diese Operationen werden von diesem Operationsfilter durchgelassen. Der nächste Filter ist ein Eigenschaftsfilter, der auf bestimmte Eigenschaften filtert. In diesem Fall werden die Attribute Name, Dauer und Erscheinungsdatum gefiltert unabhängig davon, an welchem Objekt oder an welcher Eigenschaft diese gespeichert sind. Der letzte Knoten des Rechteast ist der Entscheider Verboten, der jede Zugriffsoperation verbietet, die auf die beiden vorgestellten Filter passt. Trifft eine der beiden Bedingungen nicht auf die Zugriffsituation zu, wird der Default Entscheider Erlaubt ausgeführt.
Dieser einfache Rechtebaum würde in k-infinity folgender Maßen aussehen:
Prüfung einer Operation anhand des Rechtebaum Beispiels:
Die linke Seite zeigt die zu prüfende Operation: Der Nutzer Paul möchte das Attribut Beschreibung löschen. Auf der rechten Seite ist der Rechtebaum abgebildet. Die Prüfung der Bedingung des ersten Filters fällt positiv aus, da Paul die Operation Löschen durchführen möchte. Im Rechtebaum wird der nächste Filter des Rechteteilbaumes ausgeführt. Dies ist der Eigenschaftsfilter der Attribute Name, Dauer und Erscheinungsdatum. Die Prüfung des Filters fällt negativ aus, da die Beschreibung keine der gefilterten Eigenschaften ist. Die Abarbeitung des Teilbaumes wird angebrochen. Es wird zum nächsten Teilbaum des Rechtebaumes gewechselt. Dies ist bereits der Default-Entscheider Erlaubt, der alles erlaubt, was nicht im Rechtebaum explizit verboten ist.
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 | Zugriffsrecht | Beschreibung |
Zugriff gewähren | Der Zugriff wird in der zu prüfenden Zugriffssituation erlaubt. | |
Zugriff verweigern | Der 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
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:
Symbol | Funktion | Beschreibung |
Neuer Operationsfilter | Ein neuer Operationsfilter wird erstellt. | |
Neuer Suchfilter | Ein neuer Suchfilter wird erstellt. | |
Neuer Eigenschaftsfilter | Ein neuer Eigenschaftsfilter wird erstellt. | |
Neuer Strukturordner | Ein neuer Strukturordner wird erstellt. | |
Zugriff gewähren | Ein positiver Entscheider, der den Zugriff erlaubt, wird erstellt. | |
Zugriff verweigern | Ein 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:
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.
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.
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.
Was wird gebraucht um dieses Recht in k-infinity zu definieren? Zum einen wird ein Operationsfilter benötigt, da es um das Ändern und Löschen von Elementen geht. Zum anderen muss der Zusammenhang zwischen dem Benutzer und dem Element, an dem er eine Operation ausführen möchte, formuliert werden - das geht nur mithilfe von Suchfiltern.
Operationsfilter
Im Operationsfilter wurden die Operationen Löschen und Modifizieren ausgewählt.
Suchfilter
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:
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)
Version 2 (rechts)
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.
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
Trigger sind automatische Operationen, die in k-infinity ausgeführt werden, wenn ein bestimmtes Ereignis eintritt. Sie helfen dabei Arbeitsabläufe zu unterstützen, in dem immer gleich bleibende Arbeitsschritte automatisiert werden.
Beispiele für den Einsatz von Trigger sind:
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.
Um mit Triggern arbeiten zu können, muss die Trigger-Funktionalität zunächst im Knowledge-Builder aktiviert werden.
Anleitung zur Aktivierung von Triggern
Hier kann ein Limit für rekursive Trigger angeben werden. Die Standardeinstellung ist "Keine". Als rekursive Trigger werden Trigger bezeichnet, die sich selber aufrufen. Dies passiert, wenn im Trigger-Skript selbst Operationen im sem. Netz durchgeführt werden, die wiederum selbst auf die Filterdefinition des Triggers passen.
Vor der Aktivierung des Trigger-Funktionalität heißt der Trigger Ordner im Technikbereich von k-infinity Trigger (deaktiviert). Durch die Aktivierung wird der Ordner in Trigger umbenannt.
Anmerkung: Wenn in Triggern der aktuelle Nutzer verwendet wird (z.B. in Suchfiltern oder über die entsprechende Skriptfunktion) und der Nutzer nicht in einer Anwendung Operationen ausführt sondern im Knowledge-Builder selbst, ist die Verknüpfung des Knowldge-Builder-Benutzer-Accounts mit einem Personenobjekt notwendig. Wie eine solche Verknüpfung erstellt wird, wird im Kapitel Aktivierung des Rechtesystems erklärt.
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:
Symbol | Funktion | Beschreibung |
Keine weiteren Trigger auslösen | Die Traversierung des Triggerbaumes wird beendet. |
Am Ende eines Teilbaumes steht im Gegensatz zum Rechtesystem kein Entscheider sondern Aktionen zur Verfügung.
Symbol | Funktion | Beschreibung |
Trigger definieren | Es wird eine neue Trigger-Aktion erstellt. |
Die verfügbaren Trigger-Aktionen sind:
Gestaltung des Triggerbaumes
Bei der Gestaltung des Triggerbaumes hat die Reihenfolge, in der man die Trigger definiert i.d.R. keinen Einfluss auf die Performance von k-infinity. Beim Rechtebaum gibt es Empfehlung zur Gestaltung, die aber nicht auf den Triggerbaum übertragbar sind, da nach Ausführung einer Trigger-Aktion der Triggerbaum weiter traversiert wird.
Für die übersichtlichere Gestaltung der Trigger können diese in Strukturordnern gesammelt werden. Die Strukturordner selbst haben keinen Einfluss auf die Traversierung des Triggerbaumes.
Symbol |
Funktion |
Beschreibung |
Strukturordner | Strukturordner für die Gruppierung von Teilbäumen |
Beispiel: Triggerbaum
Dieses Beispiel zeigt einen Triggerbaum, der die Namen von Personen und Konzerten automatisch aus Eigenschaften der Objekte zusammensetzt:
Dieser einfach Triggerbaum beginnt mit einem Operationsfilter und teilt sich nach den Operationsfilter in zwei getrennte Teilbäume. Wird einer der beiden Operationen Modifizieren oder Erzeugen ausgeführt, wird diese vom Operationsfilter durchgelassen. Der Teilbaum Person filtert Operationen, die an Attributen, Relationen von Objekten des Typs Person durchgeführt werden. Ist von der Operation entweder das Attribut Vorname oder das Attribut Nachname betroffen, wird diese vom Eigenschaftsfilter durchgelassen. Das dazugehörige Skript, welches das Namensattribut einer Person aus Vor- und Nachname zusammensetzt wird ausgeführt. Der zweite Teilbaum bezieht sich ebenfalls auf den Operationsfilter Modifizieren oder Erstellen aber filtert dann Attribute und Relationen, die an Objekte des Typs Konzert gespeichert sind. Der Eigenschaftsfilter lässt nur Operationen durch, welche an den Attributen Datum, die Relationen zum Veranstaltungsort oder dem Künstler durchgeführt werden. Treffen diese Bedingungen zu, wird das dazugehörige Skript ausgeführt, welches den Name des Konzertes zusammensetzt.
So würde dieser Trigger Baum in k-infinity aussehen:
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:
Symbol | Funktion | Beschreibung |
Neuer Operationsfilter | Ein neuer Operationsfilter wird erstellt. | |
Neuer Suchfilter | Ein neuer Suchfilter wird erstellt. | |
Neuer Eigenschaftsfilter | Ein neuer Eigenschaftsfilter wird erstellt. | |
Neuer Löschfilter | Ein neuer Löschfilter wird erstellt. | |
Neuer Strukturordner | Ein neuer Strukturordner wird erstellt. | |
Neuer Trigger | Eine neue Trigger-Aktion wird erstellt. | |
Keine weiteren Trigger auslösen | Ein 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:
Trigger-Aktionen dienen dazu intelligente Operationen in der semantischen Graph-Datenbank durchzuführen, die beispielsweise Arbeitsabläufe automatisieren oder unterstützen. Sie werden nur in bestimmten Situationen ausgeführt, nämlich dann wenn die Zugriffsituation und die Verknüpfungen im semantischen Netz einen bestimmten Zustand annehmen, der durch Filter definiert wird.
Anleitung zum Anlegen von Trigger-Aktionen
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
Beachte: Trigger, die bei Löschoperationen ausgelöst werden, sollten vorzugsweise als Zeitpunkt Vor der Änderung verwenden, da ansonsten das zu löschende Element nicht mehr zur Verfügung steht. Für andere Operationen bietet sich als Zeitpunkt eher Nach der Änderung oder Ende der Transaktion an, da dann beispielsweise eine Eigenschaft zu dem neu erstellten Element hinzugefügt werden kann oder automatisch der Name aus verschiedenen Eigenschaften eines Objektes generiert werden kann, wenn eine oder mehrere Eigenschaften geändert wurden.
Werden z.B. mehrere Datensätze in einem Import in k-infinity importiert, die eine Trigger-Aktion auslösen, die auf Basis von importierten Relationen, Aktionen im sem. Netz durchführen, kann es sinnvoll sein den Import in einer Transaktion durchzuführen und entsprechend Ende der Transaktion als Zeitpunkt der Ausführung auszuwählen, da sonst noch nicht alle Relationen die das Script benötigt importiert wurden.
Je Operationsparameter nur ein mal ausführen
Ist diese Einstellung ausgewählt, dann wird das in Operationsparameter ausgewählte Element maximal ein mal pro Transaktion ausgeführt. Wenn diese Einstellung gesetzt ist, sollte der Ausführungszeitpunkt auf Ende der Transaktion gesetzt werden, damit im Skript der endgültige Zustand des Elements verwendet wird.
Beispiel: Bei Personen soll der Name des Objekts aus Vorname und Nachname zusammengesetzt werden. Mit dieser Einstellung wird bei gleichzeitiger Änderung von Vor- und Nachname der Trigger nur ein mal ausgeführt.
Ausführung löst keine Trigger aus
Mit dieser Einstellung wird festgelegt, dass durch die Operationen, die innerhalb eines Triggers ausgeführt werden, keine weiteren Trigger ausgelöst werden können. Mit dieser Einstellung lassen sich Endlosschleifen vermeiden.
Bei Skriptfehlern Skript weiter ausführen
Ist diese Einstellung aktiv, so wird versucht nach Ausführungsfehlern wieder aufzusetzen und die Ausführung des Skriptes fortzuführen. Diese Einstellung eignet sich vorwiegend für Skripte, die voneinander unabhängige Anweisungen ausführen sollen, nicht für solche, die auf vorherige Schritte des Skriptes aufbauen.
Transaktion abbrechen, wenn Trigger fehlschlägt
Diese Einstellung legt das Abbruchverhalten bei Skriptfehlern fest. Tritt bei der Ausführung des Skriptes ein Fehler auf und diese Einstellung ist aktiv, werden alle Aktionen der Transaktion rückgängig gemacht. Ist diese Einstellung nicht aktiv, werden alle Aktionen durchgeführt außer diese, die von der Fehlerstelle betroffen sind. Die ursprüngliche Aktion, die zum Aufruf des Triggers geführt hat, wird trotzdem durchgeschrieben.
Ausführen während eines Daten-Refactorings
Unter Daten-Refactoring werden Operationen zur Umstrukturierung des semantischen Netzes verstanden wie z.B. Typ wechseln oder Relationsziel neu wählen. Daten-Refactoring-Operationen können unter Umständen ungewollte Trigger-Aktionen auslösen und in bestimmten Fällen auch Fehler bei der Durchführung des Skriptes erzeugen. Aus diesem Grund kann pro Trigger eingestellt werden, ob er bei Daten-Refactorings ausgeführt werden soll.
Der Funktionsrumpf für JavaScript-Triggerfunktion wird automatisch angelegt. Ein JavaScript Trigger braucht zwangsläufig den Funktionsrumpf der Triggerfunktion. (Er darf z.B. nicht auskommentiert werden.)
/** * Perform the trigger * @param parameter The chosen parameter, usually a semantic element * @param {object} acccess Object that contains all parameters of the access * @param {$k.User} user User that triggered the access **/ function trigger(parameter, access, user) { }
Das Parameter "access" kann (je Operation variierend) folgende Eigenschaften enthalten:
Eigenschaft | Beschreibung |
accessedObject | Zugriffselement |
core | Kernobjekt |
detail | Detail |
inversePrimaryCoreTopic | Primäres Relationsziel |
inverseRelation | Inverse Relation |
inverseTopic | Relationsziel |
operationSymbol | "read", "deleteRelation", etc. |
primaryCoreTopic | Primäres Kernobjekt |
primaryProperty | Primäreigenschaft |
primaryTopic | Primärelement |
property | Eigenschaft |
topic | Übergeordnetes Element |
user | Benutzer (identisch zu "user"-Parameter der Funktion) |
Möchte man die Trigger-Funktionalität überwachen bzw. dokumentieren, wann welcher Trigger ausgelöst wurde und welche Operationen im sem. Netz ausgeführt wurden, eignen sich Log Trigger. Der Log wird in das jeweilige Log File (bridge.log, importtool.log etc.) geschrieben in dessen Anwendungsumgebung die Operation, welche den Trigger ausgelöst hat, durchgeführt wird.
Zeilen des Logeintrages | Zustand des sem. Netzes zum Zeitpunkt |
#pre | vor Auslösung |
#post | nach Auslösung |
#end | am Ende der Transaktion |
#commit | bei 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
Beispiel:
Logeintrag der das Ändern des Attributs e-mail durch einen Trigger dokumentiert.
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?
Symbol | Filter | Beschreibung |
Operationsfilter | Filtert die Operationen; Auswahl aus Liste | |
Suchfilter | Filtert Elemente durch Strukturabfrage | |
Eigenschaftsfilter | Filtert Relationen und Attribute; Auswahl aus Liste | |
Löschfilter | Filtert 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
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.
Mit Eigenschaftsfiltern können Attribute und Relationen gefiltert werden. Es gibt zwei verschiedene Vorgehensweisen einen Eigenschaftsfilter zu verwenden:
Ü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 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:
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
Beachte: Initial ist die Einstellung Alle Parameter müssen zutreffen ausgewählt. Werden beispielsweise die Operationsparameter Zugriffselement und Primärelement ausgewählt, ist die Bedingung nur dann erfüllt, wenn das Ergebnis der Strukturabfrage sowohl Zugriffselement als auch Primärelement der zu prüfenden Operation ist.
Beispiel 1: Suchfilter im Rechtesystem
Es soll ein Recht definiert werden, das besagt, dass bereits veröffentlichte Songs von allen gesehen werden dürfen unveröffentlichte Songs hingegen nicht.
In diesem Beispiel möchte die Benutzer Paul den Song X lesen. Diese Operation wird nun vom Rechtesystem geprüft. Dort ist ein Suchfilter definiert, der prüft, ob der Song bereits veröffentlicht ist. In der Strukturabfrage des Suchfilters werden Objekte vom Typ Song gesucht, mit der Einschränkung, dass das Attribut Erscheinungsdatum in der Vergangenheit liegt. Die Strukturabfrage liefert alle Songs, die diese Bedingung erfüllen. Ist der Song X einer davon, fällt die Prüfung des Filters positiv aus und der auf den Suchfilter nachfolgende Ordner (mit einem Filter oder Entscheider) wird ausgeführt.
Bei dem Suchfilter wurden die Einstellungen Suchbedingung muss erfüllt sein und Alle Parameter müssen zutreffen ausgewählt.
Beispiel 2: Suchfilter im Rechtesystem
In den meisten Fällen gibt es eine Verbindung zwischen dem Benutzer, der zugreifen will und den Objekten oder Eigenschaften, auf die er zugreifen will. Ein Beispiel dafür wäre: "Mitarbeiter einer Abteilung die eine Branche betreuen, dürfen alle Kunden aus dieser Branche bearbeiten." Eine andere Version dieses Beispiels, das unten dargestellt wird, wäre: "Nutzer, die einen Künstler pflegen, dürfen diesen bearbeiten und löschen."
Auf der linken Seite ist ein Ausschnitt des Wissensnetzes abgebildet: Das Objekt Paul ist mit den Objekten Künstler A, Künstler B und Künstler C über die Relation pflegt verknüpft. Die inverse Relation von pflegt ist wird gepflegt von, die zwischen den Objekten Künstler A, Künstler B, Künstler C und dem Objekt Paul besteht und im Suchfilter abgefragt wird. Diese Relation im semantischen Netz steht dafür, dass eine Person für die Datenpflege rund um einen Künstler verantwortlich ist.
In diesem Beispiel möchte der Benutzer Paul das Objekt Künstler A löschen. Der dazugehörige Suchfilter liefert als Suchergebnis alle Künstler die von einem bestimmten Benutzer gepflegt werden. Der aktuelle Benutzer wird als Zugriffsparameter in die Strukturabfrage übergeben. Zugriffsparameter in Strukturabfragen werden im Kapitel Strukturabfragen erklärt. Somit liefert die Suche in dieser Zugriffsituation alle Künstler, die von Paul gepflegt werden. Da Künstler A einer davon ist, fällt die Prüfung des Suchfilters positiv aus.
Von der Zugriffssituation werden in diesem Beispiel zwei Aspekte in den Suchfilter eingebracht. Das ist der Künstler der gelöscht werden soll und der Benutzer. Der Suchfilter kann entsprechend auf zwei verschiedene Arten definiert werden. Entweder wird der Künstler als Zugriffselement an den Suchfilter übergeben und der Benutzer als Zugriffsparameter in der Strukturabfrage verwendet. Oder der Benutzer wird als Operationsparameter Benutzer an den Suchfilter übergeben und die Firma als Zugriffsparameter Zugriffselement in der Strukturabfrage verwendet.
Löschfilter stehen nur bei der Definition von Triggern zur Verfügung. Sie werden dazu eingesetzt, in einer Löschsituation zu testen, ob das übergeordnete Element auch von dem Löschvorgang betroffen ist. Will man beispielsweise, dass ein Trigger nicht ausgeführt wird, wenn ein Objekt samt all dessen Eigenschaften gelöscht wird, aber dann wenn eine bestimmte Eigenschaft des Objektes gelöscht wird, muss ein Löschfilter verwendet werden.
Bei der Definition eines Löschfilters, muss mindestens ein Operationsparameter angegeben werden, der bestimmt, die Löschung welches Objektes getestet werden soll.
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.
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).
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 |
(Ober)typ |
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. |
Kernobjekt |
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. |
Primäreigenschaft |
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. |
Primärelement |
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. |
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.
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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) |
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 |
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 |
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) |
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 |
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 |
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.
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.
Operationsgruppe | 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 | |
Modifizieren | Arttributwert modifizieren | Zugriffselement, Eigenschaft, übergeordnetes Element |
Ordner modifizieren | Ordner | |
Schema modifizieren | Zugriffselement, übergeordnetes Element | |
Typ wechseln | Zugriffselement, übergeordnetes Element | |
Werkzeuge verwenden | Export | |
Import | ||
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.
In Strukturabfrage verwenden
Ist ein negatives Zugriffsrecht für ein Element definiert, das auf die Operation In Strukturabfrage verwenden gefiltert wird, dann darf das Element nicht in einer Strukturabfrage verwendet werden. Es wird auch dann nicht in Strukturabfragen berücksichtigt, wenn der (abstrakte) Obertyp angegeben wird.
Attributwert validieren
Die Operation Attributwert validieren wird dann verwendet, wenn der zu setzende Attributwert bestimmte Bedingungen erfüllen muss. Die Definition der Bedingung an den Attributwert wird in einer Strukturabfrage gemacht. Dort stehen für die Validierung des Attributwertes zwei Definitionsmöglichkeiten zur Verfügung:
Für die Validierung stehen verschiedene Vergleichsoperatoren zur Verfügung, mit denen der zu setzende Attributwert gegen einen anderen Wert geprüft werden kann.
Entspricht der neue Wert nicht der definierten Bedingung, so ergibt die Prüfung des Filters ein negatives Ergebnis, sofern die initiale Einstellung Suchbedingung muss erfüllt sein ausgewählt ist.
Schema modifizieren
Die Operation Schema modifizieren, betrifft Änderungen am Definitionsbereich von Relationen und Änderungen an der Typenhierarchie (ist Untertyp von und ist Obertyp von Relationen).
In diesem Beispiel wird gezeigt wie Operationsgruppen (Lesen, Erzeugen, Modifizieren, Löschen) bei der Rechtedefinition sinnvoll eingesetzt werden können. Es sollen alle Operationen für den Typ Song und dessen Objekte verboten werden. Dies umfasst die folgenden Aktionen:
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.
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:
Zum Testen des Rechtesystems und der Trigger-Funktionalität sind zwei Bereiche relevant:
Anleitung zum Öffnen der Testumgebung
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.
Beachte: Bei der Prüfung von Relationen werden i.d.R. die Relation, die inverse Relation und beide Relationshälften einzeln getestet.
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
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.
Die View-Konfiguration ermöglicht es verschiedene Sichten auf die Daten von k-infinity zu konfigurieren. Die konfigurierten Sichten kommen in Anwendungen zum Einsatz. Es können beispielsweise Teilausschnitte des semantischen Modells gezeigt oder bestimmte Zusammenstellungen der Daten (z.B. in Formularen, Tabellen, Ergebnislisten u.v.m.) erstellt werden.
So können wir u.a. folgende Fragen entscheiden und die entsprechend gewünschten Ansichten mit View-Konfigurationen erstellen:
Wie sollen die Eigenschaften von bestimmten Objekten dargestellt werden? In welcher Reihenfolge sollen die Eigenschaften dargestellt werden? Wenn wir ein neues Objekt anlegen, welche Attribute und Relationen sollen dann so dargestellt werden, damit sie auf keinen Fall übersehen und nicht ausgefüllt werden? Wie soll die Liste von Objekten zu einem Typ aussehen? Soll es überhaupt eine einfache Liste sein oder sollen die Objekte in Tabellen dargestellt werden? Welche Elemente sollen dann in den einzelnen Spalten zu sehen sein? Sollen Relationsziele direkt dargestellt werden? Oder nur bestimmte Attribute? Sollen wir verschiedene Reiter definieren, die zusammengehörige Eigenschaften und Attribute zusammenfassen? ...
Ein Beispiel: Konkrete Personen haben die Eigenschaften Name, Alter, Geschlecht, Adresse, Festnetznummer, E-Mail, Mobilnummer, Fax, kennt, ist befreundet mit und ist Kollege von. Nun könnten wir mithilfe der View-Konfiguration mehr Struktur in die Ansicht der Daten bringen, indem wir einen Reiter mit der Überschrift „Allgemeines“ definieren, der Name, Alter und Geschlecht zusammenfasst, einen mit der Überschrift „Kontaktdaten“, der Adresse, Festnetznummer, E-Mail, Mobilnummer und Fax beinhaltet und einen Reiter mit der Überschrift „Kontakte“, der die Eigenschaften kennt, ist befreundet mit und ist Kollege von enthält.
Beispiel einer View-Konfiguration. Oberer Screenshot: Unkonfigurierter Ausschnitt eines Objektes in der Graph-Ansicht mit allen seinen Eigenschaften. Unterer Screenshot: Konfigurierte Ansicht desselben Objektes, in der zusammengehörige Eigenschaften gruppiert, unwichtige Relationen weggelassen und Ähnlichkeitsbeziehungen direkt dargestellt sind.
Ein Spezialfall der View-Konfiguration ist die Konfiguration der Ansicht der Daten im Knowledge-Builder, denn auch der Knowledge-Builder ist eine Anwendung, in der verschiedene Sichten auf die Daten möglich sind. Hilfreich ist dies dann, wenn wir den Knowledge-Builder als Preview benutzen wollen, um bestimmte Konfigurationen auszuprobieren. Die View-Konfiguration im Knowledge-Builder eignet sich außerdem, wenn Daten systematisch erfasst werden sollen, denn dann kann man beispielsweise die Detailseiten von Objekten so konfigurieren, dass wichtige zu ergänzende Eigenschaften gut sichtbar abgefragt werden.
Anhand eines Beispiels aus einer Datenbank zu Reisezielen und Sehenswürdigkeiten wird hier gezeigt, wie eine View-Konfiguration Schritt für Schritt erstellt wird. Die Detailseite zu Sehenswürdigkeiten in einer Web-Anwendung zur Reise-Datenbank soll konfiguriert werden. Die unkonfigurierte Standard-Ansicht einer Sehenswürdigkeit (links), listet alle ihre Attribute und Relationen untereinander auf, was in diesem Fall weder sinnvoll noch attraktiv für Anwender ist:
Die konfigurierte Ansicht (rechts) zeigt hingegen nur relevante und nützliche Informationen zur Sehenswürdigkeit, stellt diese übersichtlich, geblockt und mit passenden Überschriften dar und beinhaltet zudem eine Relation, die eine indirekte Beziehung darstellt: dass das Ägyptische Museum in Kairo steht, bedeutet es befindet sich im Land Ägypten. Darüber hinaus wurden der Graph-Button zur Ansicht des Objektes in einer Graph-Ansicht und mehrere Reiter hinzugefügt ("Details", "Ähnliche Sehenswürdigkeiten" und "Suche"), mit denen die Anwender definierte Aktionen durchführen können. Im Folgenden wird erläutert, wie diese Konfigurationen im Einzelnen erstellt werden.
Wir wollen die Detail-Ansicht von Objekten des Typs "Sehenswürdigkeit" konfigurieren. Darum bewegen wir uns im Knowledge-Builder zum Typ "Sehenswürdigkeit", wählen dort den Reiter "Details" aus und klicken in der angezeigten Hierarchie dann unter "View-Konfiguration" -> "Objekt" auf "Details":
Unter "View-Konfiguration" stehen neben "Details" (von Objekten) noch andere Auswahlmöglichkeiten bereit:
Mit einem Klick auf "Neu" können wir hier eine neue View-Konfiguration anlegen. Für eine View-Konfiguration der Art Details bei Objekten stehen in einem sich anschließend öffnenden Dialog sechs Typen der View-Konfiguration bereit, von denen man einen auswählen muss:
Wir benötigen den Typ "Gruppe", da wir verschiedenste Unterkonfigurationen in einer Ansicht zusammenfassen wollen. (Die anderen Typen sind im Kapitel Detailkonfiguration für Objekte oder Typen erklärt.)
Nachdem wir den Typ der Konfiguration ausgewählt haben sehen wir unsere neu angelegte View-Konfiguration im rechten Fenster. Für den Namen der View-Konfiguration wurde automatisch der Name des Typs übernommen, der in Spalte vier noch einmal zu sehen ist. Die zweite Spalte zeigt den Typ der View-Konfiguration. In der dritten Spalte "Kontext" wird angezeigt, in welcher Anwendung die View-Konfiguration zum Einsatz kommt. Da wir noch keine Anwendung definiert haben, ist die Spalte noch leer.
Mit einem Klick auf den Bearbeiten-Button oder einem Doppelklick auf die ausgewählte View-Konfiguration öffnen wir den Editor, mit dem wir die Ansicht konfigurieren können.
Bevor wir eine Ansicht konfigurieren, gehen wir auf den Reiter "Verwendung" um dort die Anwendung festzulegen, in der die View-Konfiguration gültig ist. Die Anwendung legt man unter anwenden in fest:
In diesem Beispiel wählen wir die Anwendung Viewkonfiguration-Mapper in dem Feld anwenden auf aus. Unter anwenden auf wird der Objekttyp angegeben, der in unserem Fall bereits übernommen ist.
Die View-Konfiguration hat eine Baumstruktur. Unser Wurzelelement ist die von uns zu Anfang angelegte Gruppe. Darum genügt es, wenn wir nur hier Angaben zur Verwendung machen, da das Prinzip der Vererbung auch in der View-Konfiguration greift und das Wurzelelement die Verwendung an seine Unterelemente vererbt.
Um dem der erstellten Wurzelkonfiguration vom Typ Gruppe nun weitere Konfigurationselemente hinzuzufügen klicken wir "Objektkonfiguration neu anlegen" . Es öffnet sich ein Dialog, der alle möglichen Arten der View-Konfiguration anzeigt. (Die einzelnen Typen sind im Kapitel Detailkonfiguration für Objekte oder Typen erklärt.)
Da wir eine Darstellung mit Reitern erstellen wollen, müssen wir das Konfigurationselemente "Alternative" anlegen.
Die einzelnen Reiter müssen nun unter der "Alternative" angelegt werden.
Der erste Reiter soll die Details der Sehenswürdigkeit zum Inhalt haben, also die wichtigen direkten Attribute und Relationen (Beschreibungstext, Bild, Themen, etc.). Hierfür könnten wir demnach das Konfigurationselement "Eigenschaften" wählen, mit dem man einzelne Eigenschaften eines Objekttyps anzeigen lassen kann. Da wir allerdings noch Überschriften definieren und eine einzelne indirekte Relation abbilden wollen, benötigen wir stattdessen ein weiteres Konfigurationselement des Typs "Gruppe".
Der zweite Reiter soll ähnliche Sehenswürdigkeiten anzeigen, die mithilfe einer Ähnlichkeitssuche berechnet werden und der dritte Reiter soll die Suchfunktion der Web-Anwendung zugänglich machen. Für beide Reiter müssen wir demnach jeweils ein Konfigurationselement des Typs "Suche" wählen.
Wir müssen uns zu jedem Reiter eine passende Beschriftung überlegen, denn ohne Beschriftung kann der Reiter in der Anwendung nicht angezeigt werden. Diese können wir unter "Konfiguration" bei Beschriftung eintragen.
Wenn wir die View-Konfiguration nun über den Button "View-Konfigurationen aktualisieren" aktualisieren, können wir das Ergebnis in unserer Web-Anwendung betrachten:
Wir sehen, dass die Beschriftung nicht nur als Beschriftung der Reiter dient, sondern auch als Überschrift bei einem ausgeklappten Reiter. Wenn wir dieses im Prinzip doppelte Vorkommen der Überschrift nicht wollen, können wir jedem Reiter eine Style-Eigenschaft geben, die die Überschrift versteckt. Dazu müssen wir bei dem jeweligen Konfigurationselement unter "Aktionen und Styles" mithilfe des Knopfes "Style hinzufügen" das Style-Element "hideLabel" auswählen.
Das Ergebnis: unsere drei Reiter sind fertig konfiguriert. Mit dem Style-Element hideLabel können wir Beschriftungen verstecken.
Nun wollen wir festlegen, welche Attribute und Relationen der Objekte des Typs Sehenswürdigkeit in dem Reiter "Details" zu sehen sein sollen. Den Reiter "Details", haben wir in unserem Konfigurationsbaum bereits als Gruppe definiert. Das Unterelement, das wir nun benötigen ist "Eigenschaften". Dieses Element dient dazu die verschiedenen Eigenschaften eines Objektes in einer Liste untereinander darzustellen. Mit einem weiteren Klick auf den Button "Eigenschaft neu anlegen" , fügen wir der Eigenschaftsliste nun eine Eigenschaft hinzu. Damit haben wir in unserem Baum ein Blatt erreicht, d.h. wir sind an einem Punkt angelangt, bei dem wir schließlich eine Eigenschaft festlegen, die in einer Anwendung dargestellt werden soll. Wir können hier keine weiteren Unterelemente mehr anlegen.
Unter Eigenschaft müssen wir festlegen, welche Eigenschaft angezeigt werden soll. Eine Eigenschaft kann ein Attribut, eine Relation oder eine Abkürzungsrelation sein. Alle Einstellungsmöglichkeiten werden in Kapitel Eigenschaft erläutert.
So definieren wir alle Eigenschaften der Sehenswürdigkeit, die wir für die Anwendung als sinnvoll erachten. Die Reihenfolge, wie wir sie im View-Konfigurationsbaum sehen ist dieselbe, wie wir sie nach der Aktualisierung über den Button "View-Konfigurationen aktualisieren" sehen:
Um sie Ansicht noch etwas schöner zu gestalten, können wir verschiedene Style-Elemente verwenden:
Mithilfe weiterer Eigenschaftslisten stellen wir nun noch die Themen der Sehenswürdigkeiten, sowie die Schöpfer und den Ort dar.
Wenn wir wissen, in welcher Stadt sich eine Sehenswürdigkeit befindet, wissen wir auch in welchem Land sie sich befindet, auch wenn das Land nicht direkt mit der Sehenswürdigkeit verbunden ist. Diese indirekte Beziehung zwischen Sehenswürdigkeit und Land können wie auch mit der View-Konfiguration darstellen. Dazu brauchen wir ein Konfigurationselement des Typs "Suche", denn hier können wir eine beliebige Abfrage, also auch die hierfür benötigte Strukturabfrage, definieren:
Die Strukturabfrage muss so aufgebaut sein, dass das gewollte Ergebnis, bzw. die gewollten Ergebnisse, Ausgangspunkt der Strukturabfrage sind. Das Objekt Sehenswürdigkeit wird mit einem Parameter versehen.
Der Parameter des Objekts muss ebenfalls in der View-Konfiguration angegeben werden. Ob der Wert über ein Skript oder über eine Benutzereingabe ermittelt werden soll, muss unter Wertermittlung angegeben werden. Ein Skript, das das Element des Parameters zurückgibt, wird ebenfalls benötigt. Als Typ muss angegeben werden, dass es sich um ein Element des semantischen Modells handelt (k:element). Ausführlichere Erklärung zu diesen und den weiteren Einstellungsmöglichkeiten sind im Kapitel Suche nachzuschlagen.
Unter Tabelle wird definiert, wie (d.h. mit welchen Eigenschaften) das Ergebnis, bzw. die Ergebnisse der Suche dargestellt werden sollen. Hier können ebenfalls Style-Elemente angegeben werden. Wir verwenden das Style-Element MediaList, welches die Ergebnisse mit Namen und dem Icon ihres Objekttyps darstellt. Alle Details zur Konfiguration einer Ergebnistabelle sind im Kapitel Tabelle nachzuschlagen.
Das Style-Element MediaList ermöglicht eine alternative Darstellung von Ergebnissen einer Abfrage
Prinzipiell funktioniert die Einstellung der Konfiguration von ähnlichen Sehenswürdigkeiten genau wie die Konfiguration der indirekten Eigenschaft "Land", mit dem einzigen Unterschied, dass hier eine Such-Pipeline anstelle einer Strukturabfrage verwendet wird, um beispielsweise die fünf ähnlichsten Sehenswürdigkeiten auf Grundlage von Themen, Schöpfer und Ort zu berechnen.
Der letzte Reiter unserer Anwendung soll eine Suche beinhalten.
Den Reiter "Suche" haben wir in unserem Konfigurationsbaum bereits als Konfigurationselement vom Typ "Suche" definiert. Hier legen wir in einer Strukturabfrage fest, dass die Namen aller konkreten Objekte der Datenbank mögliche Ergebnisse sein können. Der Wert des Namens wird über den Parameter q definiert. Der Parameter q soll nicht zwischen Groß- und Kleinschreibung einer Benutzereingabe unterscheiden und wenn der Benutzer ein Wort eines zusammengesetzten Begriffes eingibt (z.B. "Museum"), so sollen alle Objekte, bei denen dieses Wort im Namen vorkommt, in der Ergebnisliste erscheinen (z.B. "Ägyptisches Museum"). Dies wird durch den Operator Enthält Zeichenkette (strings to words filter (Beschreibungstexte bereinigen)) in der Strukturabfrage festgelegt.
Im Editor der View-Konfiguration des Reiters "Suche" muss der Parameter q noch unter Parametername angegeben werden. Hier muss zudem definiert werden, dass sich der Wert des Parameters über die Benutzereingabe ermittelt und dass die Benutzereingabe eine beliebige Zeichenkette sein kann (Typ xsd:string).
Wie die Ergebnisliste dargestellt werden soll, wird wieder über das Element Tabelle konfiguriert. In unserem Fall wird hier eine Tabelle angelegt, die lediglich die Namen der Ergebnisse zeigt und das Style-Element MediaList verwendet.
Auf dem Reiter Verwendung einer View-Konfiguration muss angegeben werden, in welcher Anwendung und für welchen Objekttyp die View-Konfiguration angezeigt werden soll.
Im Feld anwenden in auf dem Reiter Verwendungen wird die Anwendung eingetragen.
Ist keine Anwendung als Verwendung der View-Konfiguration eingetragen, so wird die View-Konfiguration nicht angezeigt. View-Konfigurationen werden als Baumstruktur definiert, in der das Prinzip der Vererbung gilt. Aus diesem Grund muss die Anwendung bei Unterkonfigurationen nicht extra angegeben werden. Sie werden als Teil der Oberkonfiguration mit angezeigt. Zum Beispiel wird eine Eigenschaftskonfiguration angezeigt, wenn diese Teil einer Gruppe ist, deren Verwendung angegeben wurde.
Anwendungen der View-Konfiguration festlegen
Die folgenden Anwendungen stehen von Anfang an zur Verfügung:
Darüber hinaus können auch eigene beliebige Anwendungen definiert werden, die an dieser Stelle mit der View-Konfiguration verknüpft werden können.
Objekttyp der View-Konfiguration festlegen
Im Feld anwenden auf wird der Objekttyp automatisch eingetragen, wenn die View-Konfiguration am Objekttyp definiert wird. Hier können nach Bedarf weitere Objekttypen angegeben werden. Je nach dem wo man die View-Konfiguration angelegt hat, entweder unter Objekt oder unter Typ, wird die View für Objekte des ausgewählten Typs oder den Typ einschließlich seiner Untertypen angezeigt. Durch das Setzen oder Wegnehmen des Häkchens des Attributs anwenden auf Untertypen kann diese Auswahl (gültig für Objekte oder Typen) auch nach der Definition der View-Konfiguration geändert werden.
Wiederverwendung von View-Konfigurationen
View-Konfigurationen können in anderen View-Konfigurationen wieder verwendet werden. So kann man beispielsweise eine Tabelle konfigurieren, die für die Anzeige von mehreren View-Konfigurationen vom Typ Suche eingesetzt wird. Falls die View-Konfiguration Baustein einer anderen View-Konfiguration ist, wird dies unter [inverse] anwenden in angezeigt.
Im Kapitel Die Verwendung von View-Konfigurationen wurde bereits beschrieben, dass die Angabe über die Verwendung von View-Konfigurationen ausschlaggebend ist ob, in welcher Anwendung und für welche Objekte bzw. Typen die View angezeigt wird. Trotzdem ist es möglich, dass die View-Konfiguration nicht in der ausgewählten Anwendung angezeigt wird. Hier stellt sich die Frage: Wann ist eine View-Konfiguration gültig? Und für welche Objekt bzw. Typen ist die View-Konfiguration gültig?
Vererbung von View-Konfigurationen
View-Konfigurationen verhalten sich in Bezug auf die Vererbung wie Eigenschaften. View-Konfigurationen werden auf die Untertypen bzw. die Objekte der Untertypen vererbt.
Anwendung der konkretesten View-Konfiguration
Die Untertypen verwenden nach dem Prinzip der Vererbung die View-Konfiguration der Obertypen solange sie keine eigenen View-Konfigurationen besitzen. Es wird immer die konkreteste View-Konfiguration angewendet: Das ist die Konfiguration, die direkt am Typ definiert ist. Ist das nicht der Fall, so wird geprüft ob es am Obertyp eine View-Konfiguration gibt. Ist das ebenfalls nicht der Fall so wird in der Typenhierarchie jeweils eine Ebene nach oben gegangen und geprüft ob eine View-Konfiguration definiert ist. Es wird dann diejenige View-Konfiguration angewendet, die dem Objekttyp am nächsten steht. Wird keine View-Konfiguration an den Obertypen gefunden, wird für Administratoren die Default-Konfiguration verwendet.
Was passiert wenn zwei gleichwertige View-Konfigurationen existieren?
Gibt es zwei gleichwertige View-Konfigurationen, so wird keine View-Konfiguration angezeigt. Wurde bei einer View-Konfiguration die Anwendung oder der Objekttyp nicht definiert, zählt diese nicht zu den aktiven View-Konfigurationen. In diesem Fall wird die andere View-Konfiguration verwendet. Möchte man für unterschiedliche Benutzer jeweils andere Views anzeigen, kann im Detektorsystem eine Regel definiert werden. In diesem Fall wird dann die View-Konfiguration entsprechend der definierten Regel angewendet, solange die Regel abhängig von Nutzer nur eine gültige View-Konfiguration liefert.
Eine Detailkonfiguration beschreibt, wie Objekte oder Typen dargestellt werden sollen. Im folgenden werden die verschiedenen Detailkonfigurationsarten, die der View-Konfiguration zur Verfügung stehen, beschrieben.
Die einzelnen Detailkonfigurationen lassen sich teilweise beliebig zusammenstecken. Ebenfalls können die Konfigurationen mehrfach als Unterkonfiguration verwendet werden.
Liste der verschiedenen Detailkonfigurationstypen
Konfigurationstyp | Top-Level-Konfiguration | Kann folgende Unterkonfiguration enthalten |
Alternative | x | beliebig |
Eigenschaft | ||
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.
Eine Alternative verwenden wir, um beliebig viele verschiedene alternative Ansichten auf ein Objekt zu konfigurieren. Die alternativen Ansichten können in der Anwendung mittels Reitern ausgewählt werden. Zur Beschreibung, wie man eine Alternative anlegt, siehe Kapitel Reiter konfigurieren.
Einstellungsmöglichkeiten
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
Werden die Ansichten in JSON herausgeschrieben, werden die einzelnen Unteransichten in einem ARRAY an den KEY alternatives gehängt.
Beispiel einer Alternative in einer Anwendung: Mittels der Reiter kann zwischen den Ansichten "Details", "Ähnliche Sehenswürdigkeiten" und "Suche" gewechselt werden.
Darstellung im Knowledge-Builder
Im Knowledge-Builder werden dem Anwender die verschieden konfigurierten und mit der Alternative verknüpften Ansichten eines Objekts durch Reiter zur Verfügung gestellt.
Beispiel einer Alternative im Knowledge-Builder: Mittels der Reiter kann zwischen der Ansicht "Details" und der Ansicht "Wiki-Verweise" gewechselt werden.
Anmerkung
Diese Konfiguration ist ähnlich der Konfiguration Gruppe. Allerdings werden bei einer Gruppe alle Unteransichten gleichzeitig angezeigt.
Mit der View-Konfiguration Eigenschaft kann definiert werden, wenn beispielsweise eine abstrakte Eigenschaft benutzt wird, die eine Menge von Eigenschaften zusammenfasst, angezeigt werden soll.
Einstellungsmöglichkeiten
Name | Wert |
Absteigend sortieren | Steuert, ob die Eigenschaften auf- oder absteigend nach ihrem Namen sortiert werden. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert. |
Anzeigeart | 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. Auswahlmöglichkeiten:
|
Beschriftung | Anzeigename der Eigenschaft. Ist keine Beschriftung angegeben wird der Name des Eigenschaftstyps ausgegeben. |
Eigenschaft | Verknüpfung zu einem Eigenschaftstyp, der angezeigt werden soll. |
Skript für virtuelle Eigenschaften | Alternativ zu 'Eigenschaft': Skript zur Berechnung anzuzeigender Werte |
Einblendung des Relationsziels | Standardmäßig wird lediglich der Name des Relationsziels angezeigt. Wird der Name angeklickt, öffnet sich das Relationsziel in einem weiteren Editor. Wird hingegen die Option Einblendung des Relationsziels gewählt, werden die Relationsziele direkt angezeigt, d.h. nicht nur ihr Name, sondern alle ihre Eigenschaften. |
Einblendung zusätzlicher Eigenschaften | Nur bei der Ansicht zum Bearbeiten von Objekten relevant: Ist diese Option gesetzt, wird zu der Eigenschaft eine weitere Eigenschaft eingeblendet, sodass diese bequem und schnell ausgefüllt werden kann. Die Eigenschaft muss mehrfach vorkommen dürfen. |
Einblendung zusätzlicher neuer Eigenschaften | Nur bei der Ansicht zum Bearbeiten von Objekten relevant: Ist diese Option gesetzt, wird die Eigenschaft nur dann eingeblendet, wenn die Eigenschaft noch nicht angelegt wurde. So kann sie bequem und schnell ausgefüllt werden und wird nicht so leicht vergessen. |
Einblendungsfilter | Nur bei der Ansicht zum Bearbeiten von Objekten relevant: Mit dieser Option kann eine Verknüpfung zur einer Abfrage, die entscheidet, ob diese Konfiguration angezeigt wird, angelegt werden. Die Abfrage wird mit dem Objekt dieser Eigenschaft gefüllt. Nur, wenn die Abfrage ein Ergebnis enthält, wird die Eigenschaft zum bearbeiten angezeigt. |
Konfiguration für eingebettete Metaeigenschaften | Angabe der Konfiguration, die verwendet werden soll, um Metaeigenschaften anzuzeigen. Die Metaeigenschaften werden eingebettet, d.h. hinter dem Wert der Eigenschaft angezeigt. Der Name des Eigenschafttyps wird nicht angezeigt. |
Konfiguration für Metaeigenschaften | Angabe der Konfiguration, die verwendet werden soll, um Metaeigenschaften anzuzeigen. Die Metaeigenschaften werden unter dem Wert der Eigenschaft angezeigt. |
Relationszielansicht | Wird als Eigenschaft eine Relation gewählt, kann mit diesem Parameter die Ansicht der Relationsziele definiert werden:
|
Skript für Sortierung | Anhand des Skriptes wird ein Wert, nach dem sortiert wird, ermittelt. Siehe Beispiel unten. |
Suche zur Zielauswahl | Die Suche bestimmt, welche Wissensnetzelemente als mögliche Relationsziele angeboten werden. Zur Konfiguration der Suche, siehe auch Kapitel Suchen/Abfragen. |
Tabelle | Steht nur zur Verfügung, wenn Relationszielansicht den Wert Tabelle, bzw. Tabelle (Relationsziele) hat und ist dann obligatorisch. Die hier angegebene Tabellenkonfiguration gibt an, welche Eigenschaften der Relationsziele tabellarisch ausgegeben werden sollen. Um das Relationsziel anzuzeigen muss mindestens sein Name in der Tabelle konfiguriert werden. Zur Konfiguration einer Tabelle, siehe Kapitel Tabelle. |
Beispiel für Skript für Sortierung
Vorbedingung: An allen Eigenschaften kann das Attribut sortKey angebracht werden.
function sortKey(element) { if (element instanceof $k.Property) { var attribute = element.attribute('sortKey') if (attribute) { return attribute.value(); }; }; if (element instanceof $k.Domain) { var attribute = element.type().attribute('sortKey'); if (attribute) { return attribute.value(); }; }; return undefined; }
Eigenschaftsanzeige einer Person
Anmerkung: Beim Attributtyp Vorname ist für sortKey der Wert 20 eingetragen, daher steht dieser vorläufige Wert am Ende der Liste.
Die Konfiguration Eigenschaften ist im Prinzip eine Liste von einzelnen Eigenschaften. Die Unterkonfigurationen können ausschließlich vom Typ Eigenschaft sein.
Einstellungsmöglichkeiten
Name | Wert |
Beschriftung | Anzeigename der Sammlung von Eigenschaften. Ist keine Beschriftung angegeben wird im Knowledge-Builder die Zeichenkette 'Eigenschaften' verwendet. |
Initial ausgeklappt | Ist diese Konfiguration z.B. als Metakonfiguration eingehängt, kann mit diesem Parameter bestimmt werden, ob diese beim Öffnen des Knowledge-Builder-Editors bereits ausgeklappt sein soll. Achtung: Das Front-End stellt die betroffene Metaeigenschaft gar nicht dar, wenn der Haken hier nicht gesetzt ist. |
Einstellungsmöglichkeiten für die Sortierung
Name | Wert |
Absteigend sortieren | Steuert, ob auf- oder absteigend sortiert wird. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert. |
Primäres Sortierkriterium | Auswahlmöglichkeit für das Kriterium, nach dem die Eigenschaften sortiert werden:
|
Sekundäres Sortierkriterium | Sortierkriterium für Eigenschaften, die für das primäre Sortierkriterium den gleichen Wert haben. Einstellmöglichkeiten analog zum Primären Sortierkriterium |
Skript zur Sortierung | Verweis auf ein registriertes Skript, das den Sortierschlüssel für das primäre bzw. sekundäre Sortierkriterium zurückgibt. |
Darstellung in Anwendungen
Die Ansichten der Unterkonfiguration einzelner Eigenschaften werden in einem ARRAY abgelegt und mit dem KEY properties angehängt.
Darstellung im Knowledge-Builder
Die in der Konfiguration eingestellte Beschriftung wird prominent angezeigt. Ihm folgen die Ansichten der konfigurierten Eigenschaften.
Anmerkung
Meta-Eigenschaften werden mit dem gleichen Vorgehen angehängt.
Mit Hilfe der Gruppe lassen sich verschiedenste Unterkonfigurationen in einer Ansicht zusammenfassen. Ausnahme, die nur für Front-End gilt: Das Element Eigenschaft kann keine direkte Unterkonfiguration von Gruppe sein. Hierfür braucht es zunächst die Konfiguration Eigenschaften.
Einstellungsmöglichkeiten
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"
Der Konfigurationstyp "Hierarchie" stellt Elemente eines semantischen Modells hierarchisch dar.
Einstellungsmöglichkeiten
Name | Wert |
Beschriftung | Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist. |
Skript für Beschriftung | Es ist auch möglich durch ein Skript eine Beschriftung festzulegen. |
Banner der Hierarchiewurzel anzeigen | Betrifft nur den Knowledge-Builder: Banner wird angezeigt. |
Detailansicht ausblenden | Standardmäßig wird die Detailansicht eines ausgewählten Objektes angezeigt (Knowledge-Builder) oder ausgegeben (json, als subview). Durch Aktivieren dieser Option wird keine Detailansicht angezeigt bzw. ausgegeben. |
Subkonfiguration | Wird eine Detailansicht angezeigt, muss die View-Konfiguration für diese Detailansicht hier angegeben werden. |
Unterelemente erzeugen ohne Frage nach Namen | Wenn neue Unterelemente in der Hierarchie erzeugt werden, wird standardmäßig gefragt, wie ihr Name lauten soll. Ein Häkchen hier, erzeugt ohne Frage nach Namen namenlose Objekte. |
Verbiete manuelles Sortieren | Standardmäßig kann der Anwender im Knowledge Builder Elemente dem Schema entsprechend durch Drag&Drop umhängen. Wird diese Option aktiviert, ist dies nicht mehr möglich. |
Einstellungsmöglichkeiten für die Sortierung
Name | Wert |
Absteigend sortieren | Steuert, ob auf- oder absteigend sortiert wird. Ist dieser Parameter nicht gesetzt, wird aufsteigend sortiert. |
Primäres Sortierkriterium | Auswahlmöglichkeit für das Kriterium, nach dem die Eigenschaften sortiert werden:
|
Sekundäres Sortierkriterium | Sortierkriterium für Eigenschaften, die für das primäre Sortierkriterium den gleichen Wert haben. Einstellmöglichkeiten analog zum Primären Sortierkriterium. |
Skript für Sortierung | Verweis auf ein registriertes Skript, das den Sortierschlüssel für das primäre bzw. sekundäre Sortierkriterium zurückgibt. |
Ermittlungsmöglichkeiten der hierarchiebildenden Elemente
Name | Ermittlung von ... |
Relation (absteigend) | Unterelementen |
Relation (aufsteigend) | Oberelementen |
Strukturabfrage (absteigend) | Unterelementen |
Strukturabfrage (aufsteigend) | Oberelementen |
Skript (absteigend) | Unterelementen |
Skript (aufsteigend) | Oberelementen |
Aktionen und Styles
Es lassen sich sowohl für die gesamte Hierarchie als auch für die einzelnen Knoten Aktionen und Styles anbringen.
Darstellung in einer Anwendung
Erst ab Version 4.1 gibt es die JSON-Repräsentation einer Konfiguration vom Typ Hierarchie.
Darstellung im Knowledge-Builder
In der Detail-Anzeige eines Elements wird im linken Bereich eine Hierarchie eingeblendet. Im rechten Bereich wird das Element mit einer View-Konfiguration ohne Hierarchie angezeigt. Diese View-Konfiguration muss eigens definiert werden und unter Verwendung >> anwenden in muss der Konfigurationsname der Hierarchie angegeben werden. Die Subkonfiguration lässt sich alternativ auch direkt an der Hierarchie unter Subkonfiguration angeben.
Anmerkung
Beispiel - Anwendungsfall
Typischerweise werden Hierarchien verwendet, um Ober-/Unterthema-Relationen oder Teil-von-Relationen darzustellen.
1. Hierarchiebildende Relation
Die direkteste Variante. Die Relationen, die die Hierarchie bilden, werden eingetragen.
2. Hierarchiebildende Strukturabfrage
Die Relationen lassen sich ebenfalls über eine Strukturabfrage ermitteln.
3. Hierarchiebildendes Skript
Auch durch ein Skript lassen sich die möglichen hierarchiebildenden Relationen aufsammeln.
Skript hat Oberthema
function relationsOf(element) { return element.relations('hatOberthema'); }
Eine durch ein Skript generierte HTML-Beschreibung wird an dieser Stelle angezeigt.
Einstellungsmöglichkeiten
Name | Wert |
Beschriftung | Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist. |
Skript | Zur Generierung einer HTML-Beschreibung |
Beispiel
Skript
function render(topic, document) { var writer = document.xmlWriter(); writer.startElement("html"); writer.startElement("body"); writer.startElement("h2"); writer.cdata(topic.name()); writer.endElement(); writer.endElement(); writer.endElement(); }
Generierter Inhalt
<html> <body> <h2>Hermannn</h2> </body> </html>
Ausgabe
Hermann
Ein nicht veränderlicher Text wird ausgegeben.
Einstellungsmöglichkeiten
Name | Wert |
Beschriftung | Eine Beschriftung wird nur ausgegeben, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist. |
Text | Text, der ausgegeben werden soll |
Das View-Konfigurationselement "Suche" kann als Unterkonfiguration einer Alternative oder einer Gruppe ausgewählt werden. Eine beliebige Abfrage ist hier obligatorisch, deren Ergebnisse angezeigt werden. Ein Beispiel, wie man eine solche Suche anlegt wurde bereits in Kapitel Indirekte Eigenschaften konfigurieren gegeben. Auch Suchen zur Benutzereingabe können konfiguriert werden. Ein Beispiel hierfür findet sich in Kapitel Suchen konfigurieren.
Einstellungsmöglichkeiten
Name | Wert |
Abfrage | Hier kann die Suche ausgewählt werden, die sofort ausgeführt wird. Das semantische Objekt für welches die View-Konfiguration angezeigt wird, kann als Zugriffselement in der Abfrage verwendet werden. |
Beschriftung | Eine Beschriftung findet nur ihre Anwendung, wenn diese Konfiguration in einer anderen Konfiguration wie z.B. Alternative eingebettet ist. |
Einstellungsmöglichkeiten für eine Abfrage
Die folgenden Parameter werden als Meta-Eigenschaften für eine Abfrage gepflegt.
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. |
Wertermittlung | 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 für die Suchergebnisse gibt es erst ab Version 4.1 von k-infinity.
Darstellung im Knowledge-Builder
Die Ergebnisse einer beliebigen Abfrage werden im Knowledge-Builder stets in einer Objektliste angezeigt.
Beispiel:
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.
Tabellen können als Unterkonfiguration für die Ergebnisanzeige von Abfragen des Konfigurationstyps "Suche" oder als eigenständige Konfiguration zur Darstellung der Objektlisten im Knowledge-Builder verwendet werden.
Eine Tabelle listet konkrete Objekte, Eigenschaften oder Untertypen eines bestimmten Typs auf. Ob alle Objekte, Eigenschaften oder Untertypen oder nur eine Auswahl angezeigt werden, lässt sich über die Eingabe in den Spaltenköpfen steuern. Mit den eingegebenen Werten wird eine Strukturabfrage nach passenden Objekten, Eigenschaften oder Untertypen ausgeführt und das Ergebnis tabellarisch dargestellt. Außerdem kann bei Objektlisten nach Eingabe von Werten in die Spaltenköpfe ein neues Objekt, ein neuer Eigenschaftswert oder ein neuer Untertyp mit den ausgefüllten Eigenschaften erzeugt werden.
Bestandteile der Konfiguration Tabelle sind Spaltenkonfigurationen. Diese wiederum beinhalten Spaltenelemente. Diese Aufteilung dient der Trennung von spaltenrelevanten Eigenschaften, wie Reihenfolge und Benennung der Spalte in der Tabelle, und der Zuordnung, welche Inhalte in der Spalte angezeigt werden sollen. Spaltenelemente wiederum erlauben die Zuordnung von Eigenschaften, zusätzlich können Skript-Bausteine und Strukturabfrage-Bausteine eingebettet werden.
Die hierarchische Darstellung aller Unterkonfigurationselemente der Tabellenkonfiguration weist eine Menü-Zeile auf, die wie folgt mit Aktionen belegt ist:
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. |
Reihenfolge |
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:
|
Aktionen und Styles
Aktionen und Styles lassen sich für die gesamte Tabelle, aber auch für Zeilen festlegen.
Verwendung
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.
Beispiele:
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:
|
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. |
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.
Einstellungsmöglichkeiten
Name | Wert |
Beschriftung | 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. |
Beispiel
Spaltenkonfiguration für die Spalte Name
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.
Einstellungsmöglichkeiten
Name | Wert |
Eigenschaft (obligatorisch oder Skript) | Verknüpfung zu einem Eigenschaftstyp, der angezeigt werden soll. |
Skript (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. |
Relationszielansicht | 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.
Beispiel
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:
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++) { result.push(secondTargets[j].name());}; }; }; 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.
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 (4.3) 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.
Einstellungsmöglichkeiten
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. |
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. |
Menüart | Die Menüart beschreibt die Verwendung des Menüs in den einzelnen Komponenten. Die Menüarten werden weiter unten beschrieben. |
Werkzeugleiste
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. |
Anmerkungen
Icon | |
Knowledge-Builder | Derzeit lassen sich Kontextmenüs für eine Tabellenzeile und einen Objekteditor erweitern oder neu definieren. Objektkonfiguration: 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. Tabellen-Kofiguration: 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. |
JSON | "label" : "Menü (Kontext)", "actions" : [{...}], "type" : "contextMenu" |
Icon | |
Knowledge-Builder | 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. |
JSON | "label" : "Menü (Liste)", "actions" : [{...}], "type" : "listMenu" |
Icon | |
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. |
JSON | "label" : "Menü (Werkzeugleiste)", "actions" : [{...}], "type" : "toolbar" |
Mit Hilfe von Aktionen lassen sich Zusatzfunktionalitäten an Detail- und Tabellenansichten anbringen.
Im Knowledge-Builder werden die vollständig konfigurierten Aktionen als zusätzliche Schaltflächen angezeigt. Bei einer Selektion wird das enthaltene Skript ausgeführt.
Bei einer Kommunikation mit einer anderen Applikation über JSON wird eine Beschreibung der möglichen Aktion herausgeschrieben. Die Gegenstelle hat dann die Möglichkeit, über einen passenden Request diese Aktion auszuführen zu lassen.
Aktion an einer Objektliste
Die Beschriftung wird als Tooltip im Knowledge-Builder angezeigt. Das ausgewählte Symbol (eine beliebige Bilddatei) wird auf Buttongröße skaliert.
Achtung: Ist kein Symbol angegeben, wird kein Button angezeigt.
Aktuell lassen sich die vier folgenden Skript-Typen ausführen.
Die drei letzten Skript-Typen finden bisher nur bei der Ausgabe über JSON Verwendung.
Dieses Skript wird ausgeführt, wenn der benutzerdefinierte Knopf gedrückt oder ein Action-Request gesendet wird.
"Verweis auf Skript"-Attribut Skript
function onAction(element, context) { return element; }
Variablen
Das Skript einer Aktion kann auf folgende vordefinierte Variablen, in context enthalten, zugreifen:
Detaileditor
Variable | Wert |
selectedElement | Ausgewähltes Objekt oder ausgewählter Typ |
type | Objekttyp. Falls das Element ein Typ ist, wird der Typ selbst verwendet |
Objektliste
Variable | Wert |
selectedElement | Ausgewähltes Objekt oder ausgewählter Typ. nil, falls kein Element oder mehrere Elemente ausgewählt wurden. |
selectedElements | Ausgewählte Elemente |
elements | Alle Elemente der Objektliste |
type | Typ der Objektliste |
"Verweis auf Skript"-Attribut Skript (actionResponse)
function actionResponse(element, context, actionResult) { var actionResponse = new $k.ActionResponse(); actionResponse.setData(actionResult); actionResponse.setFollowup("new"); actionResponse.setNotification("Erledigt","warn"); return actionResponse; }
Die ActionResponse kann um Werte für Followup und Nofication erweitert werden. Diese Werte können von anderen Anwendungen wie z.B. dem ViewConfigMapper ausgewertet werden.
"Verweis auf Skript"-Attribut Skript (visible)
function actionVisible(element, context) { return true; }
Das Skript darf nur einen booleschen Wert zurückliefern. Anhand des Wertes wird entschieden, ob der Knopf angezeigt werden soll oder nicht. Bei der Ausgabe über JSON wird die Aktion nicht weiter betrachtet und somit auch nicht ausgegeben.
"Verweis auf Skript"-Attribut Skript (enabled)
function actionEnabled(element, context) { return true; }
Das Skript darf nur einen booleschen Wert zurückliefern. Anhand des Wertes wird entschieden, ob der Knopf aktiv ist oder nicht. Bei der Ausgabe über JSON wird der Marker enabled auf false gesetzt.
Das die Aktion realisierende Skript kann auf UI-spezifische Funktionen zurückgreifen. Wegen dieser Möglichkeit wird das Skript nicht innerhalb einer einzigen Transaktion ausgeführt. Werden Transaktionen aufgrund von Schreibzugriffen benötigt, dann müssen diese im Skript aufgerufen werden.
$k.UI.alert(message, windowTitle)
Zeigt eine Meldung an.
$k.UI.requestString(message, windowTitle)
Benutzer kann eine Zeichenkette eingeben.
$k.UI.confirm(message, windowTitle)
Öffnet einen Abbrechen-Dialog.
$k.UI.choose(objects, message, windowTitle, stringFunction)
Objekt aus einer Menge auswählen lassen.
$k.UI.openEditor(element)
Standardeditor für das Objekt öffnen.
$k.UI.notificationDialog(notificationFunction, parameters, windowTitle)
Es wird ein Warte- bzw. Benachrichtigungsdialog geöffnet. Dieser kann, je nachdem wie er konfiguriert ist, abgebrochen werden.
Mögliche Parameter:
Parameter | Beschreibung | Standardwert |
autoExpand | Ist der Anzeigebereich des Dialogs initial geöffnet. | true |
canCancel | Kann der Dialog abgebrochen werden. | true |
stayOpen | Bleibt der Dialog nach Beendigung geöffnet. | true |
Beispiel:
ui.notificationDialog(function() { ui.raiseNotification("1"); ui.alert("Hello world"); return undefined; }, { "canCancel" : false }, "Ein Wartedialog");
Mit der folgenden Function raiseNotification können Meldungen auf dem Anzeigebereich ausgegeben werden.
$k.UI.raiseNotification(message)
Diese Benachrichtigung wird nur von der Function notificationDialog gefangen und die Nachricht wird nur dort im Anzeigebereich ausgegeben.
<UIWarn message="${name() + ' lebt'}"/>
Zeigt eine Meldung an.
<UIRequestString message="'Name'"/>
Benutzer kann eine Zeichenkette eingeben.
<UIConfirm message="'Sind Sie versichert?'"/>
Öffnet einen Abbrechen-Dialog.
<UIChooseObject message="'Person'" objects="//Person/instances()"/>
Objekt aus einer Menge auswählen lassen.
<UIOpenEditor/>
Standardeditor für das Objekt öffnen.
<UICreateTopic/>
Objektliste: Ein neues Topic samt Eigenschaften für die Suchfeldeingaben wird angelegt. Editor: Keine Wirkung, liefert null.
<UIOpenTopicList title="Personen" objects="//Person/instances()"/>
Öffnet ein Objektlistenfenster mit den durch das Argument objects festgelegten Wissensnetzelementen.
Die Graph-Editor-Konfiguration ermöglicht es nur bestimmte Typen und Relationen im Graphen anzuzeigen. So kann verhindert werden, dass unerwünschte Typen und Relationen im Graphen zu sehen sind. Die Graph-Editor-Konfiguration kann ebenfalls über JavaScript-Funktionen angefragt werden. Sie findet beispielsweise Verwendung im Net-Navigator.
Sollte keine Graph-Editor-Konfiguration angelegt sein, wird im Graph-Editor des Knowledge-Builders auf eine Fallback-Graph-Editor-Konfiguration zurückgegriffen.
Diese unterscheidet sich für Administratoren und Anwender um einen sinnvollen Standard zu bieten.
Konfigurierte Typen:
Administratoren | Alle Typen und Individuen |
Anwender | Alle Typen und Individuen ohne Technik |
Konfigurierte Relationen für Administratoren und Anwender:
Alle Benutzerrelationen außer:
SystemRelationen:
Der Graph-Editor wird im Technik-Bereich unter View-Konfiguration >> Objekttypen >> Konfigurationselement >> Graph-Editor-Konfiguration konfiguriert.
Eine Graph-Editor-Konfiguration besteht aus einem Graph-Editor-Konfigurations-Objekt. An diesem können Beschriftung und die Anwendung, in welcher diese Graph-Editor-Konfiguration gilt (Bsp. Net-Navigator), konfiguriert werden.
Über den Button "Knotenkategorie neu anlegen" kann eine Knotenkategorie neu angelegt werden. Eine Knotenkategorie definiert ein oder mehrere Typen bzw. dessen Objekte, welche im Graphen angezeigt werden sollen. Diese Typen können über die Relation "anwenden auf" im Reiter Verwendung festgelegt werden. Die Option "anwenden auf Untertypen" bewirkt dabei, dass der Typ und nicht seine Objekte angezeigt werden. Möchte man sowohl den Typ als auch dessen Objekte angezeigt bekommen, legt man zwei Relationen "anwenden auf" mit selbem Ziel an, wobei sich nur "anwenden auf Untertypen" unterscheidet.
Ein Knoten wird im Graphen angezeigt, wenn wenigstens eine Knotenkategorie diesen Typen konfiguriert. Dabei wird auch Vererbung berücksichtigt. Sollte ein Knoten keiner direkten Knotenkategorie angehören, gehört er der Knotenkategorie an, die den ersten Obertypen konfiguriert.
Die Option "an konkreten Typ anpassen" bildet automatisch Knotenkategorien für alle Untertypen der konfigurierten Typen. Dies wird in JavaScript-Funktionen berücksichtigt (siehe Kapitel Graph-Editor Konfiguration in JavaScript), findet im Knowledge-Builder jedoch keine Verwendung.
Eine Knotenkategorie kann Verknüpfungskonfigurationen haben. Diese definieren, welche Relationen an der Knotenkategorie erwünscht sind. Dies beeinflusst das Ausklappen von Relationen, sowie das Anlegen von Relation im Graphen. Eine neue Verknüpfungskonfiguration kann über den Button "neues Anlegen" >> "Verknüpfungskonfiguration" angelegt werden. Konfigurierte Relationen können entweder über das Feld "Relation" direkt angegeben, oder durch ein Skript bzw. eine Strukturabfrage ermittelt werden. Auch konfigurierte Relationen vererben die Konfiguration an ihre Untertypen.
Eine Relation kann angezeigt, ausgeklappt und erstellt werden, falls sowohl Domain als auch Inversedomain des Relationstyps eine Knotenkategorie haben, und der Relationstyp an der Knotenkategorie des Topics konfiguriert ist.
Man kann einen konfigurierten Graphen auch über JavaScript-Funktionen anfragen. Dazu gibt es einige Funktionen die im Folgenden näher beschrieben werden.
Beispiel | Beschreibung |
$k.GraphConfiguration.for("ApplicationName"); | Liefert ein Graph-Editor-Konfigurationsobjekt für einen optionalen Kontext. |
$k.GraphConfiguration.from(configurationTopic); | Liefert die Graph-Editor-Konfiguration welche durch das configurationTopic definiert wird. |
graph.configElement(); | Liefert das KonfigurationsTopic der Graph-Editor-Konfiguration. |
graph.addElements([node1, node2]); | Fügt dem Graphen ein Array von Topics hinzu. |
graph.expand([node1, node2], 2); | Fügt dem Graphen alle Nachbarn bis zu einer Tiefe 2 der angegebenen Knoten hinzu. |
graph.expandNodes(2); | Fügt dem Graphen alle Nachbarn bis zu einer Tiefe 2 aller Knoten hinzu. |
graph.collapse([node1, node2]); | Entfernt die Nachbarn der angegebenen Knoten aus dem Graphen. |
graph.categories(); | Liefert alle Knotenkategorien als JSON. |
graph.possibleRelationTargets(node1); | Liefert die erstellbaren Relationstypen von einem Knoten node1 zu allen anderen Knoten sortiert nach Zielknoten als JSON. |
graph.render(["categories"]); | Liefert den Graphen als JSON. Die angegebenen Filter werden nicht gerendert. |
graph.semanticElements(); | Liefert alle Knoten im Graphen. |
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.
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 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:
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.
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.
Die Konfiguration der Relationszielsuche ermöglicht es, auf die Strategie einzuwirken, mit der mögliche Relationsziele gesucht werden. Enthält ein semantisches Modell keine Relationszielsuche, dann wird auf eine Eingabe von "Egon" immer nach einem Objekt mit Namen "Egon" gesucht (d.h. das jeweilig definierte Namensattribut wird verwendet). Durch Angabe einer zuvor definierten Abfrage kann dieses Verhalten verändert werden. Beispielsweise könnte man für die Suche nach Personen eine Abfrage definieren, die sowohl den Vornamen als auch den Nachnamen durchsucht. Sucht man dann nach einem Ziel für eine Relation, deren Zieldomäne Person ist, dann werden die Nachnamen und Vornamen von Personen nach der Eingabe von "Egon" durchsucht. Sinnvoll ist eine angepasste Relationszielsuche auch, wenn man gleichzeitig Namen und Synonyme von Objekten durchsuchen möchte, sodass beispielsweise das Objekt "Architektur" auch gefunden wird, wenn der Anwender "Baukunst" eingibt.
Relationszielsuche konfiguriert für die Suche nach Personen
Wie bei allen Konfigurationen muss der Kontext angegeben werden, in dem die Relationszielsuche verwendet werden soll. Zusätzlich kann die Verwendung auf einen Typ von Relationszielen oder auch auf einen speziellen Relationstyp eingeschränkt werden. Diese Angaben sind jedoch optional.
Einstellungsmöglichkeiten
Name | Wert |
Hintergrundbild | Ein Bild |
Farbwert für Schriftart einer Aktion | Je nach ausgewähltem Bild muss eine andere Farbe für die Beschriftung der Aktionen gewählt werden, um den Text lesen zu können. |
Darüber hinaus lassen sich Aktionen definieren. Siehe dazu Kapitel Aktion. Zusätzlich kann eine Aktionsart festgelegt werden. Hier stehen folgende Einträge zur Verfügung:
Aktionsart | Aktion |
Handbuch (spezialisierter Web-Link) | Web-Handbuch wird im Browser geöffnet |
Homepage (spezialisierter Web-Link) | Die Homepage wird im Browser geöffnet. |
Support-E-Mail (spezialisierter Web-Link) | Ein Fenster für eine neue E-Mail wird mit der Support-E-Mail-Adresse geöffnet. |
Web-Link | Frei definierbarer Web-Link |
<keine Aktionsart> | Konfigurierte Aktion (mit Skript) ausführen |
Ein Web-Link muss vollständig konfiguriert sein, sonst wird er nicht angezeigt.
Abweichend dazu muss dies bei den drei oberen Aktionsarten (spezialisierte Web-Links) nicht so sein. Diese verwenden, falls eine Eigenschaft fehlt, ihre Standardwerte. Es besteht die Möglichkeit die Standardwerte zu überschreiben.
Konfigurationsmöglichkeit Web-Link
Name | Wert |
Beschriftung | Anzeigename hinter dem Icon |
Symbol | Icon, welches vor der Beschriftung angezeigt wird |
URL | URL die geöffnet werden soll |
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.
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.
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.
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 k-infinity definiert sind. Um welche Elemente es sich handelt und wie diese Style-Elemente im Knowledge-Builder angelegt werden, sodass sie dann mit einzelnen Elementen der View-Konfiguration einer Anwendung verknüpft werden können, wird im Folgenden erläutert.
Zunächst muss das Element der View-Konfiguration ausgewählt werden, mit dem wir ein oder mehrere Style-Elemente verknüpfen wollen. Je nach Typ des View-Konfiguration-Elements stehen verschiedene Reiter zur Konfiguration der Styles zur Verfügung ("Aktionen und Styles" -> "Styles" oder direkt "Styles"). Diesen Reiter wählen wir aus und können dann entweder ein neues Style-Element definieren oder ein bereits vorhandenes Style-Element verknüpfen . Wenn wir ein neues Style-Element definieren, müssen wir diesem zuerst einen Konfigurationsnamen geben. Auf der rechten Seite des Editors kann daraufhin die Konfiguration vorgenommen werden.
Im Folgenden werden die einzelnen Konfigurationsmöglichkeiten für ein Style-Element erläutert:
Name | Attributtyp | StylePropertyKey | Konfigurations- typ | Beschreibung |
actionConfirmation | Verweis auf Skript | actionConfirmation | ||
actionConfirmation | Zeichenkette | actionConfirmation | ||
actionConfirmationTitle | Zeichenkette | actionConfirmationTitle | ||
actionType | Zeichenkette | actionType | ||
class | Zeichenkette | class | ||
class (skript) | Verweis auf Skript | class | ||
collapsed | Boolean | collapsed | ||
Datumsformat | Zeichenkette | DatumFormat | ||
Do not print | Boolean | doNotPrint | ||
Download request | Zeichenkette | downloadRequest | ||
Element ID | Zeichenkette | elementId | ||
extra | Zeichenkette | downloadRequest | ||
group column grid | Zeichenkette | groupColumnGrid | Gruppe | Als Eingabe wird ein String mit Zahlen erwartet, die durch ein Leerzeichen oder ein Komma getrennt werden. Jede Zahl definiert die Anzahl der Spalten, wenn das Maximum 12 Spalten beträgt. |
hide filters | Boolean | hideFilters | ||
hierarchyDetached | Boolean | hierarchyDetached | ||
href | Zeichenkette | href | ||
Label anzeigen | Boolean | hideLabel | ||
Panel | Zeichenkette | panel | ||
render-Mode | Auswahl | renderMode | ||
render-Mode | Zeichenkette | renderMode | ||
schreibgeschützt | Boolean | readOnly | Eigenschaften | Die Eigenschaften des View-Konfiguration-Elements können in der Anwendung nur gelesen und nicht bearbeitet werden. Auch ein "Bearbeiten-Button" wird darum nicht angezeigt. |
vcmStateContext | Auswahl | vcmStateContext | global, none or page | |
vcmStateContext | Zeichenkette | vcmStateContext | ||
vcmTruncate | Ganzzahl | vcmTruncate | ||
Zahlenformat | Zeichenkette | numberFormat | ||
Zeichenkette für Konfigurationswert | Zeichenkette | style | ||
Skript für Konfigurationswert | Verweis auf Skript | style | ||
Zeilen markieren | Boolean | vcmMarkRowClick | ||
Ziel | Zeichenkette | class | ||
Zusätzliche Datumsformate | Zeichenkette | extraDatumFormats |
Falls wir ein neues Style-Element definiert haben, muss noch ein letzter Schritt vorgenommen werden. Damit die vorgenommene Konfiguration auch in die JSON-Ausgabe geschrieben wird, muss bei dem entsprechenden Konfigurationselement im Schema noch eine Ergänzung vorgenommen werden. Zum Schema gelangt man, indem man im Menü des entsprechenden Konfigurationselements auf "Schema" klickt. Im Schema muss man dann unter "Details" -> "Typ" das Attribut "StylePropertyKey" hinzufügen und dort den Namen des Konfigurationselements eingeben.
In der JSON-Ausgabe werden dann die Schlüssel-Wert-Paare (StylePropertyKey -> Style-Eigenschaft) als Array unter dem Schlüssel additionalConfig rausgeschrieben.
Auch ganz eigene Style-Eigenschaften können so definiert werden.
Beispiel
Konfiguration des Typs Zeichenkette für Style-Wert
Konfiguration des Typs Noch eine Zeichenkette für Style-Wert
Konfiguration des Typs Banner anzeigen Attribut
Konfiguration des Objektes Eine Style-Konfiguration vom Typ Style
JSON-Ausgabe:
"properties": [{ "values": [{ ... }], "label": "Vorname", "additionalConfig": { "jsonKey1": ["jsonValue1"], "jsonKey2": ["jsonValue2"], "Banner anzeigen": ["true"] }, "viewId": "ID34304_461524079", "schema": { ... } }
Im Knowledge-Builder bestimmen die Eigenschaften eines Styles über die Darstellung einiger Benutzungsoberflächenelemente. Nicht alle möglichen Eigenschaften eines Styles ergeben für alle Konfigurationen Sinn. Die folgende Tabelle zeigt, welche Eigenschaften von welcher Konfiguration unterstützt werden und was der Effekt ist.
Style-Eigenschaft | Konfigurationstyp | Effekt |
Banner anzeigen | Objektkonfiguration |
Banner mit Namen des Objekts und Schaltflächen zur Bearbeitung anzeigen. Standard ist nein. |
Baumansicht | Gruppe | Elemente der Gruppe als Baum darstellen. Standard ist nein, d.h. die Gruppenelemente werden nebeneinander oder untereinander angezeigt. |
Editorbreite (Pixel) | Eigenschaft | Breite in Pixeln einer Eigenschaft |
Vertikale Anordnung | Gruppe | Elemente der Gruppe nebeneinander darstellen. Standard ist untereinander anzeigen. |
Höhe | Gruppe | Höhe eines Gruppenelements in Pixeln bei nebeneinander dargestellten Gruppenelementen. |
Höhe | Eigenschaft | Höhe in Zeilen bei Zeichenkettenattributen |
Meta-Eigenschaften im Kontextmenü einblenden | (Meta-) Eigenschaft(en) |
Metaeigenschaften werden im Kontextmenü der Eigenschaft eingeblendet. Somit kann man entweder einzelne Meta-Eigenschaften oder alle Meta-Eigenschaften einer Meta-Eigenschaftenkonfiguration einblenden. (Anmerkung: Der Menüpunkt Metaeigenschaften hinzufügen bleibt dabei unverändert). |
Vorschau anzeigen | Tabelle | Steuert, ob unterhalb der Tabelle ein Editor angezeigt wird. |
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.
The JavaScript-API is a server-side API for accessing a semantic net. The API is used in triggers, REST services, reports etc.
The API reference is available here:
www.k-infinity.de/api/4.0/index.html
Most objects are defined in the namespace $k. The namespace object itself has a few useful functions, e.g.
$k.rootType())
which returns the root type of the semantic network, or
$k.user())
which returns the current user.
Another important object is the Registry object $k.Registry. It allows to access objects by their registered key (folder elements) / internal name (types).
Examples:
$k.Registry.type("Article")
returns the type with the internal name "Article".
$k.Registry.query("rest.articles")
returns the query with the registered key "rest.articles".
The Registry object is a singleton, similar to JavaScript's Math object.
Semantic elements are usually retrieved from the registry or by a query.
// Get the person type by its internal name var personType = $k.Registry.type("Person");
// Perform the query named "articles", // with the query parameter "tag" set to "Sailing" var sailingArticles = $k.Registry.query("articles").findElements({tag: "Sailing"});
The properties of an element can be accessed by specifying the internal name of the property type.
// Get the value of the attribute "familyName" var familyName = person.attributeValue("familyName"); // Get the target of the relation "bornIn" var birthplace = person.relationTarget("bornIn");
A shortcut to access the value of the name attribute is the function name()
var name = birthplace.name();
If an attribute is translated, the desired language can be specified, either as 2-letter or 3-letter ISO 639 language code. The current language of the environment is used if no language is specified.
var englishTitle = book.attributeValue("title", "en"); var swedishTitle = book.attributeValue("title", "swe"); var currentTitle = book.attributeValue("title");
Transactions 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:
$k.transaction( function() { return $k.Registry.type("Article").createInstance() }, function() { throw "The transaction was rejected" } );
// 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 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");
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]);
Any element can be deleted with the remove() function:
person.remove();
This also deletes all properties of the element.
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"));
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*"});
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
person.remove()
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) relation[r].isolate(); 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. response.setContents(images[0].value()); // Show the image instead of asking to download the file response.setContentDisposition("inline"); } else { response.setCode($k.HttpResponse.BAD_REQUEST); response.setText(images.length + " images found"); } } else { response.setCode($k.HttpResponse.BAD_REQUEST); 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); city.setName(name); response.setText("Created city " + name); } else { response.setCode($k.HttpResponse.BAD_REQUEST); 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(); writer.startElement("result"); for (var t in topics) { writer.startElement("poi"); writer.attribute("name", topics[t].name()); writer.endElement(); } writer.endElement(); response.setContents(document); response.setContentType("application/xml"); } else { response.setCode($k.HttpResponse.BAD_REQUEST); response.setContents("Name not specified"); } }
XML output
<result> <poi name="Plaza Mayor"/> <poi name="Plaza de la Villa"/> <poi name="Puerta de Europa"/> </result>
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"); writer.startElement("child","k").endElement(); writer.endElement();
XML output
<k:root xmlns:k="http://www.i-views.de/kinfinity" k:hidden="true"> <k:child/> </k:root>
Define a default namespace
var document = new $k.TextDocument(); var writer = $k.out.xmlWriter(); writer.startElement("root"); writer.defaultNamespace("http://www.i-views.de/kinfinity"); writer.startElement("child").endElement(); writer.endElement();
XML
<root xmlns="http://www.i-views.de/kinfinity"> <child/> </root>
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); portree.setName("Portree"); }
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 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"); mail.setSender("kinfinity@example.org"); mail.setReceiver("developers@example.org"); mail.setUserName("kinf"); mail.send();
Das Benutzerkonto "kinf" wird für die Authentifizierung verwendet. Das Passwort wird in den SMTP-Einstellungen hinterlegt.
JSON-Strukturen können auch anhand der View-Konfiguration generiert werden, sowohl für einzelne Objekte als auch Objektlisten.
Im einfachsten Fall wird ein Objekt anhand der Standard-Konfiguration ohne weiteren Kontext in JSON umgewandelt:
var data = element.renderJSON();
Es werden dann alle durch die Konfiguration definierten Strukturen in JSON umgesetzt:
{ "viewType" : "fieldSet", "label" : "Bern", "elementType" : "instance", "modNum" : 26, "elementId" : "ID17361_141538476", "type" : { "elementType" : "instance", "typeId" : "ID10336_319205877", "internalName" : "City", "typeName" : "Stadt" }, "properties" : [{ "values" : [{ "value" : "Bern", "propertyId" : "ID17361_137824032" } ], "schema" : { "label" : "Name", "elementType" : "attribute", "internalName" : "name", "maxOccurrences" : 1, "attributeType" : "string", "viewId" : "ID20838_426818557", "typeId" : "ID4900_317193164", "minOccurrences" : 0 } }, { "values" : [{ "typeId" : "ID4900_79689320" } ], "schema" : { "label" : "Alternativname/Synonym", "elementType" : "attribute", "internalName" : "alternativeName", "attributeType" : "string", "rdf-id" : "alternativeName", "viewId" : "ID20839_64952366", "typeId" : "ID4900_79689320", "minOccurrences" : 0 } }, { "values" : [{ "target" : { "typeId" : "ID10336_493550611", "label" : "Kunstmuseum Bern", "elementId" : "ID17362_205182965" }, "propertyId" : "ID17361_395925739" }, { "target" : { "typeId" : "ID10336_493550611", "label" : "Schweizerische Nationalbibliothek", "elementId" : "ID20401_126870015" }, "propertyId" : "ID17361_9264966" } ], "schema" : { "targetDomains" : [{ "elementType" : "instance", "typeId" : "ID10336_493550611", "internalName" : "point_of_interest", "typeName" : "Sehenswürdigkeit" } ], "label" : "beherbergt Sehenswürdigkeit", "elementType" : "relation", "internalName" : "contains_poi", "viewId" : "ID20840_182208894", "typeId" : "ID2052_332207092", "minOccurrences" : 0 } } ] }
Zusätzlich kann ein Kontext in Form eines Anwendungs- oder Konfigurationsobjekts angegeben werden. Es wird dann ein zu diesem Kontext passende Konfiguration gewählt. Im folgenden Beispiel wird die Anwendung "Android" vorgegeben:
var application = $k.Registry.elementAtValue("viewconfig.configurationName", "Android"); var data = element.renderJSON(application);
Es ist aber auch möglich, eine Konfiguration vorzugeben und diese das Element umwandeln zu lassen. Dazu erzeugt man eine $k.ViewConfiguration aus dem Konfigurationsobjekt.
var configurationElement = $k.Registry.elementAtValue("viewconfig.configurationName", "Android Article Configuration"); var data = $k.ViewConfiguration.from(configurationElement).renderJSON(element);
Da die JSON-Struktur recht umfangreich ist, kann man auch bestimmte Properties bei der Umwandlung weglassen, indem man die Schlüssel als zusätzlichen Parameter angibt:
var application = $k.Registry.elementAtValue("viewconfig.configurationName", "Android"); var data = element.renderJSON(application, ["rdf-id", "viewId", "typeId", "propertyId", "modNum", "minOccurrences", "maxOccurrences"]);
{ "viewType": "fieldSet", "label": "Bern", "elementType": "instance", "elementId": "ID17361_141538476", "type": { "elementType": "instance", "internalName": "City", "typeName": "Stadt" }, "properties": [ { "values": [ { "value": "Bern" } ], "schema": { "elementType": "attribute", "label": "Name", "internalName": "name", "attributeType": "string", "maxOccurrences": 1 } }, { "schema": { "elementType": "attribute", "label": "Alternativname/Synonym", "internalName": "alternativeName", "attributeType": "string" } }, { "values": [ { "target": { "label": "Kunstmuseum Bern", "elementId": "ID17362_205182965" } }, { "target": { "label": "Schweizerische Nationalbibliothek", "elementId": "ID20401_126870015" } } ], "schema": { "elementType": "relation", "targetDomains": [ { "elementType": "instance", "internalName": "point_of_interest", "typeName": "Sehenswürdigkeit" } ], "label": "beherbergt Sehenswürdigkeit", "internalName": "contains_poi" } } ] }
The following restlet function renders a document using the Mustache template library. It expects the following schema of a template document:
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 $k.module("mustache.js"); // 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 response.setText(output); response.setContentType(templateTopic.relationTarget("template.contentType").name()); }
Java can be accessed via JNI (Java Native Interface).
Caution: JNI is an experimental feature and has several restrictions:
[JNI] classPath=tika\tika-app-1.5.jar 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 "); builder.append($k.volume()); // toJS() converts Java objects to Javascript objects $k.out.print(builder.toString().toJS());
Text/metadata extraction with Apache Tika
$jni.use([ "java.io.ByteArrayInputStream", "java.io.BufferedInputStream", "java.io.StringWriter", "org.apache.tika.parser.AutoDetectParser", "org.apache.tika.metadata.Metadata", "org.apache.tika.parser.ParseContext", "org.apache.tika.sax.BodyContentHandler" ], 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 { bufferedInputStream.close(); }
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())
$k.define({ /* * 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") } }});
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.
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.
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 $k.out.print(testResponse.debugString());
Breakpoints can be set on the tab "Debug".
Restlet scripts can be also be debugged with a remote debugger.
[KRemoteDebuggerBridge] port=9000
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) { subtype.printSchema(); }); } // 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(", "); else separate = true; $k.out.print("\"" + inverseDomain.type().name() + "\""); }); $k.out.print(")"); } } $k.out.cr(); } // 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) { propertyType.logPropertySchema(); }); } } // Print the entire schema $k.rootType().printSchema();
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"); }, 0); } // 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");
Ü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
https://<hostname>:<port>/<service-id>/<resource-pfad-und-parameter>
aufgebaut sind.
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.
[Default] host=localhost loglevel=10 [KHTTPRestBridge] volume=demo port=8086 services=core,extra
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.
Ressourcen beschreiben das Verhalten bei einer HTTP-Anfrage an die Schnittstelle. Es gibt folgende Arten von Ressourcen:
Ressource | Beschreibung |
Script Resource | Durch Skripte definierbare Ressource. |
Built-In Resource | Vordefinierte Ressource, deren Verhalten vom System definiert ist. Diese Ressourcen werden von der Komponente angelegt. |
Static File Resource | Liefert 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: albums/{genre} Es können mehrere Parameter angegeben werden. Jeder Parameter muss aber ein kompletter durch "/" getrennter Teil sein: albums/{genre}-{year} ist nicht gültig, albums/{genre}/{year} schon |
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 |
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. |
Script | Registriertes Skript zur Definition des Verhaltens (nur bei Script-Ressourcen relevant) |
Transaction | 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 |
Automatic | Bei GET nur lesender Zugriff, bei POST/PUT/DELETE wird das Skript in einer Transaktion ausgeführt. |
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. |
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.
Argument | Typ | Beschreibung |
request | $k.HttpRequest | Anfrage (URL, Header, usw.) |
parameters | Object | Aus dem Request extrahierte Parameter |
response | $k.HttpResponse | Antwort |
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")); response.setContentType("application/json"); }
Dieses Skript könnte man z.B. mit bei einer Ressource
albums/{genre}/{year}
verwenden und in der Abfrage "albums" die Suchparameter "genre" und "year" als Suchbedingungen verwenden.
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 | Methode | Beschreibung |
BlobResource | GET | Gibt den binären Inhalt eines bestehenden Blob-Attributes zurück. Das Blob-Attribut wird über den Query-Parameter "blobLocator" identifiziert. |
BlobResource | POST, PUT | Ändert den binären Inhalt eines Blob-Attributes. Das Blob-Attribut wird über den Query-Parameter "blobLocator" identifiziert. Je nach Typ des blobLocators wird ein neues Attribut angelegt oder ein bestehendes verändert. |
EditorConfigResource | GET, POST, PUT | Ausgeben und Einlesen einer XML-Repräsentation eines semantischen Elementes. |
ObjectListResource | GET | Gibt eine Tabelle von Instanzen oder Untertypen von dem angegebenen Typ zurück. Optional kann gefiltert, sortiert oder direkt die Menge der Objekte definiert werden. |
ObjectListPrintTemplateResource | GET | Gibt eine Tabelle von Instanzen oder Untertypen in gedruckter Form zurück. Das Drucktemplate muss angegeben sein. |
ObjectListPrintTemplateResourceWithFilename | GET | Gibt eine Tabelle von Instanzen oder Untertypen in gedruckter Form zurück. Das Drucktemplate muss angegeben sein. Der Parameter {filename} wird nicht ausgewertet und dient allein der besseren Handhabung im Browser. |
TopicIconResource | GET | Gibt das Icon oder Bild des angegebenen semantischen Elementes zurück. |
Ab K-Infinity 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.
BlobResource
Diese eingebaute Resource ermöglicht das Laden und Speichern der Inhalte von Datei-Attributen.
Download
Ü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.
Upload
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.
http://{server:port}/baseService/topicIcon/{topicID}?size=10
Objektliste
Über den folgenden Pfad kann eine Objektliste im JSON-Format angefordert werden:
http://{server:port}/baseService/{conceptLocator}/objectList
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.
Filter
Über den optionalen und mehrwertigen Query-Parameter "filter" kann die Objektliste gefiltert werden. Ein Filter hat zwei mögliche Formen:
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.
Sortierung
Ü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:
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".
Vererbung
Ü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", "Mustermann", "Max", "111", "m.mustermann@email.net", "10", "6", "2000-01-01", "Projekt A, Projekt B"] }, { topicID: "ID987_123456789", row: ["MF", "Musterfrau", "Maxine", "222", "m.musterfrau@email.net", "10", "8", "2000-01-01", "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" }] }
Objektlistendruckvorlage
Über den folgenden Pfad kann eine Objektliste in eine 'Druckvorlage für Liste' gefüllt und das Resultat heruntergeladen werden:
http://{server:port}/baseService/{conceptLocator}/objectList/printTemplate/
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:
http://{server:port}/baseService/{topicLocator}/printTemplate/
"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.
Dokumentformatkonvertierung
Über den folgenden Pfad kann ein Dokument in ein anderes Format umgewandelt werden (z.B. odt in pdf):
http://{server:port}/baseService/jodconverter/service
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"
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.
Beispiel:
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
Unterhalb von Methoden kann man die Parameter der Ressource definieren. Dies ist nicht zwingend erforderlich, hat aber einige Vorteile:
Folgende Parameter-Eigenschaften können konfiguriert werden:
Parameter name | Name des Parameters |
Style | Art des Parameters
|
Type | Datentyp des Parameters. Parameter werden validiert und umgewandelt an das Skript übergeben. |
Repeating | 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. |
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:
[KHTTPRestBridge]
accessControlAllowOrigin=http://*.i-views.de
accessControlAllowHeaders=Origin, X-Requested-With,Content-Type, Accept
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.
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.
Die RTF-Vorlagedateien können auswertbare KPath-Ausdrücke mit den Schlüsselworten 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.
KPATH_EXPAND
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.
Beispiel:
Die Vorlage sei:
Absender: <KPATH_EXPAND @$adresse$/rawValue()>
Nach Auswertung steht in der Ausgabedatei:
Absender: intelligent views gmbh
Julius-Reiber-Str. 17
64293 Darmstadt
KSCRIPT_EXPAND
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.
Beispiel:
Die Vorlage sei:
<KSCRIPT_EXPAND einSkriptDas1bis9Ausgibt>
Nach Auswertung steht in der Ausgabedatei:
123.456.789
KPATH_ROWS
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.
Beispiel:
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 |
RTF-Druck | |
ODT-Druck | Ersetzt den RTF-Druck |
Konvertierungsservice | Optionaler Dienst |
KSCRIPT_ROWS
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.
Beispiel:
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 |
Der Druck über das ODT-Format (Open Document Text, offener Standard) hat viele Vorteile gegenüber dem RTF-Format:
ODT-Vorlagen können mit OpenOffice 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.
Als Skript-Typen gibt es:
ScriptID->Funktionsname()Der Funktionsaufruf wird automatisch um zwei Argumente erweitert: das semantisch Elemente und die durch die Umgebung vorgegebenen Variablen
function headerLabel(element, variables) { return element.name().toLocaleUpperCase(); }
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-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.
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. K-Infinity sorgt dafür, dass alle Formeln neu berechnet werden, sobald die ausgefüllte Excel-Datei das nächste Mal mit Excel geöffnet wird.
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.
[file-format-conversion] sofficePath="C:\Program Files (x86)\LibreOffice 4.0\program\soffice.exe"
Konvertierungsservice
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:
[Default] host=localhost [KHTTPRestBridge] port=3040 volume=kartenverwaltung services=jodService [file-format-conversion] 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.
Beispiel:
http://localhost:3040/jodService/jodconverter/service
Dokument-Formate
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 | application/pdf | |
OpenDocument Text | odt | application/vnd.oasis.opendocument.text |
Microsoft Word | doc | application/msword |
Falls es zu einem Aufrufparameter auch einen Eintrag der Ini-Datei gibt, hat der der Aufrufparameter höhere Priorität.
-inifile <Dateiname>, -ini < Dateiname >
Name der Ini-Datei, die statt dem Standard-Ini-Datei verwendet wird.
-host <hostname:port>, -hostname <hostname:port>
Die Bridge kann als Windows-Dienst installiert werden: bridge -installAsService <Name> [<Dienst_1> ... <Dienst_n>]
„Name“ gibt den Namen des Windows-Dienstes an. Das aktuelle Verzeichnis, aus dem die Installation als Dienst gestartet wird, wird als Arbeitsverzeichnis verwendet
Die (optionale) angegeben Dienste werden als benötigte Dienste eingetragen. Insbesondere der K-Infinity Server-Dienst bietet sich hier an.
Der Starttyp des Dienstes kann danach noch bei Bedarf in der Windows-Diensteverwaltung auf „Automatisch“ geändert werde.
Der Dienst kann mit
bridge -deinstallService <Name>
wieder entfernt werden. Vorsicht: Es wird nicht überprüft ab der angegebene Dienst tatsächlich eine Bridge oder ein anderer Dienst ist. Alternativ kann der Dienst auch mit dem Service Control-Tool von Microsoft deinstalliert werden:
sc delete <Name>
Der K-Infinity Server sorgt für konsistente und persistente Datenhaltung und für die Aktualität der Daten auf den angeschlossenen K-Infinity Clients.
Die Datenhaltung erfolgt in einer objektorientierten Datenbank, die durch ein optimistisches Transaktionssystem kooperatives Arbeiten auf dem Wissensnetz ermöglicht.
In seiner Funktion als Kommunikationszentrale sorgt der K-Infinity Server für die Synchronisation von Clients und Services. Als Basismechanismus stellt er hierfür einen geteilten Objektraum und aktive Updates zur Verfügung.
Technische Daten:
Der K-Infinity Server ist Plattform-unabhängig und läuft auf allen gängigen Betriebssystemen, z. B. Windows, Solaris und Linux (ab Kernel 2.2).
OS | Version | Prozessor | Unterstützt | 64 Bit VM |
Windows | 10, 8, 7,Vista, 2000, XP, Server 2003, 2008, 2012 | x86 | ja | ja |
2003 | IA64 | x86 Emulation | nein | |
AIX | 5.3 | ja | nein | |
HP-UX | 11.x | PA-RISC | ja | nein |
11.x | IA64 | nein | nein | |
Solaris | 8+ | Sparc | ja | ja |
10 | x86 | nein | nein | |
Linux | RedHat, SLES9+, u.a. | x86 | ja | ja |
RedHat, SLES9+, u.a. | IA64 | x86 Emulation | nein | |
RedHat, SLES9+, u.a. | PPC | ja | nein | |
Mac | OSX 10.4+ | x86 | ja | nein |
OSX 10.4+ | PPC | ja | nein |
Der K-Infinity Server benötigt prinzipiell keine spezielle Installation, d.h. er ist ad hoc aus einem beliebigen Verzeichnis startbar.
Es ist dabei darauf zu achten, dass die notwendigen Zugriffsrechte (lesen/schreiben/erzeugen) für das Arbeitsverzeichnis des Servers und alle Unterverzeichnisse gesetzt sind.
Dem Mediator Prozess können beim Start diverse Parameter mit übergeben werden. Die meisten Parameter können aber auch in der mediator.ini angegeben werden, sodass man den Mediator mit einer einfachen Kommandozeile starten kann. Dabei gilt, dass auf der Kommandozeile angegebene Parameter Präzedenz vor evtl. doppelt in der .ini-Datei angegebenen Parametern haben.
Die komplette Liste der möglichen Startparameter gibt der Mediator beim Aufruf mit dem Parameter "-?" aus.
-port <num>
Startet den Server mit der Portnummer <num>. Ohne diese Angabe wird Port 30060 verwendet.
Dieser Parameter ist veraltet. Er wird durch den Parameter "interface" ersetzt. Dabei entspricht ein Eintrag von "-port 1234" dem Eintrag "-interface cnp://0.0.0.0:1234".
-interface <interface-1>
Dieser Parameter bestimmt, unter welchen Adressen und Protokollen der Server erreichbar ist. Mögliche Protokolle sind: http, https, cnp, cnps. Dabei steht "cnp" für "Coast Native Protocol" bzw. "Coast Native Protocol Secure". Der syntaktische Aufbau einer Interface-Definition entspricht der einer URL mit Schema, Host und Port. Über den Host-Teil steuert man, über welche Netzwerkadresse(n) der Server erreicht werden kann. z.B: "0.0.0.0"=IPv4 alle Interfaces, "[::1]"=IPv6 nur Loopback.
Die Protokolle "http" und "https" lassen sich über Proxies umleiten, so dass man den Server bspw. über einen auf Port 443 laufenden IIS erreichen kann.
-password <passwd>
Setzt das Passwort zum Stoppen des Servers auf <passwd>
-clientTimeout <sec>
Setzt die Zeit, innerhalb der sich ein Client automatisch melden muss, auf <sec> Sekunden. Der Wert sollte mindestens auf 600 gesetzt werden (was auch der Standardwert ist).
-baseDirectory <directory>
Setzt das Verzeichnis, in dem sich das Verzeichnis "volumes" befindet. Neben dem Unterverzeichnis "volumes" werden hier auch standardmäßig die Verzeichnisse für Backups und Downloads angelegt. Dieser Parameter hieß früher "-volumes".
Die folgenden Parameter stellen Kommandos an das Mediator Executable, um bestimmte Aufgaben auszuführen, ohne danach als Server für Wissensnetze zu fungieren.
-quickRecover <volume> -recover <volume>
Falls der Mediator unordnungsgemäß beendet wird (z.B. Absturz des Rechners), bleiben in Volumes, die in Benutzung waren, Lock-Dateien stehen. Das Volume kann dann nicht mehr betreten werden. Um das Lock aufzuheben, kann man mit dem Aufruf von -quickRecover <volume> das Lock entfernen. Der Aufruf schlägt fehl, wenn (mögliche) Inkonsistenzen gefunden wurden. In diesem Fall muss der Startparameter -recover verwendet werden.
-stop -password <passwd>
Stoppt den Server auf 'localhost' mit den gegebenen Parametern (port und password)
-stop -host <hostname> -password <passwd>
Stoppt den Server auf ‚hostname’ mit den gegebenen Parametern (port und password)
Achtung:
Das Arbeitsverzeichnis beim Aufruf muss hier das Verzeichnis sein, welches das „volumes“-Verzeichnis enthält. Der „-volumes“-Parameter wirkt hier also nicht.
-backup <volume> [-host hostname] [-port portnumber] [-password <passwd>] -startBackup <volume> [-host hostname] [-port portnumber] [-password <passwd>] -waitForBackup <volume> [-host hostname] [-port portnumber] [-password <passwd>]
Da das Backup des BlockfileSystems asynchron erfolgt, wird mit -startBackup ein Backup gestartet, ohne auf dessen Beendigung gewartet werden muss. Mit -waitForBackup kann man nun im Falle eins laufendes Backups den Aufrufer blockieren, bis das Backup fertig ist. Um ein Backup zu Starten und die Beendigung abzuwarten, kann man über den Parameter -backup ein Backup starten.
-bfscommand <volume> <command>
Führt Kommandos aus, die vom BlockFileSystem erkannt werden.
Kommandozeilen-Parameter für das Logging:
-nolog
Schaltet Logging ab
-loglevel <Integer>
Konfiguriert, welche Meldungen im Log erscheinen sollen:
-logfile <Dateiname>, -log <Dateiname>
Name der Log-Datei, die statt der Standard-Log-Datei verwendet wird. Dieser Parameter muss auf jeden Fall verändert werden, wenn mehrere Clients im selben Arbeitsverzeichnis gestartet werden sind.
-debug
Schaltet das Logging auf debug-mode
-log <logname>
Setzt die Logdatei auf <logname>.
Einige Mediator-Einstellungen können auch in der Konfigurationsdatei mediator.ini festgelegt werden. Der Aufbau der Datei sieht folgendermaßen aus:
[Default] parameterName1=parameterWert1 parameterName2=parameterWert2 ...
Folgende Parameter sind an dieser Stelle einsetzbar:
port=<portnummer>
Startet den Server mit der Portnummer <num>. Ohne diese Angabe wird Port 30061 verwendet.
Dieser Parameter ist veraltet. Er wird durch den Parameter "interfaces" ersetzt. Dabei entspricht ein Eintrag von "port=1234" dem Eintrag "interfaces=cnp://0.0.0.0:1234". Im Unterschied zum Startparameter sind hier mehrere Werte zulässig, die, durch Komma getrennt, hintereinander aufgezählt werden.
interfaces=<interface-1>,<interface-2>,...<interface-n>
Dieser Parameter bestimmt, unter welchen Adressen und Protokollen der Server erreichbar ist. Mögliche Protokolle sind: http, https, cnp, cnps. Dabei steht "cnp" für "Coast Native Protocol" bzw. "Coast Native Protocol Secure". Der syntaktische Aufbau einer Interface-Definition entspricht der einer URL mit Schema, Host und Port. Über den Host-Teil steuert man, über welche Netzwerkadresse(n) der Server erreicht werden kann. z.B: "0.0.0.0"=IPv4 alle Interfaces, "[::1]"=IPv6 nur Loopback.
Die Protokolle "http" und "https" lassen sich über Proxies umleiten, so dass man den Server bspw. über einen auf Port 443 laufenden IIS erreichen kann.
baseDirectory=<Verzeichnis>
Setzt das Verzeichnis, in dem sich das Verzeichnis ‚volumes’ befindet. Sollte dieser Wert auf volumes enden, so wird dieses Verzeichnis direkt verwendet, ohne noch zusätzlich darunter ein Verzeichnis ‚volumes’ anzulegen.
volumesDirectory=<Verzeichnis>
In diesem Verzeichnis liegen die Wissensnetze. Als Standardwert ist an dieser Stelle 'volumes' eingetragen.
backupDirectory=<Verzeichnis>
Gibt das Verzeichnis an, in welches Wissensnetz-Backups geschrieben und zum Wiederherstellen auch gelesen werden. Nur vollständige Verzeichnisnamen erlaubt, keine Relativ-Angabe.
networkBufferSize=<Größe in Bytes>
Gibt die Größe des Puffers an, der für das Senden/Empfangen von Daten verwendet wird. Der Standardwert ist 20480. In manchen Infrastrukturen kann man durch Angabe von
networkBufferSize=4096
einen höheren Durchsatz erreichen.
flushJournalThreshold=<Anzahl der Cluster>
gibt den Maximalwert an, den "veränderte Cluster" + "Indexcluster" in einem Speichervorgang erreichen dürfen. Wenn der Wert für "veränderte Cluster" bereits überschritten ist, werden keine "Indexcluster" gespeichert sondern diese werden mit Journal geführt.
Ein niedriger Wert (z.B. 50) garantiert schnelle Speicherzeiten, baut aber potentiell ein großes Journal auf.
Ein Wert von "0" deaktiviert Journaling. Standardwert ist "2000".
Anmerkung: Ein "flush" des Journals wird immer spätestens bei einer vollständigen Speicherung ausgeführt. Diese wiederum wird ausgelöst, wenn:
autoSaveTimeInterval=<Warteintervall in Sekunden>
gibt an in Sekunden, wie lang nach dem letzten Cluster-Speichern maximal gewartet wird, bis wieder automatisch gespeichert wird. Standardwert ist 15.
clientTimeout=<Timeout in Sekunden>
gibt die Zeit in Sekunden an, die ein verbundener Client maximal keine Alive-Nachricht geschickt haben darf, bevor der Mediator ihn als inaktiv erachtet und ihn ausschließt.
skipVolumesCheck=<true|false>
gibt an, ob die normalerweise nach dem Start des Mediators durchgeführte Überprüfung der vorhandenen Volumes ausgelassen wird
Geändert
Logging-Einstellungen:
loglevel = <Integer>
Konfiguriert, welche Meldungen im Log erscheinen sollen:
debug = true/false
Setzt den Log-Level bei true auf 0, bei false auf 10
channels = <Channel1> [,<Channel2>,...]
Namen von Channelfiltern. Mit Hilfe der Channelfilter werden nur Log-Meldungen ausgegeben, die zu den angegebenen Channelfiltern gehören. Der Name eines Channelfilters deutet darauf hin, zu welchem Themengebiet die Log-Ausgaben gehören. Welche Channelfilter möglich sind, erfährt man in der Kommandozeile mit Hilfe des Parameters -availableChannels.
logfile = <Dateiname> log = <Dateiname>
Name der Log-Datei, die statt der Standard-Log-Datei verwendet wird.
maxLogSize = <size>
die maximale Größe des Logfiles, ab der die alte Logdatei archiviert wird und eine neue angebrochen wird. Bei Werten kleiner als 1024 wird die Angabe als in MB verstanden
notifiers = <Name1> [,<Name2>,...]
Namen von Notifiern. Ein Notifier wird bei Log-Ausgaben ab einem bestimmten Level aktiviert (typischerweise bei Fehlermeldungen). Siehe Abschnitt „Notifier“.
logprefix = <Prefix1> [, <Prefix2>,... ]
Zusätzliche Daten, die bei jeder Log-Ausgabe hinzugefügt werden
Bei einem Präfix, der nicht in dieser Liste enthalten ist, wird der Präfix unverändert ausgegeben.
Speicher-Einstellungen:
Die folgenden drei Parameter dienen zur Konfiguration der Speicherzuteilung und -nutzung. Erlaubt ist die Angabe von Werten entweder in Megabyte oder in tatsächlichen Byte, wobei die Annahme gilt, dass sich Werte kleiner als 1048576 auf Megabyte-Angaben beziehen.
maxMemory=<Integer, in MB>
Maximal erlaubte Hauptspeicherbelegung. Minimal 50 MB, standardmäßig gesamter physikalisch vorhandener Hauptspeicher (unter Windows) bzw. 512 MB.
growthRegimeUpperBound=<Integer, in MB>
Hauptspeicherbelegung ab der verstärkt versucht wird, Speicher freizugeben. Standardmäßig 0.6 * maxMemory.
freeMemoryBound=<Integer, in MB> [10]
Falls belegter, aber nicht mehr benötigter Speicher diese Grenze überschreitet, wird er wieder freigegeben.
Mail-Notifier Einstellungen:
Log-Ausgaben können über Mail-Notifier zusätzlich zum Eintrag in die Log-Datei per Mail versendet werden. Sinnvollerweise wählt man einen nicht zu geringen Schwellwert (Log-Level = 30), ab dem eine Mail versendet wird.
Für jeden angegebenen Namen aus der Notifier-Liste muss eine Konfiguration angegeben werden, die im Abschnitt [Name] angegeben wird.
Folgende Angaben sind für alle Notifier gleich:
Spezifische Angaben für COAST.CoastMailNotifier;
TLS/SSL ist für Authentifizierung nicht zwingend erforderlich, aber dringend zu empfehlen. Die Kompatibilitätserweiterung STARTTLS wird nicht unterstützt.
Beispiel:
notifiers = errorMailNotifier [errorMailNotifier] class = COAST.CoastMailNotifier level = 30 ;Spezifische Angaben für Mail-Versand attachLog = true sender = sender@hostname.de recipient = receiver@hostname.de smtpHost = mailserver.hostname.de retries = 3 retryDelay = 30
Die angegebene Konfiguration definiert einen Mail-Notifier, die alle Fehlermeldungen per Mail verschickt.
BLOB-Service-Konfiguration
Soll der Mediator mit einem integrierten BLOB-Service gestartet werden, damit die BLOBs getrennt von der Datenbank auf der Festplatte gespeichert werden, so muss die folgende Einstellung in der "mediator.ini" eingetragen werden:
startBlobService=true
Nähere Informationen dazu finden Sie in der Dokumentation des BLOB-Service (siehe Link unten).
Zur Installation als Windows-Dienst werden Administrator-Rechte benötigt.
-installAsService <name>
Installiert den Server als Dienst unter dem angegebenen Namen. Alle Startparameter außer stop werden dabei übernommen. Ein evtl. gleichnamiger Dienst wird zuvor deinstalliert. Das aktuelle Verzeichnis, aus dem die Installation als Dienst gestartet wird, wird als Arbeitsverzeichnis verwendet. Auf einem System können mehrere Server installiert werden, wenn Arbeitsverzeichnisse, Ports und Servicenamen sich nicht überschneiden. Nach der Installation empfiehlt sich eine Anpassung der Startart des Dienstes auf „automatisch“ und ein automatischer Neustart des Dienstes im Fehlerfall.
-deinstallService <name>
Entfernt den angegebenen Dienst. Die Dateien des Dienstes bleiben erhalten. Vorsicht: Es wird nicht überprüft ab der angegebene Dienst tatsächlich ein K-Infinity Server oder ein anderer Dienst ist.
Alternativ kann der Dienst auch mit dem Service Control-Tool von Microsoft deinstalliert werden:
sc delete <name>
Parameter, die nicht mehr zur Verfügung stehen:
-installService <service name> <service runtime path>
Bitte stattdessen den Parameter -installAsService verwenden.
Der K-Infinity Server ist eine generische Komponente, die nicht nur für K-Infinity verwendet werden kann. Daher kennt der Server keinerlei benutzerspezifische Berechtigungen. Dennoch ist es möglich, den Server so einzurichten, dass sich nur authentifizierte Anwender anmelden können und diese dann nur die Operationen ausführen dürfen, zu denen sie autorisiert sind.
Jede Anwendung (Client und Server) enthält ein RSA-Schlüsselpaar, das je ausgelieferter Anwendung eindeutig ist. Den öffentlichen Schlüssel kann man über die Information erhalten (KB: Menü „Werkzeuge“, „Info“, dann die Schaltfläche „RSA-Key kopieren“) bzw. für Konsolen-Anwendungen per Aufruf mit dem Parameter -showBuildID. Die hierdurch exportierte Build-Information enthält den öffentlichen RSA-Exponenten (rsa.e_1) und RSA-Modul (aufgeteilt auf mehrere rsa.n_x) sowie eine MD5 Prüfsumme dieser Informationen (buildID).
Beispiel einer Build-Information:
[buildID.90A1203EFB957A58C2268AD8FE3CC5A3] rsa.n_1=93D516DF61395258AA21A91B33E8EE67 rsa.n_2=B07C6FC5023DBB18F2201CF723C8F5DD rsa.n_3=78941FB7C10D20988FEDFC6BD02CF3B7 rsa.n_4=E4567751843C38F055ED791AA7505278 rsa.n_5=23D94BB9EAB2E23F21DBEAA3DD2D2776 rsa.n_6=CE8B81564645DA85C85E9A78BB6E6B41 rsa.n_7=28A646D4868C38E00AE4810601B1EE9F rsa.n_8=4FF5C35F873E6ED4F65F0FE8B4B45307 rsa.e_1=010001
Möchte man nun, dass sich nur eine bestimmte Menge Client-Anwendungen mit dem Server verbinden kann, so muss man im Server die jeweiligen Abschnitte in die mediator.ini übertragen. Beim Verbindungsaufbau überträgt der Client seine buildID. Wenn der Mediator einen passenden Eintrag enthält, so wird er die Client-Authentizität prüfen. Andernfalls wird er eine Verbindung nur aufbauen, wenn es gar keine Einträge zu Build-Informationen in seiner Ini-Datei gibt. Somit kann beispielsweise verhindert werden, dass sich veraltete Client-Anwendungen oder modifizierte Client-Anwendungen mit dem Mediator verbinden.
Umgekehrt können auch in der Client-Anwendung entsprechende buildIDs für die Mediatoren in die jeweilige ini-Datei eingetragen werden, um eine Verbindung zu einem kompromittierten oder veralteten Server zu verhindern.
So kann man zum Beispiel eine Umgebung einrichten, in der nur mit der aktuellsten Software auf die Produktivdaten zugegriffen werden kann, aber auf die Server mit den Testdaten auch von einer Entwicklungsumgebung aus. Die Anwendersoftware wiederum kann nur auf den Produktivserver oder auf den Testserver zugreifen.
Konfiguriert man weder Server noch Client, so verhält sich die Installation wie in den Vorgängerversionen: Jede Anwendung kann sich mit jedem Server verbinden (sofern die Protokollversion übereinstimmt).
Seit der Version 5.4 des Servers benötigt man zum Durchführen administrativer Befehle das Server-Passwort als Parameter (als Kommando-Zeilen-Parameter oder über die Verwaltung per Administrationswerkzeug). Damit nicht alle Administratoren Kenntnis dieses Passwortes haben müssen, kann einzelnen Benutzern mit Admin-Recht für einzelne Operationen das Passwort zugewiesen werden. Die jeweilige Operation kann der Anwender dann nach erfolgreicher Anmeldung im Admin-Tool ohne Eingabe des Server-Passwortes ausführen.
In einigen Anwendungsszenarien kann es gefordert sein, alle Zugriffe auf ein Wissensnetz in einem Zugriffs- oder Audit-Log zu protokollieren. Dieses Audit-Log enthält Einträge für alle An- und Abmeldevorgänge, schreibende und lesende Zugriffe auf Wissensnetz-Inhalte, gestellte Suchanfragen, Ausdrucke, Exporte etc.
Damit das Zugriffslog aktiviert werden kann, muss eine Konfigurationsdatei 'log.ini' im Verzeichnis des zu überwachenden Wissensnetzes angelegt werden:
[Default] applicationLog=CoastJSONApplicationLogger [CoastJSONApplicationLogger] filename=zugriffslog.json backupInterval=14
Zusätzlich muss das Log im Admin-Tool in der Rubrik 'Systemkonfiguration / Audit-Log' aktiviert werden. Die Aktivierung bzw. Deaktivierung des Logs resultiert wiederum in einem Eintrag im Audit-Log.
Für die Auswertung der Zugriffslogs steht Administratoren eine Funktion im Administrations-Menue des Knowledge-Builders zur Verfügung.
Der K-Infinity Server lässt sich manuell durch Aufruf mit dem Parameter -stop beenden. Bei der Installation als Windows-Dienst muss der Server mit der Diensteverwaltung gestoppt werden.
Unter UNIX sowie beim Betrieb als Windows-Dienst, wird der Server beim Herunterfahren des Betriebssystems ordnungsgemäß beendet.
Zum Ausführen dieses Befehls muss mittels Parameter -password das richtige Serverpasswort übermittelt werden.
Verzeichnisstruktur
Das Basisverzeichnis des K-Infinity-Servers weist folgende Struktur auf:
volumes/
wissensnetzName/
wissensnetzName.cbf
wissensnetzName.cdr
wissensnetzName.cfl
wissensnetzName.lock (wenn das Wissensnetz geöffnet ist)
backup/
wissensnetzName/
<zehnstellige Nummer>/
wissensnetzName.cbf
wissensnetzName.cdr
wissensnetzName.cfl
Speicherung von Wissensnetzen
Wissensnetze werden im Dateisystem im Unterverzeichnis "volumes" des Basisverzeichnisses des K-Infinity-Servers abgelegt. In diesem Verzeichnis wird für jedes Wissensnetz ein Unterverzeichnis mit entsprechendem Namen angelegt. Eine Datei mit der Dateiendung '.lock' zeigt an, dass ein Wissensnetz gerade in Verwendung ist.
Backup von Wissensnetzen
Die Wissensnetzverzeichnisse dürfen auf keinen Fall direkt kopiert werden, so lange der K-Infinity-Server läuft. Zu diesem Zweck besitzt der Server einen Backup-Service, der einen konsistenten Stand des Wissensnetzes in einen Backup-Bereich kopiert. Dieser Backup-Bereich muss in regelmäßigen Abständen gesichert werden (z.B. im Rahmen einer allgemeinen Backup-Strategie).
Der Ort, an dem die Backups angelegt werden kann über den Eintrag
backupDirectory=<Verzeichnis>
in der Datei "mediator.ini" festgelegt werden. Ohne diese Angabe wird das Unterverzeichnis "backup" des Basisverzeichnisses verwendet.
Der Backup-Service des K-Infinity-Servers kann auf zwei Arten angestoßen werden:
;Uhrzeit, zu dem das Backup gestartet wird backupTime=00:45 ;Turnus in Tagen – hier täglich backupInterval=1 ;Wird dieser Parameter angegeben, so werden nur die letzten 5 Backups dieses Wissensnetzes im Archiv aufgehoben backupsToKeep=5
Der Eintrag 'backupInterval' ist optional.
Ohne Garbage Collection wächst das Wissensnetz kontinuierlich mit der der Verwendung. Folglich ist es sinnvoll, von Zeit zu Zeit eine Bereinigung (Garbage Collection) durchzuführen. Wie die Datensicherung kann die Garbage Collection jederzeit manuell (z.B. mit einem speziellen Administrationswerkzeug) oder automatisch gestartet werden.
Die Garbage Collection kann – je nach Netzgröße – viel Zeit und Arbeitsspeicher in Anspruch nehmen. Bei der Durchführung auf großen Netzen empfiehlt es die Garbage Collection ohne verbundene Clients (z.B. KBuilder und JobClients) und ohne weitere aktive Prozesse (z.B. Backup) zu starten.
Automatische Garbage Collection: Aufbau der Datei jobs.ini
Die automatische Garbage Collection wird durch einen Eintrag in der Datei 'jobs.ini' konfiguriert, z.B.
[volume1] garbageCollectTime=00:55 garbageCollectInterval=7
Dieser Eintrag in der jobs.ini sorgt dafür, dass das Netz mit Namen "volume1" im Abstand von "7" Tagen jeweils um "00:55" Uhr garbage-collected wird. Für das Intervall ist der Standardwert "1" (also täglich), der Zeitpunkt muss angegeben werden.
Bei der Angabe der Netznamen in eckigen Klammern ist die Verwendung der Platzhalter "*" und "?" erlaubt, Groß- und Kleinschrift wird ignoriert.
Manueller Start der Garbage Collection
Alternativ kann die Garbage Collection auch durch spezielle Aufrufparameter des K-Infinity-Servers gesteuert werden:
-startGC <volume> -host <hostname> | Startet die Garbage Collection auf dem Netz mit Namen <volume> auf einen ggfs. entfernten Mediator auf Rechner <hostname> (optional inkl. Portangabe). |
-stopGC <volume> -host <hostname> | beendet eine ggfs. auf dem Mediator <hostname> laufende Garbage-Collection des Netzes mit dem Namen <volume>. |
-infoGC <volume> -host <hostname> | Informiert über den aktuellen Stand der Garbage Collection. |
Diese Kommandos werden mit Hilfe eines Mediator-Executables an einen anderen bereits laufenden Mediator übermittelt.
Als weitere Möglichkeit bietet sich das Starten der Garbage Collection über das Admin-Tool an.
Zum Ausführen dieser Befehle muss mittels Parameter -password das richtige Serverpasswort übermittelt werden.
Unter UNIX reagiert der Server auf folgende Signale:
SIGTERM/SIGHUP
Beendet den Server
SIGUSR2
Der Server startet einen sofortigen Backup aller Wissensnetze, die in der jobs.ini-Datei für Backup spezifiziert sind (siehe auch Abschnitt über Backup).
Der Mediator kann in einem Cluster betrieben werden. In einer Cluster-Umgebung wird i.d.R. eine laufende Spiegelung der Verzeichnisse und damit des Wissensnetzes vorgenommen. Fällt der Teil des Clusters, auf dem der Mediator läuft aus, wird automatisch ein neuer Mediator gestartet, der dann den Zugriff auf das Wissensnetz verwaltet.
Bei Ausfall des ersten Mediators kann es passieren, dass der Mediator keine Zeit mehr hat, das Wissensnetz in einen konsistenten Zustand zu bringen, das Netz damit eine Inkonsistenz aufweist und die "lock"-Datei des alten Mediators noch im entsprechenden Verzeichnis bestehen bleibt. Damit der neue Mediator in der Lage ist, die "lock"-Datei zu löschen, muss folgender Parameter in die mediator.ini hinzugefügt werden.
host=NameDesClusters
In diesem Fall können alle Mediatoren mit diesem ini-Eintrag auch gesperrte Volumes anderer Mediatoren, die beim Start den selben Wert in der mediator.ini ausgelesen hatten, entsperren. "NameDesClusters" ist frei wählbar, muss aber den Regeln entsprechen, die für Hostnamen gelten (keine Leerzeichen, Doppelpunkte, o.ä.)
Eine Konsistenzprüfung des Volumes läuft beim Starten des Mediators automatisch ab. Soweit möglich, wird das Wissensnetz in einen konsistenten Zustand versetzt und der Betrieb läuft normal weiter.
Falls der K-Infinity-Server während des Betriebs nicht ordnungsgemäß heruntergefahren wurde (z.B. Absturz des Rechners), bleiben bei geöffneten Wissensnetzen die Sperren bestehen. Beim Öffnen eines gesperrten Wissensnetzes wird diese Sperre erkannt und – falls möglich – entfernt.
Falls der Mediator eine Inkonsistenz erkennt, kann in der Kommandozeile durch den Aufruf des Mediators mit den Parametern -quickRecover / -recover das Wissensnetz geprüft und Inkonsistenzen soweit möglich repariert werden.
Sollte eine Auflösung der Inkonsistenzen wider Erwarten nicht möglich sein, muss auf eine Sicherungskopie zurückgegriffen werden.
Mögliche Kommandos für das BlockFileSystem sind:
copyto {target volume}
Ein Volume wird umkopiert. Das neue Volume darf noch nicht existieren. Bei diesem Vorgang werden die Blöcke umstrukturiert, wodurch der Vorgang länger als eine reine Dateikopiervorgang dauert.
Zum Ausführen dieses Befehls muss mittels Parameter -password das richtige Serverpasswort übermittelt werden.
Die Bridge ermöglicht den externen Zugang zu Wissensnetzen auf drei Arten/Betriebsmodi:
Zusätzlich gibt es noch den Betriebsmodus "Lastverteiler für andere Bridges" (KLoadBalancer).
ACHTUNG: KMultiBridge und KEMBridge dürfen nicht gleichzeitig in einer Bridge aktiviert werden, weil diese sich gegenseitig behindern. Gleiches gilt für den Betrieb als KLoadBalancer, auch dieser sollte allein betrieben werden (siehe Kapitel KLoadBalancer).
Die Bridge und alle in ihr zu aktivierenden Zugänge lassen sich über eine ini-Datei konfigurieren. Einstellungen für die Zugänge sind dabei in Abschnitten gebündelt. Die wichtigsten dieser Parameter lassen sich aber auch über die Kommandozeile spezifizieren. Ist dies der Fall, so haben die Werte des Kommandozeilenaufrufs Vorrang vor denen in der ini-Datei. Die einzelnen Parameter werden nun erläutert.
Wird die Bridge ohne jegliche Parameter gestartet, so werden die erforderlichen Parameter aus der Ini-Datei bridge.ini gelesen und die Fehlermeldungen in die Datei bridge.log geschrieben.
Falls es zu einem Aufrufparameter auch einen Eintrag der Ini-Datei gibt, hat der der Aufrufparameter höhere Priorität.
-inifile <Dateiname>, -ini < Dateiname >
Name der Ini-Datei, die statt dem Standard-Ini-Datei verwendet wird. Standard ist bridge.ini
-host <hostname:port>, -hostname <hostname:port>
Name des Mediators, der als Datenserver fungiert. Dieser gilt für alle aktivierten Bridgeclients
-port |<ClientName> <portnumber>
Der Parameter –port ist eigentlich für jeden Klienten in der ini-Datei zu setzen. Will man dieses aber bereits in der Kommandozeile tun, so lassen sich die unterschiedlichen Klienten durch Voranstellen des Klientennamens vor die Portnummer spezifizieren. Die obige Zeile gilt für einen Klienten, entsprechend muss der Parameter –port wiederholt werden, sollen mehrere Klienten konfiguriert werden.
Beispiele für den Aufruf der Bridge:
bridge –host server01:30000 –port KEMBridge 4713 –port KEMStreamingBridge 4714 bridge –ini bridge2.ini –port KMultiBridge 3030
Kommandozeilen-Parameter für das Logging:
-nolog
Schaltet Logging ab
-loglevel <Integer>
Konfiguriert, welche Meldungen im Log erscheinen sollen:
-logfile <Dateiname>, -log <Dateiname>
Name der Log-Datei, die statt der Standard-Log-Datei verwendet wird. Dieser Parameter muss auf jeden Fall verändert werden, wenn mehrere Clients im selben Arbeitsverzeichnis gestartet werden sind.
-debug
Schaltet das Logging auf debug-mode
-log <logname>
Setzt die Logdatei auf <logname>.
-stop <hostname>
Ruft man die Bridge mit dem obigen Parameter auf, so wird die auf dem angegebenen Host laufende Bridge zum Beenden aufgefordert. Alle in ihr gestarteten Klienten werden heruntergefahren und die Bridge beendet.
Alle der folgenden Einträge befinden sich unterhalb des ini-Datei-Abschnitts [Default]. Die Einträge für die einzelnen Klienten schließen daran an. Durch das Einfügen klientenspezifischer Konfigurationsabschnitte wird zusätzlich definiert, welche Klienten in der zu konfigurierenden und zu startenden Bridge aktiviert sind. Im Moment mögliche Klienten sind dabei:
Zusätzlich kann noch der KLoadBalancer als Klient der Bridge gestartet werden, dann enthält die ini-Datei nur den Abschnitt
host = <hostname:portnumber>
siehe Kommandozeilenparameter -host
Logging-Einstellungen:
loglevel = <Integer>
Konfiguriert, welche Meldungen im Log erscheinen sollen:
debug = true/false
Setzt den Log-Level bei true auf 0, bei false auf 10
channels = <Channel1> [,<Channel2>,...]
Namen von Channelfiltern. Mit Hilfe der Channelfilter werden nur Log-Meldungen ausgegeben, die zu den angegebenen Channelfiltern gehören. Der Name eines Channelfilters deutet darauf hin, zu welchem Themengebiet die Log-Ausgaben gehören. Welche Channelfilter möglich sind, erfährt man in der Kommandozeile mit Hilfe des Parameters -availableChannels.
logfile = <Dateiname>
Name der Log-Datei, die statt der Standard-Log-Datei verwendet wird.
maxLogSize = <size>
die maximale Größe des Logfiles, ab der die alte Logdatei archiviert wird und eine neue angebrochen wird. Bei Werten kleiner als 1024 wird die Angabe als in MB verstanden
notifiers = <Name1> [,<Name2>,...]
Namen von Notifiern. Ein Notifier wird bei Log-Ausgaben ab einem bestimmten Level aktiviert (typischerweise bei Fehlermeldungen). Siehe Abschnitt „Notifier“.
logprefix = <Prefix1> [, <Prefix2>,... ]
Zusätzliche Daten, die bei jeder Log-Ausgabe hinzugefügt werden
Bei einem Präfix, der nicht in dieser Liste enthalten ist, wird der Präfix unverändert ausgegeben
Speicher-Einstellungen:
Die folgenden drei Parameter dienen zur Konfiguration der Speicherzuteilung und -nutzung. Erlaubt ist die Angabe von Werten entweder in Megabyte oder in tatsächlichen Byte, wobei die Annahme gilt, dass sich Werte kleiner als 1048576 auf Megabyte-Angaben beziehen.
maxMemory=<Integer, in MB>
Maximal erlaubte Hauptspeicherbelegung. Minimal 50 MB, standardmäßig gesamter physikalisch vorhandener Hauptspeicher (unter Windows) bzw. 512 MB.
growthRegimeUpperBound=<Integer, in MB>
Hauptspeicherbelegung ab der verstärkt versucht wird, Speicher freizugeben. Standardmäßig 0.6 * maxMemory.
freeMemoryBound=<Integer, in MB> [10]
Falls belegter, aber nicht mehr benötigter Speicher diese Grenze überschreitet, wird er wieder freigegeben.
minAge=<Integer> [30]
Mindestdauer (in Sekunden), die ein Cluster im Speicher bleibt. Ein Cluster ist eine Menge von Objekten, die immer zusammen am Stück geladen werden (z.B. ein Individuum mit all seinen (Meta)eigenschaften. Cluster, die längere Zeit nicht mehr verwendet werden, werden bei Bedarf ausgelagert.
unloadInterval=<Integer> [10]
Mindestdauer (in Sekunden) zwischen zwei Cluster-Auslagerungen
unloadSize=<Integer> [4000]
Mindestanzahl an geladenen Cluster, ab der ausgelagert wird
keepSize=<Integer> [3500]
Zahl der Cluster, die beim Auslagern behalten werden
useProxyValueHolder=true/false
Um den Mediator bei Suchen zu entlasten, kann die Option useProxyValueHolder=false verwendet werden. Der Client lädt dann Indizes in den Hauptspeicher, statt per RPCs den Mediator abzufragen.Der Nachteil dieser Option ist, dass dann nur noch lesender Zugriff möglich ist.
loadIndexes=true/false
Über diese Option werden Indizes ebenfalls in den Speicher geladen. Es ist aber auch weiterhin schreibender Zugriff möglich. Die Option kann bei allen Clients inkl. Knowledge-Builder aktiviert werden.
Mail-Notifier Einstellungen:
Log-Ausgaben können über Mail-Notifier zusätzlich zum Eintrag in die Log-Datei per Mail versendet werden. Sinnvollerweise wählt man einen nicht zu geringen Schwellwert (Log-Level = 30), ab dem eine Mail versendet wird.
Für jeden angegebenen Namen aus der Notifier-Liste muss eine Konfiguration angegeben werden, die im Abschnitt [Name] angegeben wird.
Folgende Angaben sind für alle Notifier gleich:
Spezifische Angaben für COAST.CoastMailNotifier;
TLS/SSL ist für Authentifizierung nicht zwingend erforderlich, aber dringend zu empfehlen. Die Kompatibilitätserweiterung STARTTLS wird nicht unterstützt.
Beispiel:
notifiers = errorMailNotifier [errorMailNotifier] class = COAST.CoastMailNotifier level = 30 ;Spezifische Angaben für Mail-Versand attachLog = true sender = sender@hostname.de recipient = receiver@hostname.de smtpHost = mailserver.hostname.de retries = 3 retryDelay = 30
Die angegebene Konfiguration definiert einen Mail-Notifier, die alle Fehlermeldungen per Mail verschickt.
Die REST-Bridge Application ermöglicht den lesenden und schreibenden Zugriff auf K-Infinity über eine RESTful Services-Architektur. Die Schnittstelle steht als HTTP- oder HTTPS-Version zur Verfügung.
Die REST-Bridge läuft innerhalb der Standard-Bridge von k-infinity (bridge.exe).
Die Schnittstelle wird vollständig durch Konfigurations-Individuen im Wissensnetz konfiguriert. Der Rückgabewert eines REST-Aufrufes ist eine beliebige Zeichenkette, in der Regel in einem Format, das der aufrufende Client gut weiterverarbeiten kann (z.B. XML oder JSON).
Durch das Hinzufügen der Softwarekomponente "KRestServiceComponent" im Admin-Tool wird im Wissensnetz das benötigte Schema angelegt.
Das Schema wird in einem Teilnetz des Wissensnetzes namens "Servicekonfiguration" angelegt:
Die REST-Schnittstelle wird durch die Standard-Bridge-Komponente von K-Infinity bereitgestellt, sofern in der zugehörigen Konfigurationsdatei bridge.ini eine Kategorie KHTTPRestBridge bzw. KHTTPSRestBridge eingetragen ist:
[KHTTPRestBridge] volume=name des Wissensnetzes port=port, unter dem der Service erreichbar sein soll, default ist 8815 services=Liste von Service-IDs
Für die HTTPS-Version müssen in den Konfiguirationsdatei zusätzlich die Dateipfade für Zertifikat und Private Key angegeben werden:
[KHTTPSRestBridge] volume=name des Wissensnetzes port=port, unter dem der Service erreichbar sein soll, default ist 8815 services=Liste von Service-IDs certificate=Name der .crt-Datei privateKey=Name der .key-Datei
In der Konfigurationssektion "KHTTPRestBridge" oder "KHTTPSRestBridge" können außerdem noch die folgenden speziellen Konfigurationsoptionen eingetragen werden:
Name | Beschreibung |
realm | Name, der bei aktivierter Authentifizierung als Realm-Name an den Client zurückgegeben wird. Web-Browser zeigen den Realm-Namen typischerweise in Dialogfenstern zur Authentifizierung als Applikationsnamen an, damit der Benutzer weiß, wer die Authentifizierung fordert. Standardwert: REST |
Zunächst muss eine neue Service-Instanz angelegt werden. Sie haben die Möglichkeit mehrere Service-Instanzen zu konfigurieren, die von unterschiedlichen KService-Applikationen angesprochen werden. Erzeugen Sie dazu ein neues Individuum vom Typ "KService".
An dieser Instanz muss ein frei wählbarer Name und die serviceId vergeben werden. Die serviceId muss dem serviceIdentifier in der kservice.properties entsprechen. Haben Sie diesen nicht geändert, ist der Defaultwert "KService".
Diese Instanz dient als Einstiegspunkt für die Webapplikation. Alle Restlets, die unter dieser Service-Instanz verfügbar sein sollen, müssen auch über die Relation "uses restlet" zugeordnet werden!
Reinitialisieren des Services
In diesem Abschnitt wird beschrieben, wie eine Reinitialisierung des Services durchgeführt werden kann, ohne die Bridge neu starten zu müssen.
Dieser Vorgang wird in zwei Schritte durchgeführt:
Anmerkung: Sind mehrere Bridges für denselben Service konfiguriert, muss der obige Vorgang für jede Bridge einzeln wiederholt werden.
Restlets allgemein
Jede Methode, die Bestandteil der Service-API ist, wird durch ein eigenes Restlet-Individuum repräsentiert. Das Restlet wird durch einen frei definierbares Pfad-Muster adressiert. Hier sollten die allgemeinen Regeln für RESTful Services eingehalten werden. Im Pfad-Muster können in geschweiften Klammern variable Teile spezifiziert werden, die vom Restlet ausgewertet werden kann.
Beispiel:
echo/{message}
Variablen
Im Path-Pattern können Variablen definiert werden. Diese werden in geschweiften Klammern geschrieben. Diese Variablen sind required und somit fester Bestandteil des Path-Patterns. Optionale Variablen werden im QueryString übergeben.
Beispiel:
Pattern: http://servername:8080/api/customer/{customerID}/address
Aufruf: http://servername:8080/api/customer/C4317/address?show=private
customerID ist eine required Variable. Für die Verarbeitung des Aufrufs, wird die Variable customerID mit dem Wert "C4317" befüllt. Die definierte Logik kann so den passenden Datensatz selektieren.
show ist eine optionale Variable. Sie kann, muss beim Aufruf aber nicht angegeben werden. In diesem Beispiel würde das Restlet die Variable abfragen. Wenn sie gesetzt ist, wird nur die Private Adresse geliefert. Fehlt die Angabe, werden alle Adressen geliefert.
Vordefinierte Variablen
Zusätzlich zu den Variablen, die im Path-Pattern oder durch den Aufruf (z.B. im Body) angegeben werden, werden Variablen automatisch vom System gesetzt bzw. befüllt.
requestBody
Mit der Variablen requestBody kann auf den Inhalt des Bodys eines Requests zugegriffen werden.
Beispielaufruf zur Kontrollausgabe:
<Script> <If test="var(requestBody)/size() > 0"> <do> <Output><path path="var(requestBody)"/></Output> </do> <else> <Output>Kein Body vorhanden</Output> </else> </If> </Script>
requestHeader
In der Variablen requestHeader ist ein Dictionary enthalten, welches die Headereinträge des HTTP-Requestes enthält.
Mit Hilfe der Funktionen groupKey und groupValue kann auf die Inhalte zugegriffen werden.
Beispielaufruf zur Kontrollausgabe:
<XMLElement name="RequestHeader"> <Path path="var(requestHeader)"> <Each> <XMLElement name="HTTPHeader"> <XMLAttribute name="name"><path path="groupKey()"/></XMLAttribute> <If test="groupValue()/size() = 1"> <do> <path path="."/> </do> <else> <Path path="groupValue()"> <Each> <XMLElement name="Value"> <path path="."/> </XMLElement><cr/> </Each> </Path> </else> </If> </XMLElement> </Each> </Path> </XMLElement>
Ausschnitt des Results des Beispielaufrufes:
<RequestHeader> <HTTPHeader name="connection">keep-alive</HTTPHeader> <HTTPHeader name="accept-encoding">gzip,deflate</HTTPHeader> <HTTPHeader name="host">localhost:8818</HTTPHeader> <HTTPHeader name="accept-language"> <Value>de-de</Value> <Value>de;q=0.8</Value> <Value>en-us;q=0.5</Value> <Value>en;q=0.3</Value> </HTTPHeader> <HTTPHeader name="accept"> <Value>text/html</Value> <Value>application/xhtml+xml</Value> <Value>application/xml;q=0.9</Value> <Value>*/*;q=0.8</Value> </HTTPHeader> </RequestHeader>
Tipp: Für die Zerlegung eines GroupValues kann die Funktion AnalyzeString verwendet werden:
<AnalyzeString string="groupValue()" regex=","> <matchingSubstring/> <nonMatchingSubstring> <XMLElement name="value"> <path path="regexNonMatch()"/> </XMLElement><cr/> </nonMatchingSubstring> </AnalyzeString>
responseHeader
Die Variable responseHeader wird initial mit einem leeren Dictionary belegt. Somit ist diese Variable vorhanden und kann mit dem KPath-Ausdruck atKeyPut() befüllt werden.
<path path="var(responseHeader)/atKeyPut(einSchluessel, einWert)"/>
Wichtig: Der Schlüssel (key) muss eine Zeichenkette sein. Der Wert (value) darf eine Zeichenkette oder ein Ganzzahl sein, aber keine Menge.
httpStatusCode
Die Variable httpStatusCode kann auf eine beliebige Ganzzahl zwischen 100 und 599 gesetzt werden. Diese Variable wird dem HTTP-Response-Request als Statuscode gesetzt.
Operation
Zu den Regeln der RESTFul Services gehört die Unterscheidung der Operation durch die Art der Anfrage. Ein Http-GET-Request steht dabei für einen lesenden Zugriff. POST für eine modifikation, PUT für neu Erzeugen und DELETE für löschen.
Die Kservice-Applikation unterscheidet zwischen diesen Request-Typen und erlaubt bei GET-Request keine Modifikation der Daten! Wählen Sie deshalb bitte immer den passenden Request-Typ.
Report Restlet
Das Report-Restlet führt einen KSkript-Report aus und schickt die generierten Ausgabe als Antwort zurück. Alle Variablen aus dem Pfad-Muster und die URL-Queryparameter stehen im KSkript als Variablen zur Verfügung.
Beim ReportRestlet können folgende Eigenschaften konfiguriert werden:
Eigenschaft | Erforderlich | Beschreibung |
Path-Pattern | Ja | Pfad zum Restlet ab der Basis-URL. Variablen sind mit geschweiften Klammern zu versehen. Bsp: user/{userID}/details |
Report GET | Nein. Standard: GET liefert http 404 | Report, der bei einem GET-Request ausgeführt werden soll. |
Report POST | Nein. Standard: POST | Report der bei einem POST-Request ausgeführt werden soll. |
Report PUT | Nein. Standard: PUT | Report der bei einem PUT-Request ausgeführt werden soll. |
Report DELETE | Nein. Standard: DELETE liefert http 404 | Report der bei einem DELETE-Request ausgeführt werden soll. |
Response content type | Nein. Standard: text/plain | Content-Type des Response-Headers (z.B. text/html) |
Requires authenticaton | Nein. Standard: false | nein: Request ist offen zugänglich und läuft ohne Rechteprüfung ja: User muss sich (per http Basic authorization) authentifizieren, der Request wird mit den Zugriffsrechten dieses Users ausgewertet. |
Part of Service | Ja | Relation zur Service-Instanz, unter der das Restlet verfügbar sein soll |
Konfigurationsbeispiel
Blob Restlet
Das Blob-Restlet ermöglicht den Upload, Download und Löschen eines Blob-Attributes.
Beim Restlet lassen sich zwei Skript-Attribute anlegen, die folgende Objekte zurückliefern müssen.
Element | Upload | Download | Löschen | |
neu | bestehend | |||
Report to resolve attribute (rest.reportToResolveBlob) | Proto des neu anzulegenden Blob-Attributes | Existierendes Blob-Attribute, das verändert werden soll | Existierendes Blob-Attribute, das zurückgegeben werden soll | Existierendes Blob-Attribute, das gelöscht werden soll |
Report to resolve topic (rest.reportToResolveTopic) | Topic an dem das Blob-Attribut angelegt werden soll | - | - | - |
Beim Upload müssen im Body des HTTP-Requests folgende Parameter befüllt sein:
filename | Name bzw. Datei-Name des anzulegenden bzw. zu modifizierenden Blob-Attributes |
content | Binärdaten des Blobs |
Liste der Standardparameter:
Variable | Required | Beschreibung |
Path -Pattern | Ja | Pfad zum Restlet ab der Basis-URL. Variablen sind mit geschweiften Klammern zu versehen. Bsp: download/{blobID} |
Requires autheticaton | Default : false | Gibt an ob sich der User authentifizieren muss |
Execute as system user | Default: false | Ermöglicht den Download als Systemuser. |
Part of Service | Ja | Relation zur Service-Instanz, unter der das Restlet verfügbar sein soll |
Static File Restlet
Mit Hilfe des Static File Restlet können statische Dateien über den REST-Server ausgeliefert werden. Dieser Restlet-Typ kann z.B. genutzt werden, um einfache Anwendungen vollständig durch den REST-Server und ohne Verwendung eines weiteren Webservers zu bedienen.
Zur Konfiguration wird lediglich das Attribut 'Path-Pattern' benötigt, in dem der Name eines Verzeichnisses im Arbeitsverzeichnis der REST-Bridge angegeben wird. Die Dateien in diesem und in untergeordneten Verzeichnissen können dann über die URL
http://{server:port}/{service name}/{path pattern}/{relative file path}
abgerufen werden.
Referenzen auf K-Infinity Objekte
Wenn eine Referenz auf ein K-Infinity-Objekt in einer URL spezifiziert wird, werden folgende Formate berücksichtigt.
Beispiele:
ID135_71384 | Referenziert das Objekt mit der Objekt-ID "ID135_71384" |
Person | Referenziert den Typ mit dem internen Namen "Person" |
templateId~abc | Referenziert ein Objekt, dass ein Attribut mit dem internen Namen "templateId" und dem Attributwert "abc" hat. |
Content-Disposition
Über den Query-Parameter "content-disposition" eines Requests kann das Response-Header-Field "Content-Disposition" der zugehörigen "Response" gesetzt werden. Der Default-Wert ist ansonsten "inline".
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.
http://{server:port}/baseService/topicIcon/{topicID}?size=10
Objektliste
Über den folgenden Pfad kann eine Objektliste im JSON-Format angefordert werden:
http://{server:port}/baseService/{conceptLocator}/objectList
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.
Filter
Über den optionalen und mehrwertigen Query-Parameter "filter" kann die Objektliste gefiltert werden. Ein Filter hat zwei mögliche Formen:
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.
Sortierung
Ü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:
Stellt man in Variante 2 ein Minus vor, wird absteigend sortiert, sonst aufsteigend.
Startmenge der Liste setzen
Über den optionalen und 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".
Vererbung
Ü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: "ID850_337000250", row: ["CS", "Schuckmann", "Christian", "240", "c.schuckmann@i-views.de", "10", "", "", "IT-Cluster P4, IT-Cluster P5"] }, { topicID: "ID12068_152328826", row: ["", "Smith", "John", "", "", "", "", "", ""] }, { topicID: "ID2438_366678497", row: ["SY", "Stoye", "Sabine", "421", "s.stoye@i-views.de", "", "", "", "Knowledge-Portal 3, Presales, SemGoRiCo, Support (HSNR)"] }], columnDescriptions: [{ label: "Login", type: "string", columnId: "1" }, { label: "Nachname", type: "string", columnId: "2" }, { label: "Vorname", type: "string", columnId: "3" }, { label: "Telefon", 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" }] }
Objektlistendruckvorlage
Über den folgenden Pfad kann eine Objektliste in eine 'Druckvorlage für Liste' (siehe Kapitel 'Schema der Druckvorlagen) gefüllt und das Resultat heruntergeladen werden:
http://{server:port}/baseService/{conceptLocator}/objectList/printTemplate/{templateLocator}/{filename}
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:
http://{server:port}/baseService/{topicLocator}/printTemplate/{templateLocator}/{filename}
"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.
Dokumentformatkonvertierung
Über den folgenden Pfad kann ein Dokument in ein anderes Format umgewandelt werden (z.B. odt in pdf):
http://{server:port}/baseService/jodconverter/service
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"
KEMBridge
Abschnittsname:
[KEMBridge]
port = <portnumber>
Angabe des Ports, unter welchem die KEMBridge reagiert. Bei Nichtangabe gilt der Defaultwert von 4713.
ldapHost = <hostname:portnumber>
Angabe des LDAP-Hostes, welcher kontaktiert werden soll, für den Fall, dass die Authentifikation über LDAP stattfinden soll. Ist dieser Parameter angegeben, so muss die Authentifikation über LDAP abgewickelt werden.
maxLoginCount = <number>
Angabe der maximalen Fehlversuche beim Einloggen, bis der entsprechende Benutzer im Netz gesperrt wird. Danach ist ein Einloggen nur nach Entsperren per Knowledge-Builder möglich. Falls der Wert nicht gesetzt ist, ist ein fehlerhaftes Einloggen praktisch beliebig oft möglich.
Um ein Sperren des Benutzers im Wissensnetz zu ermöglichen, muss für Individuen des Personenkonzepts ein boolesches Attribut mit internem Namen ‚userlock’ und Defaultwert ‚false’ definiert sein.
KEMrestrictToIPAddress = <IP-Adresse>
Wenn dieser Parameter gesetzt ist, werden nur Verbindungen von dem hier angegebenen Host akzeptiert.
trustedLoginEnabled = <true/false>
Erlaubt ein Einloggen ohne Passwort mittels des Requests: „newAuthenticatedUser(username)“.
preventSessionReplay=<true/false>
[default=false]
Dieser Parameter gibt an, dass jede schreibende Session ihren eigenen geschützten Wissensnetzzugriff erhält, so dass der sonst übliche Mechanismus, die Aktionen einer deaktivierten Session beim Reaktivieren erneut auszuführen, um den letzten aktuellen Editorstand zu erhalten, unnötig wird.
KEMStreamingBridge
Abschnittsname:
[KEMStreamingBridge]
port = <portnumber>
Angabe des Ports, unter welchem die KEMStreamingBridge reagiert. Bei Nichtangabe gilt der Defaultwert von 4714.
Der KLoadBalancer kann eingesetzt werden, um die Services und Verfügbarkeit der KEMBridge und KEMStreamingBridge zu skalieren.
Im Abschnitt [KLoadBalancer] können/müssen die folgenden Angaben gemacht werden, um den gewünschten Betriebsmodus zu erreichen:
Der Parameter #configNames dient der weiteren Konfiguration der zu startenden KEMBridges und KEMStreamingBridges, je Einzel-Konfiguration wird ein Bridge-Typ gesteuert. Die Konfigurationsnamen sind durch Komma zu trennen.
Hier ein Beispiel für eine KLoadBalancer-ini-Datei:
[Default] [KLoadBalancer] hostname=ws01 port=30003 directory=C:\3.2\balancing executable=bridge.exe ;vm=visual ;image=bridge.im configNames=KEM,Streaming [KEM] bridgeClientClassName=KInfinity.KEMBridge inifile=kembridge.ini bridgeLogfile=kem-<id>.log maxBridges=2 [Streaming] bridgeClientClassName=KInfinity.KEMStreamingBridge inifile=streaming.ini bridgeLogfile=streaming-<id>.log maxBridges=2
Beim Start werden gemäß der beiden Konfigurationen KEMBridges und KEMStreamingBridges gestartet. Da zum Betrieb dieselbe Software wie für den Betrieb des KLoadBalancers verwendet wird, sind in diesem Abschnitt die Angabe der Parameter #executable, #image und #vm (für Linux-Betrieb), #hostname, #directory und #parameters nötig.
executable / image, vm; directory: Angaben, wie die einzelnen Bridges gestartet werden können. Unter Windows wird die Angabe von #executable und #directory benötigt, unter Linux die Angabe von #image, #vm und #directory.
hostname / port: Der Hostname, der den zu startenden Bridges als für Verwaltungszwecke zu kontaktierender KLoadBalancer genannt wird. Falls hier keine Angabe gemacht wird, wird der Rechnername ermittelt und dieser verwendet. Der Port gibt an, unter welchem Port die Bridges den Balancer ansprechen, Default-Wert ist 4715.
Vorsicht: Der Name des jeweiligen Mediators, den die Bridges zum Abrufen von Daten kontaktieren, ist in den jeweiligen ini-Dateien gemäß Konfigurationsabschnitt einzutragen!
parameters: Ein Feld, mit dem zusätzliche Angaben in die Kommandozeile der zu startenden Bridges eingefügt werden können, ist für alle zu startenden Bridges gleich.
allowRemoteShutdown: Parameter, der angibt, ob der KLoadBalancer per shutdown-Request per remote-Zugriff zu beenden ist.
autoRestart: Parameter, der angibt, ob eine gestoppte KEMBridge nach dem shutdown erneut zu starten ist, mit neuer ID.
In jedem Konfigurationsabschnitt müssen zusätzliche Angaben gemacht werden:
Zur Beachtung: Der Parameter #directory gibt das Arbeitsverzeichnis an, in dem die in den Konfigurationsabschnitten angegebenen Dateien gesucht und ggfs. angelegt werden. Software und ini-Datei für den Start des KLoadBalancers können sich an anderer Stelle befinden.
Die ini-Dateien der jeweiligen Bridges müssen wie gewohnt aufgebaut werden. Ein Beispiel für die im obigen Konfigurationsabschnitt KEM referenzierte ini-Datei ist hier angefügt:
[Default] host=mediator-hostname:30053 [KEMBridge] trustedLoginEnabled=true preventSessionReplay=true sslEnabled=true timeout=10
Für Details sei auf Kapitel 5 "Konfigurationsdatei bridge.ini" verwiesen.
Der Job-Client erbringt zum einen Dienste für andere K-Infinity-Clients, um diese von rechenzeit- oder datenintensiven Aufgaben zu entlasten. Zum anderen dient er als Brücke zwischen K-Infinity-Clients und externen Systemen.
Zu seinen wichtigsten Aufgaben gehört die Ausführung aller Arten von Suchen sowie die Auslieferung der Suchergebnisse an die Clients (Sortierung, textuelle Aufbereitung, Rechtefilterung).
Im Normalfall wartet der Client auf die Fertigstellung eines Auftrags (Synchronbetrieb).
Für die Ausführung komplexer Suchen, das Erstellen von Statistiken, Batch-Abgleiche, Datenaufbereitungen, Datenbereinigungen, etc. muss der Client nicht auf die Fertigstellung warten (Asynchronbetrieb). Das Ergebnis wird vom Service bereitgestellt und der Client wird benachrichtigt. Das Ergebnis kann dann beliebige Zeit später eingesehen werden. Da das Ergebnis auch persistent gemacht wird, ist es auch nach einem Neustart des Systems bzw. im Falle eines Fail-Overs weiterhin verfügbar.
Funktionsweise:
In dem vom K-Infinity-Mediator bereitgestellten geteilten Objektraum werden die Aufträge der Clients an die Services in sogenannten Pools abgelegt. Alle K-Infinity Job-Clients werden über neue Aufträge notifiziert und bewerben sich – sofern sie aktuell frei sind – für die Bearbeitung des neuen Auftrags. Nach Bearbeitung des Auftrags wird das Resultat wieder im geteilten Objektraum bereitgestellt, der beauftragende Client wird benachrichtigt und das Ergebnis kann abgerufen und zur Anzeige gebracht werden. Somit beauftragt der Client zwar logisch einen Job-Client, physikalisch läuft die Kommunikation aber immer über den K-Infinity Server. Für den Client ist es transparent, welcher Job-Client seinen Auftrag ausführt, sowie es für den Job-Client transparent ist, wo der Auftrag herkommt und wie viele parallele Job-Clients zurzeit aktiv sind. Für Administratoren ist die Installation und Wartung der Job-Clients daher sehr einfach und flexibel. Job-Clients lassen sich beliebig skalieren, auf verschiedene Rechner verteilen und dynamisch zu- und abschalten. Eine externe Clusterung oder sonstige Orchestrierung ist nicht erforderlich.
Technische Daten:
Multi-Platform Executable auf Basis der VisualWorks Smalltalk Virtual Machine (jobclient.exe bzw. jobclient.im)
Benötigt eine TCP/IP-Verbindung zum K-Infinity Server
Automatische Lastverteilung zwischen den Services
Job-Clients können zu jeder Zeit zugeschaltet oder heruntergefahren werden
Standby-Modus bei zeitweiliger Nicht-Verfügbarkeit benötigter Ressourcen
Die Konfiguration des Job-Clients wird in der Ini-Datei vorgenommen. Falls nicht durch den Aufrufparameter "-inifile" spezifiziert wird "jobclient.ini" als Konfigurationsdatei verwendet.
host=<Hostname:Portnummer>
Name / IP-Adresse des Servers
volume=<Volumename>
Der Name des Wissensnetzes, auf dem gearbeitet werden soll.
jobPools=Jobname1 [,Jobname2, ...]
Angabe, welche Jobs der Job-Client abarbeiten soll. Die Namen der zu startenden Job-Pools sind hier kommagetrennt anzugeben. Alternativ kann auch die Kategorie (z.B. "index") angegeben werden. Es werden dann alle Job-Pools dieser Kategorie ausgewählt.
Beispiel:
jobPools=KScriptJob, query
Die möglichen Typen werden in den Unterkapiteln dargestellt.
cacheDir=<Verzeichns>
Beschreibung des Ortes, an dem der Cache für den Job-Client angelegt wird.
volumeAccessor=CatBSBlockFileVolumeAccessor oder CatCSVolumeFileStorageAccessor
Beschreibung der Speicherart des Caches. Wenn nicht angegeben wird CatBSBlockFileVolumeAccessor verwendet. Diese Speicherart ist vor allem bei großen Netzen zu empfehlen, da CatCSVolumeFileStorageAccessor eine große Anzahl an Dateien anlegen würde.
maxCacheSize=<Größe in MB>
Zielgröße des Caches
shutDownTimeout=<Sekunden>
Dauer, auf die beim Herunterfahren des Job-Clients auf die Beendigung der aktiven Jobs gewartet wird. Nach Ablauf werden die Jobs abgebrochen. Der Standardwert ist 10 Sekunden.
enableLowSpaceHandler=true/false
Mit dieser Option wird der LowSpaceHandler eingeschaltet. Dieser sollte auf jeden Fall bei großen Netzen eingeschaltet werden.
useProxyValueHolder=true/false
Mit dieser Option kann gesteuert werden, ob der Job-Client Indexzugriffe per RPC durchführt (true), oder Indizes in den Speicher lädt (false). Diese Option sollte ausgeschaltet werden, wenn der Mediator entlastet werden soll. Dabei sollte allerdings darauf geachtet werden, dass der Job-Client genug Speicher zur Verfügung hat. Falls der Job-Client für schreibende Jobs konfiguriert wurde, hat diese Option keinen Effekt, da dann der Indexzugriff immer per RPC durchgeführt wird. Es wird beim Start im Log eine Meldung ausgegeben, falls man den Wert auf false gesetzt hat.
loadIndexes=true/false
Seit 4.2 gibt es die neue Option loadIndexes=true. Indizes werden dann ebenfalls in den Speicher geladen. Im Gegensatz zur Option useProxyValueHolder ist aber auch weiterhin schreibender Zugriff möglich. Die Option kann bei allen Clients inkl. Knowledge-Builder aktiviert werden.
name=<Job-Client-Name>
Dieser Name wird verwendet, um den Job-Client im Admin-Tool in der Übersichtsliste aller Job-Clients zu identifizieren.
Logging-Einstellungen:
loglevel = <Integer>
Konfiguriert, welche Meldungen im Log erscheinen sollen:
debug = true/false
Setzt den Log-Level bei true auf 0, bei false auf 10
channels = <Channel1> [,<Channel2>,...]
Namen von Channelfiltern. Mit Hilfe der Channelfilter werden nur Log-Meldungen ausgegeben, die zu den angegebenen Channelfiltern gehören. Der Name eines Channelfilters deutet darauf hin, zu welchem Themengebiet die Log-Ausgaben gehören. Welche Channelfilter möglich sind, erfährt man in der Kommandozeile mit Hilfe des Parameters -availableChannels.
logfile = <Dateiname>
Name der Log-Datei, die statt der Standard-Log-Datei verwendet wird.
maxLogSize = <size>
die maximale Größe des Logfiles, ab der die alte Logdatei archiviert wird und eine neue angebrochen wird. Bei Werten kleiner als 1024 wird die Angabe als in MB verstanden
notifiers = <Name1> [,<Name2>,...]
Namen von Notifiern. Ein Notifier wird bei Log-Ausgaben ab einem bestimmten Level aktiviert (typischerweise bei Fehlermeldungen). Siehe Abschnitt „Mail-Notifier“.
logprefix = <Prefix1> [, <Prefix2>,... ]
Zusätzliche Daten, die bei jeder Log-Ausgabe hinzugefügt werden
Bei einem Präfix, der nicht in dieser Liste enthalten ist, wird der Präfix unverändert ausgegeben
Speicher-Einstellungen:
Die folgenden drei Parameter dienen zur Konfiguration der Speicherzuteilung und -nutzung. Erlaubt ist die Angabe von Werten entweder in Megabyte oder in tatsächlichen Byte, wobei die Annahme gilt, dass sich Werte kleiner als 1048576 auf Megabyte-Angaben beziehen.
maxMemory=<Integer, in MB>
Maximal erlaubte Hauptspeicherbelegung. Minimal 50 MB, standardmäßig gesamter physikalisch vorhandener Hauptspeicher (unter Windows) bzw. 512 MB.
growthRegimeUpperBound=<Integer, in MB>
Hauptspeicherbelegung ab der verstärkt versucht wird, Speicher freizugeben. Standardmäßig 0.6 * maxMemory.
freeMemoryBound=<Integer, in MB> [10]
Falls belegter, aber nicht mehr benötigter Speicher diese Grenze überschreitet, wird er wieder freigegeben.
minAge=<Integer> [30]
Mindestdauer (in Sekunden), die ein Cluster im Speicher bleibt. Ein Cluster ist eine Menge von Objekten, die immer zusammen am Stück geladen werden (z.B. ein Individuum mit all seinen (Meta)eigenschaften. Cluster, die längere Zeit nicht mehr verwendet werden, werden bei Bedarf ausgelagert.
unloadInterval=<Integer> [10]
Mindestdauer (in Sekunden) zwischen zwei Cluster-Auslagerungen
unloadSize=<Integer> [4000]
Mindestanzahl an geladenen Cluster, ab der ausgelagert wird
keepSize=<Integer> [3500]
Zahl der Cluster, die beim Auslagern behalten werden
Mail-Notifier Einstellungen:
Log-Ausgaben können über Mail-Notifier zusätzlich zum Eintrag in die Log-Datei per Mail versendet werden. Sinnvollerweise wählt man einen nicht zu geringen Schwellwert (Log-Level = 30), ab dem eine Mail versendet wird.
Für jeden angegebenen Namen aus der Notifier-Liste muss eine Konfiguration angegeben werden, die im Abschnitt [Name] angegeben wird.
Folgende Angaben sind für alle Notifier gleich:
Spezifische Angaben für COAST.CoastMailNotifier;
TLS/SSL ist für Authentifizierung nicht zwingend erforderlich, aber dringend zu empfehlen. Die Kompatibilitätserweiterung STARTTLS wird nicht unterstützt.
Beispiel:
notifiers = errorMailNotifier [errorMailNotifier] class = COAST.CoastMailNotifier level = 30 ;Spezifische Angaben für Mail-Versand attachLog = true sender = sender@hostname.de recipient = receiver@hostname.de smtpHost = mailserver.hostname.de retries = 3 retryDelay = 30
Die angegebene Konfiguration definiert einen Mail-Notifier, die alle Fehlermeldungen per Mail verschickt.
Lucene-Server-Konfiguration:
Die Einbindung von Lucene erfolgt über einen Job Client, dessen jobclient.ini-Datei dafür entsprechend konfiguriert werden muss. Nachfolgend eine Beispielkonfiguration:
[lucene] directory=/ext/k-infinity/4.2/lucene/index-data/index-fmg port=5100 hostname=mein-externer-hostname.com pageSize=1000 allowLeadingWildcards=true
Werden für den Jobpool die unten angezeigten Jobklassen oder index angegeben, dann werden die Indexierungsaufträge vom Job-Client ausgeführt. Die Indexierungsaufträge sollten nur von einem einzigen Job-Client durchgeführt werden. Statt alle Jobklassen einzeln im Job-Pool aufzuzählen, kann auch der symbolische Name index verwendet werden.
KAddAllToIndexJob
KLightweightIndexJob
Ein externer Index wird über den KLightweightIndexJob gepflegt.
KLuceneAdminJob
Der KLuceneIndexJob verwaltet einen extern aufgebauten Lucene-Index.
KRemoveIndexJob
KSyncIndexJob
KAddAllToIndexJob, KRemoveIndexJob und KSyncIndexJob werden benötigt, um die internen Indizes zu pflegen.
Der KBrainbotJob führt Aktionen zur Pflege eines Brainbot-Indexes aus.
Falls innerhalb der Konfiguration im Admin-Tool angegeben wird, dass Pflegeaktionen von einem Jobclient ausgeführt werden sollen ("Jobclient benutzen"), so muss ein Jobclient gestartet werden, damit die Pfege des externen Index ausgeführt wird.
Der KBrainbotJob hat keine weiteren Konfigurationsparameter in der ini-Datei, da die gesamte Konfiguration im Admin-Tool stattfindet.
Mit Hilfe des KExternalCommandJobs ist es möglich ausführbare Programme, die sich mit der Abarbeitung oder Veränderung von Dateien beschäftigen oder einfach nur aufgerufen werden sollen, anzusteuern. Eine Konfiguration in der INI-Datei des JobClients ist nicht notwendig. Der Job wird durch einen Skriptaufruf eingeworfen.
Das Hauptelement des Skriptaufrufes ist das Element ExternalCommandJob. Mit dem Attribut execution kann eingestellt werden, ob der Job lokal ohne JobClient (Wert: local) oder mit JobClient (Wert: remote) ausgeführt werden soll. Der Standardwert ist remote.
Anmerkung zur Remote-Ausführung:
Eine Kontrolle über den Zugriff auf lokale Programme findet über den Aufruf einer Batchdatei statt. Bevor sich der JobClient einen KExternalCommanJob zur Ausführung nimmt, überprüft er, ob er diesen Job ausführen kann. Das ist der Fall, wenn im aktuellen Verzeichnis des JobClients die Batchdatei vorhanden ist, die im Element Commandangegeben ist. Wird der aktuell anstehende Job von keinem JobClient zur Bearbeitung angenommen, ist die Job-Warteschlange für den Benutzer, der den Job eingeworfen hat, blockiert. Dieser Job muss von Hand gelöscht werden.
Das notwendige, erste Unterelement im Skript:
<Command>convert.bat</Command>
In dem Element Command wird der Name der Batchdatei angeben. In der Batchdatei ist das Verzeichnis und das auszuführende Programm selbst angegeben. Wichtig: Die Batchdatei muss auf der gleichen Ebene wie das Programm (z.B. JobClient oder KB) liegen. Verzeichnisangaben im Element Command werden ignoriert.
Die weiteren Unterelemente werden von oben nach unten abgearbeitet. Falls die Reihenfolge der Parameter im externen Programm eine Rolle spielt, sollte dies berücksichtigt werden.
Skriptelemente, die die Parameter für den Aufruf bilden:
<OptionString>-size 100x100</OptionString>
<OptionPath path="./topic()/concept()/@$size$"/>
Skriptelemente, die sich mit dem Handling von Attributen beschäftigen
<SourceBlob><Path path="$bild$"/></SourceBlob> <SourceBlob path="$bild$"/>
<ResultAttribute name="$bild2$" topic="./topic()" modifyExisting="true" filename="convert_ +./valueString()"/> <ResultAttribute name="$bild2$" topic="./topic()" modifyExisting="true" filename="convert_ +./valueString()"> <Path path="$bild2$"></ResultAttribute>
Beispiel 01:
Skript:
<Script> <ExternalCommandJob execution="local"> <Command>convert.bat</Command> <OptionString>-size 100x100</OptionString> <SourceBlob><Path path="."/></SourceBlob> <OptionString>-geometry +5+10</OptionString> <SourceBlob><Path path="."/></SourceBlob> <OptionString>-geometry +35+30</OptionString> <OptionString>-composite</OptionString> <ResultAttribute name="$bild2$" topic="./topic()" modifyExisting="true" filename="convert_ +./valueString()"/> </ExternalCommandJob> </Script>
Inhalt der Batchdatei unter Windows:
"C:\Program Files\ImageMagick-6.2.6-Q16\convert.exe" %*
exit /B %ERRORLEVEL%
Inhalt der Batchdatei unter Linux:
#!/bin/bash
convert $*
Beispiel 02:
Skript:
<Script> <ExternalCommandJob execution="local"> <Command>convert2.bat</Command> <SourceBlob path="."/> <SourceBlob path="."/> <ResultAttribute name="$bild3$" topic="./topic()" modifyExisting="true" filename="convert2_ + ./valueString()"/> </ExternalCommandJob> </Script>
Inhalt der Batchdatei unter Windows:
"C:\Program Files\ImageMagick-6.2.6-Q16\convert" -size 100x100 %1 -geometry +5+10 %2 -geometry +35+30 -composite %3 exit /B %ERRORLEVEL%
Inhalt der Batchdatei unter Linux:
#!/bin/bash convert -size 100x100 $1 -geometry +5+10 $2 -geometry +35+30 -composite $3
Anmerkung: Die beiden Beispiele liefern als Ergebnis die gleiche Datei. In den Windows-Batchfiles dient der Exit-Befehl dazu, den Exit-Code von "convert" an den Aufruf zurückzuliefern.
Hier noch ein Beispiel für ein erweitertes Konvertierungsskript, welches mit den Parametern "Quelldatei", "Bildbreite" und "Zieldate" aufgerufen werden kann und welches nur breitere Bilder auf die angegebene Breite verkleinert. Das Script schreibt außerdem eine Protokolldatei über die Konvertierung wobei auch Fehlermeldungen von Image Magick in die Logdatei geschrieben werden:
set MONTH_YEAR=%DATE:~-8% echo Converting %1 to %3 (width: %2) >> convert%MONTH_YEAR%.log convert.exe %1 -resize "%~2>" %3 2>> convert%MONTH_YEAR%.log echo Conversion finished with exit code %ERRORLEVEL% >> convert%MONTH_YEAR%.log exit /B %ERRORLEVEL%
Und hier noch die Version für Linux (Bash):
#!/bin/bash FULLDATE=`date +%c` MONTH_YEAR=`date +%m.%Y` LOGFILE="convert.$MONTH_YEAR.log" echo "$FULLDATE: Converting $1 to $3 (width: $2)">>$LOGFILE convert "$1" -resize "$2>" "$3" 2>>$LOGFILE EXITCODE="$?" echo $FULLDATE: Conversion finished with exit code $EXITCODE>>$LOGFILE exit $EXITCODE
Dient der ausgelagerten Ausführung von einfachen und Expertensuchen auf einem Jobclient. Wird je nach Bedürfnissen der betrachteten Suche ausgestattet und ausgeführt.
Mithilfe des KScriptJobs lassen sich KSkripte aus KSkript heraus so aufrufen, dass sie auf dem Job-Client ausgeführt werden. Dabei geschieht das Erzeugen des Jobs durch die KSkript-Regel "ScriptJob", welche ausgestattet mit Script und den zu diesem Zeitpunkt errechneten Startobjekten als Ausgangspunkt den resultierenden KScriptJob in die Job-Queue einstellt. So lassen sich Arbeiten asynchron auf Job-Clients verteilen. Anwendungsbeispiele sind die Auslagerung von Tätigkeiten, die bei sequenzieller Ausführung den aufrufenden Klienten zu lange blockieren würden.
volume=MeinNetz host=localhost jobPools=query, index cacheDir=jobcache logfile=jobclient01.log maxMemory=400 name=jobclient01
Vorab laden
Die JobClients können beim Hochfahren durch die Konfiguration auswählbare Strukturen vorab laden. Durch diesen Vorgang steigt der Speicherbedarf des JobClients. Im Gegenzug kann der JobClient Jobs schneller ausführen.
In die Ini-Datei des JobClients muss der Eintrag keepClusterIDs angegeben werden. Mögliche Werte für diesen Eintrag sind:
Wichtig: Für den Eintrag useProxyValueHolder muss der Wert false gesetzt sein. Sonst versucht der JobClient RPCs (Anfragen, die der Mediator beantworten kann) an den Mediator abzusetzen. Der Client soll jedoch die Cluster selber laden und unter Umständen auch im Speicher behalten.
Anmerkung: Es ist ebenfalls von Vorteil, für eine Performanceverbesserung den Festplattencache für den JobClient einzuschalten.
Beispiel für die Einträge in der INI-Datei:
[Default] ... useProxyValueHolder=false keepClusterIDs=index,protoOfSizes,accessRights cacheDir=jobcache maxCacheSize=1000 ...
Der Blob-Service dient der Datenhaltung von großen Dateien außerhalb des Wissensnetzes, aber verknüpft mit den Datei-Attributen, in denen diese Dateiinhalte abgelegt werden sollen. Dies hat mehrere Vorteile:
Im folgenden Kapitel wird das Einrichten und der Betrieb von Blob-Services erläutert.
Um festzulegen, unter welcher Netzwerk-Adresse (Host und Port) der Blobservice erreichbar sein soll, muss in der Datei "blobservice.ini" die Option "interfaces" eingetragen werden. Prinzipiell gibt es dabei zwei Möglichkeiten:
Hier ein Konfigurationsbeispiel für Variante 1, wobei der BLOB-Service-Port (30000) auch frei wählbar ist:
interfaces=http://localhost:30000
Zur Konfiguration von Variante 2 muss man anstelle von "localhost" die IP-Adresse des Netzwerk-Adapters eintragen, über den der BLOB-Service aus dem Netzwerk ansprechbar sein soll. Möchte man, dass der BLOB-Service über alle Netzwerk-Adapter erreichbar ist, die auf dem Rechner aktiv sind, so muss man als IP-Adresse "0.0.0.0" eintragen. Beispiel:
interfaces=http://0.0.0.0:30000
Wird der BLOB-Service über das Netzwerk angesprochen, so sollte die Kommunikation verschlüsselt werden. Die verschlüsselte Kommunikation über HTTPS kann ebenfalls in der Option "interfaces" konfiguriert werden, indem "http://" durch "https://" ersetzt wird. Beispiel:
interfaces=https://0.0.0.0:30000
Für den verschlüsselten Fall siehe auch das nachfolgende Kapitel SSL Zertifikate.
Um den Betrieb zu gewährleisten, muss zusätzlich im Arbeitsverzeichnis die DLL des SQLite Frameworks "sqlite3.dll" vorhanden sein. Ohne diese DLL kann die intern benötigte Verwaltungsstruktur nicht aufgebaut und gepflegt werden.
Danach kann der Blobservice gestartet werden und steht ab sofort zur Verfügung.
Um den Blobservice mit einem Blobstore in der semantischen Graph-Datenbank zu verknüpfen, bietet das Admin-Tool unter "Systemkonfiguration -> Blob-Speicherung" die nötigen Werkzeuge:
Durch Klicken auf "Anlegen" (1) wird eine neuer logischer Store erzeugt. Danach muss in das Eingabefeld "URL" (2) die in der ini-Datei angegebene URL des Blobservices eingetragen werden und dann auf "Hinzufügen" (3) geklickt werden. Der neu gebaute Blobstore für externe Haltung von Dateiattributen ist danach mit dem Blobservice verknüpft, was durch Klicken auf "Aktualisieren" (4) im unteren Darstellungsbereich kontrolliert werden kann.
Im Bereich "URLs" (2) kann auch eine Liste alternativer URLs per Komma getrennt angegeben werden. K-Infinity bevorzugt bei alternativen URLs wenn möglich eine Verbindung über Loopback-Device.
Der Bereich "Löschbare Dateien" (7) zeigt die Zahl der aus Sicht des Wissensnetzes nicht mehr benötigten Dateien an. Mit "Löschen" (8) werden diese im BlobService dereferenziert und ggf. entfernt.
Der Indikator "Intern" (9) zeigt an, dass es sich um einen in einen Mediator integrierten Store handelt. Interne Stores werden bei Volume-Transfers (upload, download, copy, backup, recover) automatisch mit dem Volume transferiert.
Will man die Verknüpfung eines Blobstores zu einem Blobservice aufheben, so selektiert man den gewünschten Blobstore in der Liste "Externe Speicher im Blob-Service" und klickt "Entfernen" (5). Danach kann man den Blobstore im oberen Bereich "Externe Speicher für Dateiattribute" selektieren und durch Klicken auf "Löschen" (6) ganz entfernen, oder man kann durch Angabe einer neuen URL den Blobstore mit einem anderen Blobservice wie oben beschrieben neu verknüpfen.
ACHTUNG!
Durch das Auflösen der Verknüpfung eines Blobstores zu einem Blobservice gehen alle dort gespeicherten Dateien verloren!
Zur Konfiguration der HTTPS-Verbindung müssen das Zertifikat und der Private-Key abgelegt werden.
Das Zertifikat muss unter certificates/server.crt liegen.
Der Private-Key muss unter private/server.key liegen. Es ist darauf zu achten, dass server.key als RSA-Key vorliegt, d.h. die erste Zeile der Datei muss
-----BEGIN RSA PRIVATE KEY-----
lauten. Wenn der Key in einem anderen Format vorliegt, muss er konvertiert werden. Mittels OpenSSL ist dies bspw. mittels "openssl rsa -in input.kez -out private/server.key -outform PEM" möglich.
Mit dem Admin-Tool können neue Wissensnetze angelegt, alle Wissensnetze eines Mediators verwaltet und einzelne Wissensnetze konfiguriert werden.
Nach dem Start des Admin-Tools (Windows: admin.exe, Mac OS: admin, Linux: admin-64.im) erscheint das Startfenster.
Im Freitextfeld Server wird der Name oder die IP-Adresse des Rechners angegeben, auf dem der Mediator läuft, über den auf die zu verwaltenden Wissensnetze zugegriffen 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 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. Wird beim Klicken auf ... parallel die Alt-Taste gedrückt, lassen sich Listeneinträge markieren und markierte Listeneinträge löschen.
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.
Ü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 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:
Ü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.
Neu leitet weiter zur Wissensnetzerzeugung.
Verwalten leitet weiter zur Gesamtnetzverwaltung.
Weiter leitet weiter zur Einzelnetzverwaltung.
Einzelheiten zur jeweils korrekten Konfiguration der Freitextfelder Server und Wissensnetz finden sich in den jeweiligen Kapiteln.
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.
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.
Im Freitextfeld Neues Wissensnetz wird der Name des Wissensnetzes festgelegt. Die Art der Menge der dafür erlaubten Zeichen wird über das Dateisystem des Betriebssystems vorgegeben, auf dem das Wissensnetz gespeichert werden soll. 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.
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.
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.
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.
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.
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.
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. Um von hier aus wieder zum Startfenster zurückzukehren, muss das Admin-Tool geschlossen und neu gestartet werden.
Die tabellarische Netzübersicht gibt Aufschluss über
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.
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.
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.
Beenden schließt das Admin-Tool.
Aktualisieren ermittelt die in der Netzübersicht im Gesamtnetzverwaltungsfenster erhobenen Daten neu.
Log herunterladen erzeugt eine Kopie der üblicherweise im Ordner des verbundenen Mediators liegenden Mediator-Protokolldatei (Standarddateiname: mediator.log). Name und Speicherort der Kopie können in einem Speicherdialog frei gewählt werden. In der Mediator-Protokolldatei wird ein Protokoll über alle Aktivitäten des Mediators seit seiner ersten Inbetriebnahme geführt.
Serververbindungen gibt im Nachrichtenfeld die Nummer und die IP-Adresse aller gegenwärtig über den verbundenen Mediator in Wissensnetzen angemeldeten Software-Komponenten (außer dem Blob-Service) aus und gruppiert diese nach Wissensnetzen. Die Nummer wird vom Mediator fortlaufend generiert und bei jeder Neuanmeldung einer Software-Komponente neu vergeben.
Volume herunterladen erzeugt eine Kopie des in der Netzübersicht ausgewählten Wissensnetzes und speichert sie lokal im relativ zur Position des Admin-Tools liegenden Unterordner volumes. In einem separat erscheinenden Freitextfeld kann ein neuer Name für diese Kopie vergeben werden.
Volume kopieren erzeugt eine Kopie des in der Netzübersicht ausgewählten Wissensnetzes und speichert sie im gleichen Ordner wie das Originalnetz. In einem separat erscheinenden Freitextfeld muss ein neuer Name für diese Kopie vergeben werden.
Volume hochladen erzeugt eine Kopie eines ausgewählten lokalen Wissensnetzes und speichert sie im relativ zum verbundenen Mediator liegenden Unterordner volumes. In einem separat erscheinenden Freitextfeld kann ein neuer Name für diese Kopie vergeben werden. Die Auswahl des lokalen Wissensnetzes, das im relativ zur Position des Admin-Tools liegenden Unterordner volumes abgelegt sein muss, erfolgt über ein separates Auswahlfenster.
Volume austauschen erzeugt eine Kopie eines ausgewählten lokalen Wissensnetzes und überschreibt damit das in der Netzübersicht ausgewählte Wissensnetz. Die Kopie erhält dabei den Namen des überschriebenen Wissensnetzes. Die Auswahl des lokalen Wissensnetzes, das im relativ zur Position des Admin-Tools liegenden Unterordner volumes abgelegt sein muss, erfolgt über ein separates Auswahlfenster.
In Folge der über Transfer-Operationen ausgelösten Kopierprozesse wird die Blockbelegung der Cluster und Blobs innerhalb der Wissensnetzkopien neu festgelegt und dabei deren Platzverbrauch optimiert. Der hierdurch bewirkte Komprimierungseffekt ist der gleiche wie über die Operation Verwalten -> Volume komprimieren.
Mit Ausnahme der Operation Volume kopieren setzen alle diese Operationen voraus, dass das Admin-Tool mit einem Mediator verbunden ist.
Backup erstellen erzeugt eine Sicherungskopie des in der Netzübersicht ausgewählten Wissensnetzes und speichert sie im relativ zur Position dieses Wissensnetzes liegenden Parallelordner backup. Für jede Sicherungskopie wird dort ein eigener Unterordner angelegt, in dessen Bezeichnung der Zeitpunkt der Kopieerstellung auf eine Sekunde genau eingearbeitet ist. Jede Sicherungskopie ist eine vollständige Kopie des Originalnetzes.
Vor Erzeugung der Sicherungskopie wird über ein eigenes Fenster erfragt, ob der Nutzer bis zum Abschluss des Kopiervorganges warten will. Gegebenenfalls wird bis zu diesem Zeitpunkt die weitere Nutzung des Admin-Tools blockiert. Andernfalls startet der Kopiervorgang im Hintergrund und eine Nachricht über den Fortgang des Kopiervorganges oder dessen Fertigstellung unterbleibt.
Backup wiederherstellen erzeugt eine Kopie einer ausgewählten Sicherungskopie und speichert sie im gleichen Ordner wie die in der Netzübersicht dargestellten Wissensnetze. In einem separat erscheinenden Freitextfeld muss ein neuer Name für diese Kopie vergeben werden. Die Auswahl der Sicherungskopie, die in einem Unterordner des Ordners backup abgelegt sein muss, der parallel zur Position der in der Netzübersicht dargestellten Wissensnetze liegt, erfolgt über zwei separate Auswahlfenster, in denen zuerst das Wissensnetz und danach die nach Erstellungszeiten sortierte Version ausgewählt werden.
Backup löschen löscht eine ausgewählte Sicherungskopie. Die Auswahl dieser Sicherungskopie, die in einem Unterordner des Ordners backup abgelegt sein muss, der parallel zur Position der in der Netzübersicht dargestellten Wissensnetze liegt, erfolgt über zwei separate Auswahlfenster, in denen zuerst das Wissensnetz und danach die nach Erstellungszeiten sortierte Version ausgewählt werden.
Die Blockbelegung der Cluster und Blobs innerhalb des Originalwissensnetzes wird bei der Erstellung einer Wissensnetzkopie nicht verändert. Der durch Backup-Operationen ausgelöste Kopiervorgang erzeugt deswegen keinen Komprimierungseffekt.
Volume löschen löscht das in der Netzübersicht ausgewählte Wissensnetz.
Volume komprimieren verringert den Platzbedarf des in der Netzübersicht ausgewählten Wissensnetzes. Dies geschieht über die Beseitigung ungenutzter Binnenblöcke. Durch Umkopierprozesse der Cluster und Blobs werden zunächst alle ungenutzten Blöcke an das Dateiende verschoben und dann im Dateisystem des Betriebssystems freigegeben.
Volume-Storage aktualisieren aktualisiert die Version des Blockdateisystems des in der Netzübersicht ausgewählten Wissensnetzes. Wird das Wissensnetz über einen Mediator angesprochen, wird die darin enthaltene Version verwendet, ansonsten wird die im Admin-Tool mitgelieferte Version verwendet. Die Aktualisierung ermöglicht eine schnellere Speicherung von Indexstrukturen. Sie ist möglich für Wissensnetze, deren K-Infinity-Core-Komponente älter als 4.2 ist.
Die Garbage-Collection ist ein Verfahren, das nicht mehr referenzierte Objekte (nach programmierterminologischer Lesart) in einem Wissensnetz löscht und damit den Speicherverbrauch des Wissensnetzes minimiert. Die Nutzung der Garbage-Collection setzt voraus, dass das zu bereinigende Wissensnetz über einen Mediator angesteuert wird.
Start startet eine neue Speicherbereinigung für das in der Netzübersicht ausgewählte Wissensnetz oder setzt eine pausierte Speicherbereinigung fort. Es erfolgt keine Rückmeldung, wann der Vorgang abgeschlossen ist. Der Stand des Fortschritts kann über den Menüpunkt Status in Erfahrung gebracht werden.
Pause unterbricht die Durchführung der aktiven Speicherbereinigung für das in der Netzübersicht ausgewählte Wissensnetz.
Anhalten bricht die Durchführung der aktiven Speicherbereinigung für das in der Netzübersicht ausgewählte Wissensnetz ab.
Status schreibt den aktuellen Zustand der Speicherbereinigung für das in der Netzübersicht ausgewählte Wissensnetz in die Statusspalte der Netzübersicht und in das Nachrichtenfeld. Ist eine Speicherbereinigung aktiv, erfolgt zusätzlich eine Rückmeldung über den Stand des Fortschritts in Form einer Prozentangabe.
Die Einzelnetzverwaltung erlaubt die Administration eines einzelnen Wissensnetzes. Sie kann über die Schaltfläche Weiter im Startfenster erreicht werden. Erforderlich sind hierzu entsprechende Eingaben in den Feldern Server und Wissensnetz des Startfensters.
Für den Zutritt zum Einzelnetzverwaltungsfenster ist die Anmeldung eines Nutzers mit Administratorrechten notwendig. Dessen Anmeldung vollzieht sich in einem separaten Authentifizierungsfenster.
Im Auswahlfeld Benutzer wird ein vorher im ausgewählten Wissensnetz registrierter Nutzer ausgewählt. Dessen Auswahl erfolgt über die Schaltfläche ... in einem eigenen Fenster. In der Auswahlliste werden nur Nutzer mit Administratorrechten gezeigt.
Im Freitextfeld Passwort muss das korrekte Passwort dieses Nutzers eingegeben werden.
Start meldet den Nutzer mit den eingegebenen Daten an.
Zurück kehrt zum Startfester zurück.
Das Einzelnetzverwaltungsfenster verfügt über eine mehrstufig gegliederte Menüliste links und ein Operationsfenster rechts. Der Inhalt des Operationsfensters richtet sich nach dem gewählten Menüpunkt in der Menüliste.
Die Schaltfläche Zurück wechselt zum Startfenster zurück.
Die Schaltfläche Beenden schließt das Admin-Tool.
Wird das zu administrierende Wissensnetz über einen Mediator angesprochen, muss für jede Operation, die eine Aktivität des Mediators erfordert, das korrekte Mediator-Passwort in einem eigenen Fenster angegeben werden. Dies lässt sich umgehen, indem dort die Option Passwort bis zum Abmelden merken über das nebenstehende Kontrollkästchen aktiviert wird.
Wird das zu administrierende Wissensnetz ohne Mediator angesprochen, ist ein Zutritt anderer Nutzer zum Wissensnetz über den Knowledge-Builder oder eine weitere Instanz des Admin-Tools nicht möglich, solange das Einzelnetzverwaltungsfenster geöffnet ist.
Download erzeugt eine Kopie des Wissensnetzes und speichert sie lokal im relativ zur Position des Admin-Tools liegenden Unterordner volumes. In einem separat erscheinenden Freitextfeld kann ein neuer Name für diese Kopie vergeben werden.
Kopieren nach... erzeugt eine Kopie des Wissensnetzes und speichert sie im gleichen Ordner wie das Originalnetz. In einem separat erscheinenden Freitextfeld muss ein neuer Name für diese Kopie vergeben werden.
In Folge der über Transfer-Operationen ausgelösten Kopierprozesse wird die Blockbelegung der Cluster und Blobs innerhalb der Wissensnetzkopie neu festgelegt und dabei deren Platzverbrauch optimiert. Der hierdurch bewirkte Komprimierungseffekt ist der gleiche wie über die Operation Verwalten -> Volume komprimieren in der Gesamtnetzverwaltung.
Log herunterladen erzeugt eine Kopie der üblicherweise im Ordner des verbundenen Mediators liegenden Mediator-Protokolldatei (Standarddateiname: mediator.log). Name und Speicherort der Kopie können in einem Speicherdialog frei gewählt werden. In der Mediator-Protokolldatei wird ein Protokoll über alle Aktivitäten des Mediators seit seiner ersten Inbetriebnahme geführt.
Download und Log herunterladen setzen voraus, dass das Admin-Tool mit einem Mediator verbunden ist.
Backup erstellen erzeugt eine Sicherungskopie des Wissensnetzes und speichert sie im relativ zur Position dieses Wissensnetzes liegenden Parallelordner backup. Für jede Sicherungskopie wird dort ein eigener Unterordner angelegt, in dessen Bezeichnung der Zeitpunkt der Kopierstellung auf eine Sekunde genau eingearbeitet ist. Jede Sicherungskopie ist eine vollständige Kopie des Originalnetzes.
Vor Erzeugung der Sicherungskopie wird über ein eigenes Fenster erfragt, ob der Nutzer bis zum Abschluss des Kopiervorganges warten will. Gegebenenfalls wird bis zu diesem Zeitpunkt die weitere Nutzung des Admin-Tools blockiert. Andernfalls startet der Kopiervorgang im Hintergrund und eine Nachricht über den Fortgang des Kopiervorganges oder dessen Fertigstellung unterbleibt.
Backup wiederherstellen erzeugt eine Kopie einer ausgewählten Sicherungskopie und speichert sie im gleichen Ordner wie das momentan administrierte Wissensnetz. In einem separat erscheinenden Freitextfeld muss ein neuer Name für diese Kopie vergeben werden. Die Auswahl der Sicherungskopie, die in einem Unterordner des Ordners backup abgelegt sein muss, der parallel zur Position des momentan administrierten Wissensnetzes liegt, erfolgt über zwei separate Auswahlfenster, in denen zuerst das Wissensnetz und danach die nach Erstellungszeiten sortierte Version ausgewählt werden.
Backup löschen löscht eine ausgewählte Sicherungskopie. Die Auswahl dieser Sicherungskopie, die in einem Unterordner des Ordners backup abgelegt sein muss, der parallel zur Position des momentan administrierten Wissensnetzes liegt, erfolgt über zwei separate Auswahlfenster, in denen zuerst das Wissensnetz und danach die nach Erstellungszeiten sortierte Version ausgewählt werden.
Die Blockbelegung der Cluster und Blobs innerhalb des Originalwissensnetzes wird bei der Erstellung einer Wissensnetzkopie nicht verändert. Der durch Backup-Operationen ausgelöste Kopiervorgang erzeugt deswegen keinen Komprimierungseffekt.
Um den Knowledge-Builder von bestimmten rechenintensiven Prozessen wie der Indizierung und der Abfrage von Wissensnetzen sowie der Ausführung von Skripten zu entlasten, können diese Prozesse teils wahlweise, teils exklusiv als Aufgaben (Jobs) von Job-Clients (einem Software-Dienst) übernommen werden. Dazu muss über die Benutzeroberfläche des Knowledge-Builders oder per Skript eine Aufgabe ausgelöst oder es müssen die Bedingungen für ihre Auslösung festgelegt werden. Außerdem ist mindestens ein Job-Client zu konfigurieren und zu starten, der Aufgaben dieses Aufgabentyps (Job Pool) übernehmen kann. Das Admin-Tool übernimmt hierbei überwiegend eine Beobachtungsfunktion. Unerledigte Aufgaben erscheinen im Knowledge-Builder unter dem Eintrag Aufträge in der Rubrik Technik. Die Verwaltung von Job-Clients über das Admin-Tool setzt voraus, dass das Admin-Tool mit einem Mediator verbunden ist.
Die tabellarische Job-Clients-Übersicht zeigt für jeden aktuell laufenden Job-Client
Die Job-Client-Nummer wird vom Mediator fortlaufend generiert und bei jeder Neuanmeldung neu vergeben. Der Job-Client-Name und die dem Job-Client zugeordneten Aufgabentypen werden in der Initialisierungsdatei des jeweiligen Job-Clients (Standarddateiname: jobclient.ini) unter dem Schlüssel name respektive dem Schlüssel jobPools festgelegt. In der Job-Client-Übersicht wird jeder Aufgabentyp eines Job-Clients in einer eigenen Zeile dargestellt, so dass ein Job-Client regelmäßig mehrere Zeilen belegt.
Die einzelnen Spalten der Job-Clients-Übersicht sind über einen Klick auf den Spaltenkopf sortierbar. Per Rechtsklick auf eine Zeile kann außerdem ein Kontextmenü geöffnet werden:
Die tabellarische Job-Pools-Übersicht listet alle Aufgabentypen, die in der Job-Clients-Übersicht mindestens einem Job-Client zugeordnet sind. Für jeden Aufgabentyp werden
genannt.
Die einzelnen Spalten der Job-Pools-Übersicht sind über einen Klick auf den Spaltenkopf sortierbar. Per Rechtsklick auf eine Job-Client-Zeile kann außerdem ein Kontextmenü geöffnet werden:
Client
Client-Leistungsdaten aufzeichnen startet und beendet die Erhebung diverser Leistungskennzahlen, die an Aktivitäten der mit dem Wissensnetz verbundenen Software-Komponenten gekoppelt sind. Diese Leistungskennzahlen können zur Performanzanalyse verwendet werden.
Intervall setzt die notwendige Zeitspanne in Sekunden, bis eine Software-Komponente erneut ein Datenpaket mit Leistungskennzahlen an das Admin-Tool sendet. Es kann nach dem Start der Aufzeichnung nicht mehr verändert werden. Die Vorerinstellung liegt bei 10 Sekunden.
In der Leistungskennzahlenübersicht werden die Leistungskennzahlen in geschachtelten Listenpunkten ausgegeben. Per Klick auf die links neben den Rubriken befindlichen Dreiecksymbole können Listenunterpunkte ein- und ausgeklappt werden. Alternativ lässt sich dies über ein Kontextmenü realisieren, das über einen Klick mit der rechten Maustaste auf einen Listenpunkt aufgerufen werden kann:
Mit einem Doppelklick auf einen Listenpunkt lassen sich alle darunter abgelegten Leistungskennzahlen in einem separaten Fenster auf einen Blick darstellen. Dort können sie in die Zwischenablage des Betriebssystems kopiert (Schaltfläche In Zwischenablage kopieren) oder über einen Speicherdialog als frei benennbare Textdatei an eine beliebige Stelle exportiert werden (Schaltfläche Speichern).
Aktualisieren aktualisiert die in der Leistungskennzahlenübersicht dargestellten Leistungskennzahlen.
Zurücksetzen löscht die in der Leistungskennzahlenübersicht dargestellten Leistungskennzahlen.
In Zwischenablage kopieren kopiert diein der Leistungskennzahlenübersicht dargestellten Leistungskennzahlen in die Zwischenablage des Betriebssystems.
Server
Leistung prüfen startet einen Testvorgang, der die Performanz des angeschlossenen Mediators auswertet. Dabei werden vier Anfragen an den Mediator geschickt und die an das Admin-Tool gesendeten Antworten ausgewertet. Gemessen werden
Die Testergebnisse werden in die bereitgestellte Ergebnisliste geschrieben. Die einzelnen Spalten der Tabelle sind über einen Klick auf den Spaltenkopf sortierbar.
In Zwischenablage kopieren kopiert die Testergebnisse der Ergebnisliste als Reintext in die Zwischenablage des Betriebssystems.
Über diesen Menüpunkt lassen sich diverse versionsspezifische Informationen über das Wissensnetz und das Admin-Tool abrufen.
Konkret handelt es sich dabei um
Die Informationen werden in einem unsichtbaren Textfeld ausgegeben, welches über ein Kontextmenü verfügt, das per Rechtsklick aktiviert werden kann:
Ü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 Benutzerverwaltung gleicht derjenigen im Knowledge-Builder mit der Ausnahme, dass keine Verknüpfungen zwischen Nutzern und Objekten des nutzergenerierten Teilnetzes bearbeitet werden können.
Die tabellarische Nutzerübersicht zeigt für jeden im Wissensnetz registrierten Nutzer
Die einzelnen Spalten der Tabelle sind über einen Klick auf den Spaltenkopf sortierbar.
Der Status gibt Auskunft darüber, ob ein Nutzer Administratorrechte besitzt, ob ein Nutzer mit Administratorrechten kein Passwort besitzt und ob ein Nutzer über den Knowledge-Builder im Wissensnetz angemeldet ist. Namen von Nutzern mit Administratorrechten ohne Passwort sind rot markiert.
Erstellen legt einen neuen Nutzer an. Benutzername (verpflichtend) und Passwort (optional) werden in einem eigenen Fenster festgelegt. Die Art und Menge der dafür erlaubten Zeichen ist nicht beschränkt.
Passwort ändern ändert das Passwort des in der Nutzerübersicht ausgewählten Nutzers. In zwei aufeinanderfolgenden Fenstern wird zweimal das neue Passwort eingegeben.
Abmelden meldet den in der Nutzerübersicht ausgewählten Nutzer nach einer Sicherheitsbestätigung aus dem Wissensnetz ab. Damit diese Operation eine Wirkung entfaltet, muss dieser Nutzer aktuell über den Knowledge-Builder im Wissensnetz angemeldet sein.
Löschen löscht den in der Nutzerübersicht ausgewählten Nutzer nach einer Sicherheitsbestätigung. Mindestens ein Nutzer mit Administratorrechten muss verbleiben.
Umbenennen erlaubt über ein Freitextfeld in einem separaten Fenster die Vergabe eines neuen Benutzernamens für den in der Nutzerübersicht ausgewählten Nutzer. Bleibt das Freitextfeld leer, erfolgt keine Umbenennung.
Mitteilung sendet über ein Freitextfeld in einem separaten Fenster eine Nachricht an den in der Nutzerübersicht ausgewählten Nutzer. Die Nachricht wird im Wissensnetz zwischengespeichert und erscheint dem adressierten Nutzer in einem separaten Fenster im Knowledge-Builder, sobald er sich damit am Wissensnetz anmeldet. Der Nutzer kann auf diese Nachricht nicht antworten.
Administrator verleiht oder nimmt dem in der Nutzerübersicht ausgewählten Nutzer Administratorrechte. Damit ein Nutzer Administratorrechte erhalten kann, muss er ein Passwort besitzen. Nachdem er Administratorrechte besitzt, ist eine Löschung des Passworts indes möglich. Mindestens ein Nutzer muss Administratorrechte besitzen.
Operationen öffnet ein neues Fenster, in dem für den in der Nutzerübersicht ausgewählten Nutzer aus einer Liste von Operationen, namentlich
diejenigen gewählt werden können, die dieser Nutzer im Rahmen der Einzelnetzverwaltung in Zukunft ohne Eingabe des Mediator-Passworts ausführen darf. Zur Bestätigung der Auswahl muss in das Freitextfeld Server-Passwort für Operationen das korrekte Mediator-Passwort eingegeben werden.
Die Operation Operationen ist nur wählbar für einen Nutzer mit Administratorrechten. Ihre Verwendung setzt außerdem voraus, dass ein Mediator-Passwort gesetzt wurde.
Das Feld Administratoren gibt die Anzahl aller im Wissensnetz registrierten Nutzer mit Administratorrechten an.
Das Feld Benutzer gibt die Anzahl aller im Wissensnetz registrierten Nutzer ohne Administratorrechte an.
Das Feld Aktive gibt die Anzahl aller gegenwärtig über den Knowledge-Builder im Wissensnetz angemeldeten Nutzer an.
Attributwerte von Attributen mit dem Attributdatentyp Datei (sogenannte Blobs) können auch wissensnetzextern in einem Blob-Speicher gespeichert werden. Dies hat den Vorteil, dass sie unabhängig vom Wissensnetz und damit bei Bedarf in einer anderen Systemumgebung verwaltet werden können. Um Blobs in einem Blob-Speicher zu sichern, muss der Blob-Speicher eingerichtet und mit einem konfigurierten Blob-Service (einem Software-Dienst) verbunden werden.
Anlegen erzeugt einen neuen Blob-Speicher. Er erscheint unter Verwendung des Namensformats [Wissensnetz-ID]+[Blob-Speicher-ID] in dem darüber liegenden Textfeld, der Blob-Speicher-Gesamtübersicht.
Löschen löscht den in der Blob-Speicher-Gesamtübersicht ausgewählten Blob-Speicher.
Das Zahlenfeld Löschbare Dateien zeigt die Anzahl der nicht mehr gebrauchten Blobs in dem in der Blob-Speicher-Gesamtübersicht ausgewählten Blob-Speicher. Blobs werden nicht mehr gebraucht, wenn ihre jeweiligen Attribute im Wissensnetz gelöscht wurden oder wenn die Verbindung zwischen Blob-Service und Blob-Speicher per Admin-Tool aufgehoben wurde.
Löschen löscht alle nicht mehr gebrauchten Blobs in dem in der Blob-Speicher-Gesamtübersicht ausgewählten Blob-Speicher.
Im Freitextfeld URLs kann ein Blob-Service identifiziert werden. Dies geschieht über die Eingabe der in der Initialisierungsdatei des zugehörigen Blob-Services (Standarddateiname: blobservice.ini) unter dem Schlüssel interfaces hinterlegten Netzadresse inklusive des Präfixes http. Soll der Blob-Service über mehrere Netzadressen angesprochen werden, können diese hintereinander mit Komma getrennt eingegeben werden.
Alternativ kann auch der im Mediator integrierte Blob-Service angesprochen werden. Dazu müssen in der Initialisierungsdatei des Mediators (Standarddateiname: mediator.ini) unter dem Schlüssel startBlobService der Wert true gesetzt und das Freitextfeld URLs leer gelassen werden. Das rechts neben dem Freitextfeld URLs positionierte Kontrollkästchen Intern indiziert, ob der integrierte Blob-Service oder ein externer Blob-Service angesprochen wird. Die Konfiguration des im Mediator integrierten Blob-Services erfolgt nicht über die Mediator-Initialisierungsdatei, sondern über eine separate Initialisierungsdatei (Standarddateiname: blobservice.ini).
Hinzufügen verbindet den in der Blob-Speicher-Gesamtübersicht ausgewählten Blob-Speicher mit dem über das Freitextfeld URLs identifizierten Blob-Service. Dafür muss der Blob-Service aktiviert sein. Gelingt die Verknüpfung, erscheint der Blob-Speicher unter Verwendung des Namensformats [Wissensnetz-ID]+[Blob-Speicher-ID] in dem darunter liegenden Textfeld, der Übersicht angemeldeter Blob-Speicher.
Aktualisieren aktualisiert die Übersicht angemeldeter Blob-Speicher. Dazu muss ein Blob-Speicher in der Blob-Speicher-Gesamtübersicht ausgewählt sein.
Entfernen unterbricht die Verbindung des in der Übersicht angemeldeter Blob-Speicher ausgewählten Blob-Speichers mit dem Blob-Service und entfernt den Blob-Speicher aus der Übersicht. Dabei verlieren alle im Blob-Speicher hinterlegten Blobs unwiderruflich ihre internen Verweise zu den jeweiligen Attributen im Wissensnetz und können im Wissensnetz nicht mehr abgerufen werden. Damit die Entfernung gelingt, muss der in der Übersicht angemeldeter Blob-Speicher ausgewählte Blob-Speicher auch in der Blob-Speicher-Gesamtübersicht ausgewählt sein.
Alle über einen Blob-Service gesicherten Blobs werden in einem relativ zur Position des Blob-Services liegenden Unterordner blobs abgelegt. Die interne Zuordnung jedes Blobs zu seinem Blob-Speicher und seinem Wissensnetz erfolgt über eine SQLite-Datenbank.
Wissensnetze bestehen aus Wissensnetzkomponenten. Neben den Basisfunktionalitäten gewähren sie den Wissensnetzen im Wesentlichen zusätzliche Schnittstellen und im Browser darstellbare Bedienoberflächen für die Nutzdaten (Webfrontends).
Eine besondere Untergruppe von Wissensnetzkomponenten sind die Veröffentlichungsstatuskomponenten (Release States), die in drei Varianten (Preview, Release Candidate, Release) existieren. Wird eine derartige Komponente im Wissensnetz installiert, können ausschließlich Software-Komponenten mit dem passenden Veröffentlichungsstatus auf das Wissensnetz zugreifen.
In der Software-Liste sind alle mit dem Admin-Tool mitgelieferten Wissensnetzkomponenten mit ihren jeweiligen Versionsnummern alphabetisch gelistet. Bedürfen sie einer eigenen Lizenz, ist außerdem vermerkt, ob die aktuelle Lizenz des Wissensnetzes sie umfasst oder nicht. Veröffentlichungsstatuskomponenten verfügen über keine Versionsnummer.
Wird eine Wissensnetzkomponente mit der rechten Maustaste angeklickt, erscheint ein Kontextmenü. Der dort verfügbare Menüpunkt Standardkomponente hinzufügen verfügt über die gleiche Funktionalität wie die gleichnamige Schaltfläche.
Standardkomponente hinzufügen installiert die in der Software-Liste ausgewählte Wissensnetzkomponente im Wissensnetz. Ein separates Fenster informiert über den Installationsstatus. Manche Wissensnetzkomponenten setzen für ihre Installation die Installation anderer Wissensnetzkomponenten im Wissensnetz voraus. Die meisten installierten Wissensnetzkomponenten (außer Veröffentlichungsstatuskomponenten) tauchen im Knowledge-Builder als eigene Einträge in der Rubrik Technik auf. Es kann immer nur eine Veröffentlichungsstatuskomponente zur gleichen Zeit installiert sein.
Lizenztemplate schreiben erzeugt eine inhaltlich zu vervollständigende Vorlage der für die Lizenzschlüsselgenerierung verwendeten Komponentenlizenzkonfigurationsdatei und speichert sie über einen Speicherdialog an einer frei wählbaren Stelle ab (Standarddateiname: [Wissensnetz].componentLicenseTemplate.ini). Unabhängig von der Konfiguration des gerade administrierten Wissensnetzes werden Konfigurationsplatzhalter für die Komponenten KEM, K-Infinity-Core und Knowledge-Builder vorgegeben. In jedem Konfigurationsplatzhalter wird die im Admin-Tool mitgelieferte Versionsnummer der jeweiligen Wissensnetzkomponente voreingetragen.
In der Wissensnetzliste sind alle im Wissensnetz installierten Wissensnetzkomponenten mit ihren jeweiligen Versionsnummern alphabetisch gelistet. Eine installierte Wissensnetzkomponente, für die im Admin-Tool eine neuere Version mitgeliefert ist, ist rot markiert. Die optionale Komponente Knowledge-Builder ist bei einem neuen Wissensnetz standardmäßig vorinstalliert.
Die Textfelder Name und Version zeigen den Namen respektive die dreistellige Versionsnummer der in der Wissensnetzliste ausgewählten installierten Wissensnetzkomponente.
Generische Komponente hinzufügen fügt der Wissensnetzliste eine generische Modellkomponente oder eine generische Softwarekomponente hinzu. Die Auswahl des Komponententyps erfolgt in einem separaten Fenster. Generische Komponenten erlauben die Bündelung projektspezifisch angefertigter Wissensnetzerweiterungen und vereinfachen deren (De-)Installation und Versionskontrolle über das Admin-Tool. Name und Versionsnummer einer im Wissensnetz installierten generischen Wissensnetzkomponente können in den entsprechend benannten Textfeldern frei vergeben werden.
Aktualisieren (die Bezeichnung wechselt zu Erneuern, wenn sie aktiviert werden kann) aktualisiert die in der Wissensnetzliste ausgewählte installierte Wissensnetzkomponente auf die im Admin-Tool mitgelieferte Version. Weicht die Sprache des aktuell laufenden Admin-Tools von der Sprache des Admin-Tools ab, mit dem die Wissensnetzkomponente ursprünglich im Wissensnetz installiert wurde, werden außerdem die Bezeichner aller Elemente und Elementtypen dieser Wissensnetzkomponente aktualisiert. Je nach Wissensnetzkomponente fügt die Aktualisierung den alten Bezeichnern neue Bezeichner in der Sprache des aktuell laufenden Admin-Tools hinzu (in Abhängigkeit von der Spracheinstellung des Knowledge-Builders wird dann die jeweils zutreffende Sprachversion dargestellt) oder ersetzt die alten Bezeichner mit den neuen Bezeichnern.
Entfernen deinstalliert die in der Wissensnetzliste ausgewählte installierte Wissensnetzkomponente. Sofern Wissensnetzkomponenten im installierten Zustand im Knowledge-Builder über einen eigenen Eintrag in der Rubrik Technik verfügen, hinterlassen sie dort nach ihrer Deinstallation ein eigenes Teilnetz, das manuell entfernt werden muss. Wissensnetzkomponenten lassen sich nur entfernen, wenn keine weiteren Wissensnetzkomponenten installiert sind, die von den zu deinstallierenden Wissensnetzkomponenten abhängig sind. Die beiden Wissensnetzkomponenten K-Infinity-Core und View-Konfiguration bieten Basisfunktionalitäten und lassen sich nicht entfernen.
Boost Libraries 1.18.0
Dieses Konfigurationsmenü erscheint nur, wenn die Wissensnetzkomponente Boost Libraries installiert ist.
Mit Ausnahme des Blob-Services und des Mediators können alle Software-Komponenten JavaScript interpretieren. Um den Interpretationsumfang und die Interpretationsgeschwindigkeit von in JavaScript eingebetteten regulären Ausdrücken zu verbessern, kann deren Interpretation an die Bibliothek Boost.Regex übergeben werden. Unter Windows und Linux muss sich dazu die Bibliothek (Dateiname in Windows: boost_regex.dll, Dateiname in Linux: libboost_regex.so) im gleichen Verzeichnis befinden wie die übergebende Software-Komponente. In Mac OS ist die Bibliothek in die Datei der übergebenden Software-Komponente integriert.
Die Wissensnetzkomponente Boost Libraries ermöglicht die Sicherstellung, dass auf die Boost.Regex-Bibliothek zugegriffen werden kann.
Ist die Option Boost-Libraries für alle inkl. Admins erforderlich ausgewählt, können alle Software-Komponenten außer dem Admin-Tool auf das Wissensnetz nur zugreifen, wenn sie auf die Bibliothek Boost.Regex zugreifen können.
Ist die Option Boost-Libraries für alle außer Admins erforderlich ausgewählt, können alle Software- Komponenten außer dem Admin-Tool auf das Wissensnetz nur zugreifen, wenn sie auf die Bibliothek Boost.Regex zugreifen können. Ausgenommen von dieser Zugriffsperre sind Nutzer mit Administratorrechten, die das Wissensnetz über den Knowledge-Builder betreten.
Ist die Option Boost-Libraries nicht erforderlich, nur loggen ausgewählt, hinterlegt jede Software- Komponente in seiner jeweiligen Protokolldatei, sofern vorhanden, eine entsprechende Warnung, wenn es beim Start nicht auf die Bibliothek Boost.Regex zugreifen kann. Ein Zugriff auf das Wissensnetz bleibt unabhängig davon möglich.
Knowledge Portal
Dieses Konfigurationsmenü erscheint nur, wenn die Wissensnetzkomponente Knowledge-Portal installiert ist.
Die Wissensnetzkomponente Knowledge-Portal ermöglicht einem Wissensnetz den Betrieb eines Knowledge-Portals (eines über einen Browser darstellbaren Frontends). Die Konfiguration der Darstellungs- und Bedienelemente dieses Frontends erfolgt im Knowledge-Builder an den entsprechenden Elementtypen über einen von der Wissensnetzkomponente speziell dafür bereitgestellten Editor mit Hilfe der Auszeichnungssprache XML. Zur einfacheren Wartung und logischen Reglementierung der XML-Dokumente lassen sich Schemata im Format DTD installieren, anhand derer die XML-Dokumente validiert werden können.
Im Frontend wird eine Bearbeitungssicht und eine Präsentationssicht mit jeweils exklusiven Darstellungs- und Bedienelementen unterschieden. Für beide Sichten werden separate DTD-Schemata geführt. Die nachfolgend erläuterten Bedienelemente existieren jeweils für jede Sicht.
Über die Schaltfläche Wählen kann auf das Dateisystem des Betriebssystems zugegriffen werden, um eine DTD-Schema-Datei für die jeweilige Sicht zu laden und im Wissensnetz zu installieren. Der Standarddateiname für Bearbeitungssicht-DTDs lautet editConfig.dtd, der Standarddateiname für Präsentationssicht-DTDs lautet viewConfig.dtd.
Zurücksetzen löscht das für die jeweilige Sicht installierte DTD-Schema aus dem Wissensnetz.
Anzeigen stellt das für die jeweilige Sicht installierte DTD-Schema in einem eigenen Fenster dar. Dort kann es in die Zwischenablage des Betriebssystems kopiert (Schaltfläche In Zwischenablage kopieren) oder über einen Speicherdialog als frei benennbare Textdatei an eine beliebige Stelle exportiert werden (Schaltfläche Speichern). Das Fenster verfügt außerdem über ein eigenes Kontextmenü, welches mit einem rechten Mausklick geöffnet werden kann:
Konvertierungsservice
Dieses Konfigurationsmenü erscheint nur, wenn die Wissensnetzkomponente Druckkomponente installiert ist.
Die Druckkomponente ermöglicht die Integration ausgewählter Wissensnetzelemente in ein speicherbares elektronisches Dokument. Dazu muss eine Dokumentvorlage in den Formaten ODT, DOCX oder RTF über den Knowledge-Builder in das Wissensnetz importiert und mit den in ein Dokument zu integrierenden Wissensnetzelementen verknüpft werden. Die Gestaltung dieser Dokumentvorlage erfolgt in einem externen Office-Programm, von Elementen des Wissensnetzes auszufüllende Platzhalter lassen sich mit Hilfe von KScript und KPath definieren.
Zum Funktionsumfang der Druckkomponente gehört der Konvertierungsservice. Soll im Knowledge-Builder über den Kontextmenüpunt Drucken ein Dokument erzeugt werden, lassen sich neben dem Ursprungsformat der importierten Dokumentvorlage diverse andere Ausgabeformate wählen, in die die Dokumentvorlage konvertiert werden kann. Damit diese Konvertierung funktioniert, müssen eine passend konfigurierte Bridge (ein Software-Dienst) gestartet und mit der Druckkomponente verknüpft sowie eine Version von LibreOffice oder OpenOffice installiert sein.
Passend konfiguriert wird die Bridge über ihre Initialisierungsdatei (Standarddateiname: bridge.ini). Dort muss in der Sektion [KHTTPRestBridge] unter dem Schlüssel services der Wert jodService ergänzt werden. Außerdem ist eine neue Sektion [file-format-conversion] anzulegen und dort über das Schlüsselwertpaar sofficePath=“[Dateipfad]/soffice.exe“ mit einer korrekten Pfadangabe der Ort der Startdatei von LibreOffice beziehungsweise OpenOffice zu hinterlegen.
Die Verknüpfung der Bridge mit der Druckkomponente erfolgt über das Freitextfeld URL. Dort wird die Netzadresse der Bridge im Format http://[ Bridge-IP-Nummer]:[Bridge-Port]/jodService/jodconverter/service eingetragen. Der Pfadabschnitt /jodService/jodconverter/service ist historisch bedingt und aktiviert den vordefinierten jodService.
Überprüfen startet einen Testprozess. Der Testprozess schickt über REST ein Testdokument an die über die Netzadresse festgelegte Bridge und erwartet, dass ein ordnungsgemäß konvertiertes Testdokument zurückgeschickt wird. Das Testergebnis wird in einem separaten Fenster ausgegeben.
Im Freitextfeld Timeout wird festgelegt, wie viele Sekunden lang auf die Rücksendung des konvertierten Testdokuments gewartet wird, bevor eine Fehlermeldung generiert wird. Die Voreinstellung liegt bei 20 Sekunden.
Ein Wissensnetz muss eine gültige Lizenz besitzen, damit der Knowledge-Builder und andere Software- Komponenten (mit Ausnahme des Admin-Tools) damit arbeiten können.
Das Feld Status gibt an, ob die Lizenz gegenwärtig gültig oder ungültig ist. Falls sie ungültig ist, wird außerdem ein Grund genannt. Gründe für eine ungültige Lizenz können die Überschreitung des Gültigkeitsdatums oder der maximalen Anzahl erlaubter registrierter Nutzer sein.
Das Feld Kunde beschreibt den Kunden, für den die Lizenz ausgestellt wurde. Neben dem Namen können auch die Adresse und die Abteilung genannt sein.
Das Feld Komponenten stellt den Inhalt der für die Lizenzschlüsselgenerierung verwendeten Komponentenlizenzkonfigurationsdatei [Wissensnetz].componentLicenseTemplate.ini dar. Dort werden Festlegungen über
Das Feld Partner enthält den Namen des Partners, über den die Lizenz weitergegeben wird.
Das Feld gültig bis enthält das Datum, nach dessen Ablauf die Lizenz erlischt.
Das Feld gültig für Netze enthält eine Liste der Namen aller Netze, auf die die Lizenz beschränkt ist. Möglich ist eine Erfassung über einen regulären Ausdruck.
Das Feld gültig für Server enthält eine Liste aller IP-Adressen und Port-Nummern, über die ein an das Wissensnetz angeschlossener Mediator erreicht werden darf.
Die Felder Partner, gültig bis, gültig für Netze und gültig für Server können leer sein.
Alle Felder verfügen über ein Kontextmenü, das per Rechtsklick aktiviert werden kann:
Hinzufügen / Erneuern erlaubt das Laden eines neuen Lizenzschlüssels (Dateiname: [Lizenzname].key) über das Dateisystem des Betriebssystems.
Die kommandozeilenbasierten Software-Werkzeuge (Shell-Tools) von k-infinity verwenden in ihrer Standardkonfiguration keinen Authentifikationsmechanismus. Ist ein solcher Mechanismus erwünscht, kann er über die unter diesem Menüpunkt angebotenen Konfigurationselemente nachgerüstet werden. Dazu muss das mit einer Authentifizierungspflicht auszustattende Software-Werkzeug gegenüber einem Wissensnetz als authentifizierungspflichtig gekennzeichnet werden und es muss eine an einen Nutzer dieses Wissensnetzes gebundene Authentifizierungsdatei erzeugt werden, über die sich das Software-Werkzeug authentifizieren kann. Die Kennzeichnung des Software-Werkzeuges erfolgt über seine Aufnahme in die Übersicht der Shell-Tools mit Überprüfung der Zugangsberechtigung. Die Erzeugung der Authentifizierungsdatei lässt sich über die Schaltfläche Erzeugen abwickeln.
Die Übersicht der Shell-Tools mit Überprüfung der Zugangsberechtigung listet alle authentifizierungspflichtigen kommandozeilenbasierten Software-Werkzeuge mit ihrer systeminternen Bezeichnung in alphabetischer Reihenfolge.
Aus Liste hinzufügen erlaubt die Aufnahme eines zum Standardpaket von k-infinity gehörenden kommandozeilenbasierten Software-Werkzeuges in die Übersicht der Shell-Tools mit Überprüfung der Zugangsberechtigung. Zum Standardpaket gehören
Die Auswahl erfolgt über ein eigenes Fenster. Seit k-infinity Version 4.0 meldet sich der Blob-Server nicht mehr an ein Wissensnetz an, so dass er nicht länger einer Authentifizierungspflicht unterworfen werden kann.
Manuell hinzufügen erlaubt die Aufnahme eines projektspezifisch angefertigten kommandozeilenbasierten Software-Werkzeuges in die Übersicht der Shell-Tools mit Überprüfung der Zugangsberechtigung. Dazu wird dessen systeminterne Bezeichnung im Format [Namensraumname].[Klassenname] über ein eigenes Fenster eingegeben.
Entfernen entfernt das in der Übersicht der Shell-Tools mit Überprüfung der Zugangsberechtigung ausgewählte Software-Werkzeug aus der Übersicht.
Erzeugen öffnet ein neues Fenster, in dem entweder ein bereits im Wissensnetz registrierter Nutzer ausgewählt oder über die Schaltfläche Name und Passwort eingeben ein neuer Nutzer angelegt wird. Wird ein neuer Nutzer angelegt, müssen für ihn über zwei entsprechend benannte Freitextfelder in einem separaten Fenster ein Benutzername und ein Passwort vergeben werden. Der hierdurch erzeugte Nutzer verfügt nicht über Administratorrechte. Im Anschluss wird über einen Speicherdialog an beliebiger Stelle eine verschlüsselte Authentifizierungsdatei (Dateistandardname: [Benutzername].auth) erzeugt, in die der Benutzername und das Passwort dieses Nutzers abgelegt werden. Der Name der Datei darf vom Namen des darin gespeicherten Nutzers abweichen.
Im Textfeld Volume wird angezeigt, für welches Wissensnetz zuletzt eine Authentifizierungsdatei erstellt wurde.
Im Textfeld Datum wird angezeigt, an welchem Datum und zu welcher Uhrzeit zuletzt eine Authentifizierungsdatei angelegt wurde.
Die Verschlüsselung der Authentifizierungsdatei erfolgt mit einem vom Admin-Tool zufällig erzeugten Schlüssel, der bei seiner ersten Verwendung im Wissensnetz abgelegt wird. Die Schaltfläche Zurücksetzen erzeugt, nach einer Bestätigungsfrage, einen neuen zufälligen Schlüssel und ersetzt mit ihm den alten Schlüssel im Wissensnetz. In der Folge lassen sich alle mit dem alten Schlüssel erzeugten Authentifizierungsdateien nicht mehr entschlüsseln und können nicht mehr zur Authentifizierung verwendet werden.
Damit ein als authentifizierungspflichtig gekennzeichnetes Software-Werkzeug sich mit dem Wissensnetz verbinden kann, muss es mit den Parametern -user [Benutzername] und -passwordFile [Name einer Authentifizierungsdatei, bei Bedarf mit Dateipfad] gestartet und die Platzhalter müssen durch korrekte Werte ersetzt werden. Der Benutzername muss hierbei dem in der gewählten Authentifizierungsdatei abgelegten Benutzernamen entsprechen. Alternativ können diese Parameter auch in der Form user=[Benutzername] und passwordFile=[Name einer Authentifizierungsdatei, bei Bedarf mit Dateipfad] in die Initialisierungsdatei des Software-Werkzeuges eingetragen werden, sofern eine solche existiert.
Zur Performanzverbesserung verwenden auf das Wissensnetz zugreifende Software-Komponenten häufig einen eigenen Pufferspeicher (Cache). Darin werden Schema- und Konfigurationsdaten des Wissensnetzes zwischengespeichert, um im Falle einer späteren Verwendung schneller auf sie zugreifen zu können.
Client-Caches zurücksetzen löscht diese zwischengespeicherten Daten. Dies ist sinnvoll, wenn sie aufgrund von Änderungen am Schema oder an der Konfiguration veraltet sind. Diese Operation setzt voraus, dass das Wissensnetz über einen Mediator angesteuert wird.
Die Garbage-Collection ist ein Verfahren, das nicht mehr referenzierte Objekte (nach programmierterminologischer Lesart) in einem Wissensnetz löscht und damit den Speicherverbrauch des Wissensnetzes minimiert. Die Nutzung der Garbage-Collection setzt voraus, dass das zu bereinigende Wissensnetz über einen Mediator angesteuert wird.
Start startet eine neue Speicherbereinigung für das Wissensnetz oder setzt eine pausierte Speicherbereinigung fort. Es erfolgt keine Rückmeldung, wann der Vorgang abgeschlossen ist. Der Stand des Fortschritts kann über den Menüpunkt Aktualisieren in Erfahrung gebracht werden.
Pause unterbricht die Durchführung der aktiven Speicherbereinigung für das Wissensnetz.
Anhalten bricht die Durchführung der aktiven Speicherbereinigung für das Wissensnetz ab.
Aktualisieren schreibt den aktuellen Zustand der Speicherbereinigung für das Wissensnetz in das nebenstehende Textfeld. Ist eine Speicherbereinigung aktiv, erfolgt zusätzlich eine Rückmeldung über den Stand des Fortschritts in Form einer Prozentangabe.
Wartung jetzt ausführen überprüft
auf Mängel. Im Zuge der Prüfung wird auch die über den Knowledge-Builder einsehbare Statistik von Eigenschaftshäufungen pro Objekt (Metriken) aktualisiert.
Gefundene Mängel werden in einer tabellarischen Mangelübersicht gesammelt. Für jeden Mangel wird dort
ausgegeben. Die einzelnen Spalten der Tabelle sind über einen Klick auf den Spaltenkopf sortierbar.
Details stellt alle in der Mangelübersicht des ausgewählten Mangels gelisteten Daten in einem neuen Fenster dar. Ergänzt werden die Uhrzeit des ersten Feststellungszeitpunkts sowie Datum und Uhrzeit des letzten Feststellungszeitpunkts. Die Daten können dort in die Zwischenablage des Betriebssystems kopiert (Schaltfläche In Zwischenablage kopieren) oder über einen Speicherdialog als frei benennbare Textdatei an eine beliebige Stelle exportiert werden (Schaltfläche Speichern). Die über die Schaltfläche Details ausgelöste Operation kann alternativ über einen Doppelklick auf einen Mangel in der Mangelübersicht erwirkt werden.
Entfernen löscht den in der Mangelübersicht ausgewählten Mangel. Dies hat keine Auswirkungen auf den ersten Feststellungszeitpunkt des Mangels.
Über diesen Menüpunkt lässt sich eine chronologisch sortierte Wartungshistorie aller wesentlichen Administrationsvorgänge im Wissensnetz seit seiner Entstehung abrufen. Erfasst werden Backup- und Transfervorgänge, Komponenteninstallationen und -aktualisierungen sowie Ausführungen von Wartungsskripten und der Garbage-Collection, jeweils mit Datum und Uhrzeit.
Die Wartungshistorie verfügt über ein Kontextmenü, das per Rechtsklick aktiviert werden kann:
In Zwischenablage kopieren kopiert die gesamte Wartungshistorie in die Zwischenablage des Betriebssystems.
Kommentar hinzufügen erlaubt die Eingabe einer Anmerkung über ein Freitextfeld in einem separaten Fenster. Sie wird mit einem Zeitstempel versehen und in die Wartungshistorie aufgenommen. In die Wartungshistorie aufgenommene Anmerkungen lassen sich nicht löschen.
Die Schaltfläche Setzen aktiviert eine Wartungssperre, die jedem Nutzer den Zutritt zum Wissensnetz über den Knowledge-Builder verwehrt. Dafür muss eine Wartungsnachricht formuliert werden.
Die Wartungsnachricht wird im Freitextfeld Wartungsnachricht formuliert. Sie wird jedem Nutzer, der das Wissensnetz bei aktivierter Wartungssperre über den Knowledge-Builder betreten will, in Form einer Fehlermeldung angezeigt.
Die Schaltfläche Zurücksetzen hebt die zuvor gesetzte Wartungssperre auf und löscht die Wartungsnachricht.
Über Wartungsskript auswählen kann auf das Dateisystem des Betriebssystems zugegriffen werden, um ein Wartungsskript (Dateiname: [Wartungsskript].kss) zu laden. Wartungsskripte werden fallspezifisch in der Programmiersprache Smalltalk angefertigt und erlauben Operationen, die sich nicht über die vordefinierten Funktionen des Admin-Tools oder über die KEM- oder JS-Schnittstellen realisieren lassen.
Verfügt das Wartungsskript über eine Beschreibung, wird diese nach dem Laden des Wartungsskripts in einem unsichtbaren Textfeld unterhalb der Schaltfläche Wartungsskript auswählen ausgegeben. Dieses Textfeld verfügt über ein Kontextmenü, das per Rechtsklick aktiviert werden kann:
Wartungsskript ausführen startet das Wartungsskript. Ein separat erscheinendes Fenster gibt Auskunft, wenn das Wartungsskript vollzogen wurde, und bietet je nach Skript zusätzliche Ausführungsinformationen oder erlaubt skriptspezifische Ausführungsoptionen.
Ein Wissensnetz im weiteren Sinne besteht neben den nutzergenerierten und über Komponenten eingebrachten Teilnetzen (Schemata mit Nutzdaten) noch aus diversen weiteren Bausteinen (Konfigurationen), die dieses Teilnetz funktional erweitern, konfigurieren oder damit arbeiten. Im Rahmen dieses Menüpunkts werden Schemata und Konfigurationen zusammenfassend als Konfigurationen bezeichnet.
Zahlreiche Konfigurationen eines Wissensnetzes lassen sich gezielt exportieren und importieren.
Die Konfigurationsübersicht bietet einen listenartigen Überblick über alle mittels der im Folgenden beschriebenen Operationen prinzipiell transferierbaren Konfigurationstypen eines Wissensnetzes. Prinzipiell transferierbar sind
Die Konfigurationsübersicht verwaltet überdies alle konkret zum Export bestimmten Konfigurationen. Zum Export bestimmte Konfigurationen erscheinen als ausklappbare Listenunterpunkte ihrer jeweiligen Konfigurationstypen. Benötigen diese Konfigurationen für ihren erfolgreichen Export andere Konfigurationen, sind diese anderen Konfigurationen wiederum in Form ausklappbarer Listenunterpunkte der jeweiligen Konfigurationen aufgeführt. Konfigurationstypen ohne eigene Konfigurationen sind kursiv gekennzeichnet, Konfigurationstypen mit eigenen Konfigurationen sind fett gekennzeichnet und stellen die Anzahl ihrer zugeordneten Konfigurationen in Klammern dar. Konfigurationstypen und Konfigurationen jedes Konfigurationstyps sind jeweils in alphabetischer Reihenfolge sortiert.
Das Ein- und Ausklappen von Listenunterpunkten in der Konfigurationsübersicht geschieht per Klick auf die sich links neben den Listenpunkten befindlichen Dreiecksymbole. Alternativ lässt sich dies über ein Kontextmenü realisieren, das über einen Klick mit der rechten Maustaste auf einen Listenpunkt aufgerufen werden kann:
Hinzufügen fügt der Konfigurationsübersicht eine Konfiguration des dort ausgewählten Konfigurationstyps hinzu. Existiert mehr als eine Konfiguration für den ausgewählten Konfigurationstyp im Wissensnetz, schließt sich eine Auswahlmöglichkeit in einem separaten Fenster an. Die Auswahl erfolgt dort entweder einzeln per Klick auf die jeweiligen Konfigurationen in einer Liste oder pauschal über die Schaltfläche Alles aus-/abwählen.
Entfernen löscht entweder alle Konfigurationen des in der Konfigurationsübersicht ausgewählten Konfigurationstyps oder die in der Konfigurationsübersicht ausgewählte Konfiguration.
Alle hinzufügen fügt der Konfigurationsübersicht alle im Wissensnetz existierenden Konfigurationen hinzu und verteilt diese auf die jeweils passenden Konfigurationstypen.
Über die Schaltflächen ... kann auf das Dateisystem des Betriebssystems zugegriffen werden, um ein Wartungsskript (Dateiname: [Wartungsskript].kss) zu laden. Wartungsskripte werden fallspezifisch in der Programmiersprache Smalltalk angefertigt und erlauben Operationen, die sich nicht über die vordefinierten Funktionen des Admin-Tools oder über die KEM- oder JS-Schnittstellen realisieren lassen.
Wird ein Wartungsskript geladen, erscheint der Dateiname des gewählten Wartungsskripts im links von der jeweiligen Schaltfläche positionierten Textfeld. Werden im Anschluss Konfigurationen importiert, wird das Wartungsskript ausgeführt. Werden im Anschluss Konfigurationen exportiert, wird das Wartungsskript ebenfalls exportiert und erst beim Import dieser Konfigurationen ausgeführt. Der genaue Ausführungszeitpunkt des Wartungsskripts in Relation zum Importprozess hängt davon ab, über welche der beiden ...-Schaltflächen es geladen wurde. Er befindet sich entweder vor dem Start des Importprozesses oder nach dem Ende des Importprozesses.
Export exportiert die in der Konfigurationsübersicht ausgewählten Konfigurationen. Zur Auswahl stehen der Export in eine einzige Archivdatei im Archivformat tar oder in einzelne Dateien in einem Ordner. Die Auswahl der Exportmethode vollzieht sich in einem separaten Fenster:
Import importiert nach einer Bestätigungsfrage Konfigurationen in das Wissensnetz. Zur Auswahl stehen der Import aus einer einzigen Archivdatei im Archivformat tar oder aus einzelnen Dateien in einem Ordner. Die Auswahl der Importmethode vollzieht sich in einem separaten Fenster:
Speichern speichert die in der Konfigurationsübersicht für dieses Wissensnetz aktuell getroffene Auswahl an Konfigurationen als XML-Datei. Über einen Speicherdialog werden Name und Ort der XML-Datei (Standarddateiname: instruction.xml) festgelegt.
Laden greift auf das Dateisystem des Betriebssystems zu, um eine zuvor gespeicherte Auswahl an Konfigurationen für dieses Wissensnetz aus einer XML-Datei (Standarddateiname: instruction.xml) zu laden.
Aktualisieren fügt dem Wissensnetz die mit dem Attributdatentyp Boolesch ausgestatteten Attributtypen
hinzu, falls sie darin noch nicht existieren. Diese Attributtypen werden benötigt, um bei einem Export einer Konfiguration des Konfigurationstyps Wissensnetz auszuwählen, welche in dieser Konfiguration befindlichen Elemente und Elementtypen jeweils exportiert und nicht exportiert werden sollen. Dazu werden diese Attributtypen über den Knowledge-Builder an passende Objekttypen gehängt und mit passenden Attributwerten versehen.
Soweit nicht anders über diese Attributwerte konfiguriert, gilt für jeden Objekttyp, dass er selbst exportiert wird, nicht aber seine Objekte. Wird ein Objekt oder Objekttyp exportiert, werden alle direkt mit ihm verbundenen Attribute und Relationen sowie deren Attribut- respektive Relationstypen ebenfalls exportiert.