|
| E x p a n d |
| your possibilities |
|
russian | english
|
Detailed information on SemanticNet:
|
|
Main scenarios of using the platform.
Here are the main scenarios of using the platform drawn schematically.
Exploring and querying the semantic layer.
Let's consider the application domain "refrigerator production", including concepts "base price",
"net cost", "refrigerator", "producer", "engine type", "warranty period", and others. One can browse
the semantic layer using the following chart. Here bubbles are concepts connected with associations
existing among concepts. Arrows connecting concepts mean many-to-one associations and non-arrow lines
mean many-to-many associations. Selected concepts and associations are marked with thick lines.
Double clicking on, for instance, the concept "producer", one opens the producer's surrounding
concepts to be surrounded with their own close concepts. One can repeat the procedure, thereby
navigating the semantic layer.
Thick-line selecting concepts as it is shown in the figure one can start querying the list
of refrigerators with the following header:
| Serial Number |
Issue Date |
Warranty Period |
Refrigerator Model |
Producer |
Registration Place |
Having specified a certain refrigerator model or producer, a user can get all refrigerators of the
specified model/ producer.
GUI form development and publication.
The following figure shows schematic illustration of main form development principles.
First of all, one can use the component panel to drop components on the form in run-time in the mode
WYSIWYG;
the dropped components can be tuned up and connected with data flows, such
as mater-detail flows and other more subtle data flows. Run-time design of forms is possible
both for new forms and existing ones.
The newly developed or changed forms can be saved in some individual work space of an end user, or they can
be published for common use. Since publishing, forms become immediately available for other end users to open
and to navigate to.
Semantic navigation and drilling down.
Semantic navigation is illustrated on the following schematic figure. Here a user selects a concept to
navigate, "Person" in our case, and the platform prepares the list of forms related to the concept.
Then the user clicks on some desirable form, named "People" in this example, and the form is opened.
Drilling-down represents an extension of semantic navigation and is illustrated on the following figure.
A user selects a cell, or several cells, to drill down. In our case it is the cell of the column
"Person" with the value "Person1". Then the platform prepares the list of forms related to the concept for the
user to select a desirable form. In this example user selects the form "People". When the form is opened,
the platform filters its data according to the cell selected initially for drilling-down. So the form only
shows those data, which are related to the person "Person1" selected earlier. As a result, we have actually
drilled down to data showed on the initial form "Tasks".
Mapping of an information system to the semantic layer.
The platform enables simultaneous access to various distributed heterogeneous information systems.
To make an information system accessible through the platform, its publisher should map its
data schema to the semantic layer of the platform. Consider mapping of the following relational schema:
Below we show mapping of the relational schema to concepts of the semantic layer. The mapping
consists of two stages: automatic concept generation and renaming. The first stage results in a set
of concepts named in the same way as the appropriate attributes of the tables. After generation,
the publisher should manually rename the concepts to human-readable form, as it is done below.
| Relational Schema |
|
Concepts of Semantic Layer |
| Table |
Attribute |
|
Concept Generated Automatically |
Concept After Renaming |
| TASKS |
TASK_ID |
|
TASK_ID#NODE1 |
Task |
| TASK_NAME |
|
TASK_NAME |
Name |
| PERSON_ID |
|
PERSON_ID |
Person |
| PAR_TASK |
|
PAR_TASK#PARENT |
Parent Task |
| PERSONS |
PERSON_ID |
|
PERSON_ID |
Person |
| AGE |
|
AGE |
Age |
| PHONE |
|
PHONE |
Phone |
| TASK_PERSONS |
TASK_ID |
|
TASK_ID#NODE |
Task |
| PERSON_ID |
|
PERSON_ID |
Person |
1The postfixes #node, #child, #parent are used for marking the concepts
generated for modeling a tree or net data structure.
No other procedures are needed to map the relational schema to the semantic layer.
The conceptual schema, associating the generated concepts with each other, is created automatically and
stored within the semantic layer with no human industry. One would be needed to adjust the conceptual
schema only if the underlying relational schema had no constraints over it.
|
