 |
|
Administrators are responsible for creating Users and Workgroups
|
|
 |
|
The Application Developer implements application specific functionality in form of active topics. Active Topics are deployed at server-side by the Administrator.
|
|
|
|
The application service runs DeepaMehta Applications by loading topic/associations into memory and triggering their hooks. Topics/Associations which are loaded into memory are called Live Topics and Live Associations.
When the user at client side interacts with a topic resp. association the actually the corresponding server side proxy topic resp. association is accessed.
|
|
|
|
|
An association represents a relationship between Topics. Associations along with topics represents the "knowledge" that is stored in the Corporate Memory.
Implementation notes
An Association is specified by the ISO 13250 standard "Topicmaps". A simplified form of an Association is specified by the interface Association. For the time being associations in DeepaMehta are binary whereas the standard specifies n-nary associations.
|
|
|
|
|
Corporate datasources (the databases existing in a company) are accessible by DeepaMehta
by means of Active Topics. Active Topics can reveal topics and associations based on
quering corporate datasources. Existing corporate datasources can be accessed by
DeepaMehta without any modification.
Implementation notes
A corporate datasource is specified by the interface CorporateDatasource.
Currently there implementations for SQL-databases and XML-files. An implementation for
LDAP-access is planned.
|
|
|
|
|
The Corporate Memory (german: das Firmengedächtnis) represents the companies knowledge. The knowledge is represented by information objects as well as relationships between the objects.
The information objects can be typed, like
- Person
- Project
- Task
- Workgroup
- Document
- Email
- Project description
- Workgroup discussion
- Webpage
- Meeting
- Appointment
- Database
Untyped objects are possible as well, like
Besides the objects there are also relationships between the objects stored
in the Corporate Memory. These relationships can have a semantic and a direction, e.g.
- is member of
- is responsible for
- is published by
- has appointment with
Undirected semantic-free associations are possible as well, e.g.
|
DeepaMehta relies on the ISO 13250 standard "Topicmaps", thus an
information object is represented as a Topic and the relationships as
Associations. According to the standard, you can think of the
Corporate Memory as one central Super-Topicmap which represents
the companies knowledge. This knowledge exists as is and is independant
of any presentation context. The corporate wide knowledge can consist of
thousands of topic types and millions of topic instances.
What the DeepaMehta client presents to a user is always a subset of the
Corporate Memory -- a so called View. A view is a personal view to a specific part of the corporate memory. In more detail, a view is a subset of the topics
and associations of the Corporate Memory along with Geometry and
Appearance information. According to the standard a view is a topicmap
too, thus in the DeepaMehta jargon "view", "topicmap" or just "map" are used
synonymously.
DeepaMehta extends the Topicmaps standard in the way Properties can be
stored along with topics resp. associations. A properties is a name/value pair, e.g. "Birthday/6.10.1968".
|
Implementation notes
The Corporate Memory is specified by the interface CorporateMemory.
Thus the Corporate Memory is independant from the actual storage approach. For the time
being there is an implementation for relational databases provided in form the RelationalCorporateMemory
class. You can think of further implementations for OO-databases resp. XML-Files.
|
|
|
|
|
A topic with custom behavoir extends/modifies the standard topic behavoir.
Custom topic behavoir is developed by means of the DeepaMehta-Application-Framework. A Topic with custom behavoir realizes domain specific functionality by means of one java sourcefile. The Development Guide (separate page) describes how to develop DeepaMehta applications.
A topic with custom behavoir
- Can react upon dedicated situations
- complex life-cycle: created, deleted, loaded
- the topic is renamed
- a property changed
- the topic is put into a view
- the enclosing view is published
- the viewmode is switched
- Can provide and handle application specific commands.
Commands are triggered at dedicated situations:
- choosen from topic context menu
- a topic is doubleclicked
- a detail window of a topic is closed
- Return is pressed in a single-line input field of the property panel
- can execute when application specific button of the property panel is pressed
- Can operate on properties
- Can reject a property change
- Can set topic properties to read-only
- Can perform transformations on topic properties
- Can rename derived properties
- Can operate on
- the corporate memory
- corporate datasources
- user session
- Can show an additional text next to the topic
Implementation notes
The baseclass LiveTopic provides the hooks which are the interfaces to framework.
|
|
|
|
|
A DeepaMehta application consists of a set of of domain specific topic types and/or association types. A type is defined by its properties and behavoir. Types are build by derivation. A type with derived standard behavoir is represented just by entries to the corporate memory (types and properties are themself topics). A type with custom behavoir is represented as one Java sourcecode file.
The Development Guide (separate page) describes how to develop DeepaMehta applications.
Developing Active Topics is an essential part of DeepaMehta Application Development. A DeepaMehta Application is run by the Application Service. Applications are deployed at server-side by the Administrator.
|
|
|
|
The DeepaMehta Client realizes DeepaMehta's presentation and user interaction paradigm.
The Client is a thin client which is written in Java. The client can run as applet as well as application. The presentation paradigm is heavily determined by topicmap editors. Topicmap editors are used for presenting the users workspaces as well as the opened views.
The client is application independent. It is transparent to the client if new appilcation (in form of active topics) is installed at server side.
The presentation process consists of 3 states:
Data --> Presentable Data --> Presentation
First there are the generic "Data" (the topics, associations and properties at storage
layer) -- fully independant of any presentation. The server retrieves the generic data
and enriches them wich further data needed for presentation (e.g. display coordinates,
filenames of image files, color specification codes) and sends these presentable
data to the client. The client in turn builds the actual presentation objects (by means
of the GUI) based on that presentable data.
[Geometry]
|
|
|
|
The DeepaMehta Server is an application server who serves DeepaMehta Applications.
Currently the application server is a standalone Java application who listens on one
dedicated port. Because of DeepaMehta's modular architecture it would be easy to provide
the application service as servlet (deploying only the HTTP-port) or as Enterprise
JavaBean.
|
|
|
The DeepaMehta software is made of 4 packages:
de.deepamehta.server | Server-specific classes and interfaces. |
de.deepamehta.topics | The topics package contains the active topic classes (kernel topics as well as application topics).
This package is part of the server. |
de.deepamehta.client | Client-specific classes and interfaces. |
de.deepamehta | The "common" package contains classes and interfaces used by both, client and server. |
|
|
|
|
If a person is not a registered User it can explore DeepaMehta by using the client in demo mode. In demo mode no username or password is required, but a prepared View to the Corporate Memory can be navigated and manipulated.
|
|
|
|
|
|
|
|
DeepaMehta Applications can be developed in a very effective way by means of the DeepaMehta-Application-Framework. Through the assistence provided by the framework the application development process will speed up by a factor of 2 to 20.
|
|
|
|
|
|
|
The functionality of a Non-Active Topic is determined by the DeepaMehta core logic:
- Have a type, a name, a version
- Can be associated with other topics
- Can reveal the types of associated topics
- Can reveal associated topics by topic type
- Can change the type, the name
- Can be removed from a view
- Can be deleted from corporate memory
- Can have properties, changable by user
- ... moving
- ... design mode
- ... database access
- ... derivation
- ... container
In order to realize application specific functionality Active Topics may be developed by means of custom implementation.
Implementation notes
Non-active Topics are instances of the class ProxyTopic.
|
|
|
|
|
A topic represents an information object that is relevant for the company. Besides topics there're Associations, which represents relationships between topics. Topics along with associations represents the "knowledge" that is stored in the Corporate Memory.
Implementation notes
A topic is specified by the ISO 13250 standard "Topicmaps". A simplified form of a topic is specified by the interface Topic.
|
|
|
|
|
A Topicmap is a formalism for representing and sharing knowledge. Knowledge is represented by means of information objects along with relationships between the objects. According the Topicmap formalism an information object is called a Topic and a relationship is called an Association.
Implementation notes
A Topicmap is specified by the ISO 13250 standard "Topicmaps". A simplified form of a Topicmap is specified by the interface TopicMap.
|
|
|
|
|
The person who uses the DeepaMehta Client is called the User. A User is identified by username and autentified by password. Once a User has logged in he gets presented its personal Portal.
|
|
|
|
A view is a personal view to a specific part of the Corporate Memory.
In more detail, a view is a subset of the topics and associations of the Corporate Memory along with Geometry and Appearance information. According to the ISO 13250 "Topic Maps" standard a view is a Topicmap, thus in the DeepaMehta jargon View, Topicmap or just Map are used synonymously.
|
|
|
|