Filtering Engine for Large Conceptual Schemas

Introducció

 

The Filtering Engine for Large Conceptual Schemas is a prototype tool that helps users to easily extract from those schemas the most relevant knowledge for a particular purpose.

Our engine contains a core that is responsible for maintaining and access the characteristics of a large conceptual schema. In addition, the core is under control of the filtering requests that query the schema in order to serve the information needs of the user. The conjunction of the specific information filtering requests and the core of the engine is implemented as a webservice. This architectural decision allows an easy interaction with web clients and increase the technology independence, and therefore, the usability of the overall system.

Main features

  • The Filtering Engine for Large Conceptual Schemas helps with the extraction of knowledge of interest to the user from a large conceptual schema.
  • The Filtering Engine for Large Conceptual Schemas uses inherent properties of large conceptual schemas to analyze the importance and interest of the elements in the schema.
  • The Filtering Engine for Large Conceptual Schemas introduces a request/response flow to the user interaction with a large conceptual schema.
  • The Filtering Engine for Large Conceptual Schemas reduces the time and effort a user requires to understand a large conceptual schema.

Instal·lació

 

The instructions to install the Filtering Engine are:

The prototype of the Filtering Engine for Large Conceptual Schemas can be executed in an Eclipse IDE with the Eclipse Web Tool Platform (WTP) within it. Therefore, to test the service we need to configure WTP with Tomcat and Axis. Let's see the required steps to locally use the service.

 

Step 1 - Install Eclipse Web Tools Platform (WTP)

Overview of Eclipse WTP

Eclipse WTP provides tools for developing standard Java web applications and Java EE applications. Typical web artifacts in a Java environment are HTML pages, XML files, webservices, servlets and JSPs. Eclipse WTP simplifies the creation these web artifacts and provides runtime environments in which these artifacts can be deployed, started and debugged.
Eclipse WTP supports all mayor webcontainer, e.g. Jetty and Apache Tomcat as well as the mayor Java EE application server. This tutorial uses Apache Tomcat as a webcontainer.

Dynamic Web Project

In Eclipse WTP you create "Dynamic Web Projects". These projects provide the necessary functionality to run, debug and deploy a Java web application. Therefore for the development of Java web application you create "Dynamic Web Projects" .

Tomcat Installation

  1. Download the Tomcat server 6.0.x from the following webpage http://tomcat.apache.org/
  2. On MS Windows you can use the self-explanatory MS installer to install Tomcat. For a Tomcat installation on other platforms, please use Google.
  3. After the installation test if Tomcat in correctly installed by opening a browser to http://localhost:8080. This should open the Tomcat main page and if you see this page then Tomcat is correctly installed.
  4. After verifying that Tomcat is correctly installed, stop Tomcat. Eclipse WTP is try to start Tomcat itself. If Tomcat is already running Eclipse WTP will have problems.

Installation of WTP

Use the Eclipse Update Manager (select Help -> Install New Software) to install Eclipse WTP. Install all packages from "Web, XML, and Java EE Development" except "PHP Development" and "Eclipse RAP". Follow the guidelines of the assistant and restart Eclipse.

WTP Configuration

Select Windows -> Preferences -> Server -> Runtime Environments. To configure WTP to use Tomcat Press Add.

Select your version of Tomcat.

Select the Tomcat installation directory where your version of Tomcat is installed and press continue.

Press Finish and then Ok. You are now ready to use Tomcat with WTP.
Server

During development you will create your server. You can manage you server via the server view. To see if you data was persisted stop and restart the server. You can do this via the Windows -> Show View -> Servers -> Servers

The following shows where you can start, stop and restart your server.

Now you are ready to go!

Step 2 - Install Axis 2

Apache Axis2 is a popular open source webservice framework. Axis2 uses Stax based XML parsing and uses internally the Axiom object model to represents the XML message. Based on this object model Axis2 provides an adapter which is Jax-WS compliant. We detail here how to install it and how to configure Axis 2 within Eclipse.

Installation of Axis 2

Currently Axis 2 1.5 is not supported. Make sure you download Axis 1.4.1 which can be found here Axis 2 1.4.1. Download
This chapter requires an Axis2 runtime, the general download site is here.
Extract the Axis 2 zip and point Eclipse WTP on it as shown below.
Currently Axis 2 1.5 is not supported. Make sure you download Axis 1.4.1, which can be found here Axis 2 1.4.1. Download.

Extract the Axis 2 zip and point Eclipse WTP on it as shown below.

Click OK. Select Window -> Preference and set Axis2 as the default engine.

Now you are ready to go!

Step 3 - Import Eclipse Project

Download the Filtering Service project here.
Go to File->Import->General->Existing Projects into Workspace

Click Next and Select archive file. Select the downloaded zip and click finish.

Now you have the project with the Filtering Service inside.

Step 4 - Start Filtering Service

Now you are ready to start the Web Service for the imported project. In Eclipse, right click on "Filtering.java" (within src/edu.upc.gemece.filtering package) and select Web Services -> Create Web Service.

Make sure the selected Web service runtime is Apache Axis2. If not, click on the link Web service runtime: Apache Axis2 and select Axis2. 

Press next.

Click "Next". If your server is not running, you will see this dialog. Click "Start server", wait a few seconds and then click "Next".

If no error occurs, click "Finish". Congratulations! You started the Filtering Web Service. That was easy!

Step 5 - Start Filtering Client

Once the service is ready to be consumed, we need to download the Filtering Client and unzip it into a web server that supports PHP (for example, a local Apache server with PHP). Then, inside the filter folder you find the start.php file. Execute it by typing "php start.php" in a console or by visiting the start.php file through your web browser. If everything works well, the service and client are now ready to be used. Open the index.html file within the client directory you already unzipped and continue with the usage instructions that can be found here to start filtering a large schema.

Ús

 

Reminder: First of all, follow the instructions here to prepare the environment.

The Filtering Engine provides the following filtering requests:

The prototype of the Filtering Engine for Large Conceptual Schemas includes the implementation of the filtering requests from the filtering catalog introduced in Ch. 6 of this thesis following a web-service oriented architecture. Our prototype provides functionality to extract a portion of the knowledge of the Magento conceptual schema.

Magento is a full-fledged, open source e-commerce platform aimed at web site designers, developers, and business owners who are looking for a complete e-commerce web site solution. The Magento system provides the scalability, flexibility and features for business growth. The structural subschema of Magento contains 218 entity types and 983 attributes. On the other hand, the behavioral subschema contains 187 event types and 69 pre- and postconditions specifying the effect of events. Furthermore, the conceptual schema connects its elements through a set of 319 relationship types and 165 generalization relationships, and includes 386 integrity constraints, 185 derivation rules, 15 data types, and 46 enumeration types.

Such schema is pre-loaded in the schema manager service of the prototype. Next screenshot shows the conceptual schema of Magento:

F1 - Filtering Request for Entity and Relationship Types
F2 - Filtering Request for Schema Rules
F3 - Filtering Request for Event Types
F4 - Filtering Request for A Conceptual Schema
F5 - Filtering Request for Context Behavior of Entity Types
F6 - Filtering Request for Contextualized Types

F1 - Filtering Request for Entity and Relationship Types

The first filtering request focuses on a set of (one or more) entity and relationship types from a large conceptual schema and returns the corresponding filtered schema with the knowledge of interest to the user.

In our implementation we provide users with a web-based interface to ease the construction of the focus set. The user is able to include entity and relationship types into the focus set through three different components.

First of all, we construct a word cloud with the top-25 most relevant entity types of Magento where more relevant ones are depicted in a larger font size. This format is useful for quickly perceiving the most prominent entity types by inexperienced users. Selecting a single entity type name within the word cloud, includes such entity type in the focus set.

Alternatively, the interface contains a search bar, which provides an auto-completing functionality that helps discovering the names of the existing entity and relationship types of Magento. The names of the selected entity and relationship types are shown in the search bar.

In addition to it, we include an alphabetical list to explore all the entity and relationship types of Magento. The user selects a single letter of the English alphabet from the list and then obtains an enumeration of those entity and relationship types whose name starts with that letter. The user may select the entity or relationship types of interest, which are then included in the search bar. Note that we preceded each item in the alphabetical list with an icon showing the type of the schema element (entity type, relationship type, or association class).

The user may also select the final size of the filtered schema in order to indicate the amount of knowledge she wants to obtain as a result. As an example, next screenshots shows the filtering prototype when the user selects the association class ActivityInfoOfCustomerInStoreView as the input focus set. By using our prototype, the user discovers that such association class is a binary association, whose aparticipants are Customer and StoreView. Also, she obtains the rolenames (customerWithInfoAbout and storeViewWithInfoAbout) that may allow her construct additional OCL navigations, the multiplicities (0..* in both sides), the attributes of each element, and a referentially-complete invariant in the context of StoreView.

F2 - Filtering Request for Schema Rules

The second filtering request focuses on a set of (one or more) schema rules from a large conceptual schema and returns the corresponding filtered schema with the knowledge of interest to the user.

In our implementation we provide users with a web-based interface to ease the construction of the focus set. The user is able to include schema rules into the focus set through three different components.

First of all, we construct a word cloud with the top-25 most relevant entity types of Magento where more relevant ones are depicted in a larger font size. This format is useful for quickly perceiving the most prominent entity types by inexperienced users. Selecting a single entity type name within the word cloud, includes all the schema rules defined in the context of such entity type in the focus set.

Alternatively, the interface contains a search bar, which provides an auto-completing functionality that helps discovering the names of the existing entity and event types of Magento. The names of the selected entity and event types are shown in the search bar, and all their schema rules are included in the focus set.

In addition to it, we include an alphabetical list to explore all the entity, event, and relationship types of Magento that define schema rules. The user selects a single letter of the English alphabet from the list and then obtains an enumeration of those entity and relationship types whose name starts with that letter. Note that we preceded each item in the alphabetical list with an icon showing the type of the schema element (entity type, event type, relationship type, or association class).

The user may also select the final size of the filtered schema in order to indicate the amount of knowledge she wants to obtain as a result, or alternatively, set the scope of the request to local in order to only obtain those elements referenced by the rules of focus. As an example, the next screenshots shows the filtering prototype when the user selects the post-condition createInvoice of theeffect() operation of the event type AddInvoice. By using our prototype, the user discovers the elements referenced by that schema rule taking into account that the scope was set to local. Concretely, the user may discover that the post-condition describes the behavior to generate a new instance of Invoice, including the way to set the values of the attributes of the new Invoice, and how to relate it with new instances of InvoiceLine that match the instances of OrderLine of the current Order of that event.

F3 - Filtering Request for Event Types

The third filtering request focuses on a set of (one or more) event types from a large schema and returns the corresponding filtered schema with the knowledge of interest to the user.

In our implementation we provide users with a web-based interface to ease the construction of the focus set. The user is able to include event types into the focus set through three different components.

First of all, we construct a word cloud with the top-25 most relevant event types of Magento where more relevant ones are depicted in a larger font size. This format is useful for quickly perceiving the most prominent event types by inexperienced users. Selecting a single event type name within the word cloud, includes such event type in the focus set.

Alternatively, the interface contains a search bar, which provides an auto-completing functionality that helps discovering the names of the existing event types of Magento. The names of the selected event types are shown in the search bar.

In addition to it, we include an alphabetical list to explore all the event types of Magento. The user selects a single letter of the English alphabet from the list and then obtains an enumeration of those event types whose name starts with that letter. The user may select the event types of interest, which are then included in the search bar.

The user may also select the final size of the filtered schema in order to indicate the amount of knowledge she wants to obtain as a result. As an example, next screenshots show the filtering prototype when the user selects the event type AddProductToWishlist as the input focus set. By using our prototype, the user discovers that such event type is a descendant from the abstract event types ExistingProductEvent and ExistingCustomerEvent, which indicates thatAddProductToWishlist is an event type that deals with products and customers. In fact, the filtered schema shows thatExistingProductEvent is associated to an instance of the entity type Product, and that thereforenbsp;AddProductToWishlistinherits that association. Also, the user obtains a referentially-complete invariant which states that each instance of Productis identified by the value of the attribute sku.

F4 - Filtering Request for A Conceptual Schema

The fourth filtering request focuses on a small schema obtained through the application of any of the other filtering requests from the catalog. That small schema is a filtered conceptual schema that the user wants to extend in order to obtain additional knowledge from the original large schema with higher relation to the schema elements contained in the filtered schema.

In our implementation we provide users with a web-based interface to ease the construction of the focus set. The user is able to include elements from a filtered schema into the focus set through two different components.

First of all, we provide users with an interactive graphical visualization of the filtered conceptual schema through a HTML5/Javascript library. Users are able to directly interact with the filtered schema by changing the position of elements (drag & drop). Also, users may select a set of (one or more) schema elements from the filtered schema and include them into the focus set for the application of the fourth filtering request.

Alternatively, the user may type the name of the desired entity or event types of focus in the search bar, which provides an auto-completing functionality. Therefore, the user can refine the focus set in order to combine the selection of elements from the filtered schema with the selection of additional elements from the large schema according to specific information needs.

Once the focus set is complete, the user clicks the Explore button to start the new filtering request and obtains the corresponding filtered schema. In the next screenshots, the interface shows a filtered schema where the focus was on the entity type Refund. The schema presents a Refund as a descendant of the abstract entity type Commentable, associated to instances of RefundLine, and that a Refund belongs to the Order to which it is related, which is also a descendant ofCommentable. In addition to it, the filtered schema shows three invariants.

On the other hand, the input in the example contains the schema including the four entity types from the previous step. The result includes the same elements as in the input schema (marked with a darker color) and two additional entity types of high relevance to them: Website and StoreView. Also, that schema contains two additional referentially-complete invariants.

Therefore, the interaction between the user and our proposed prototype results in an iterative process that must be applied as many times as required. The process ends when the user believes that she has obtained enough knowledge from the large schema to cover the specific information need, or wants to apply a different filtering request.

F5 - Filtering Request for Context Behavior of Entity Types

The fifth filtering request focuses on a set of (one or more) entity types from a large schema and returns the corresponding filtered schema with the event types of interest to the user.

In our implementation we provide users with a web-based interface to ease the construction of the focus set. The user is able to include entity types into the focus set through three different components.

First of all, we construct a word cloud with the top-25 most relevant entity types of Magento where more relevant ones are depicted in a larger font size. This format is useful for quickly perceiving the most prominent entity types by inexperienced users. Selecting a single entity type name within the word cloud, includes such entity type in the focus set.

Alternatively, the interface contains a search bar, which provides an auto-completing functionality that helps discovering the names of the existing entity types of Magento. The names of the selected entity types are shown in the search bar.

In addition to it, we include an alphabetical list to explore all the entity types of Magento. The user selects a single letter of the English alphabet from the list and then obtains an enumeration of those entity types whose name starts with that letter. The user may select the entity types of interest, which are then included in the search bar.

The user may also select the final size of the filtered schema in order to indicate the amount of knowledge she wants to obtain as a result. As an example, the next screenshots show the filtering prototype when the user selects the entity type Address as the input focus set. By using our prototype, the user discovers the set of event types that are related to such entity type.

Therefore, we observe in the resulting filtered schema that the event types DeleteCustomerAddress and EditCustomerAddress make use of the entity type Address for their specification. Also, the event type OrderConfirmation is related to two instances of Address for the roles of billing and delivery, which indicates that in Magento orders of products require a billing address and a delivery address.

F6 - Filtering Request for Contextualized Types

The sixth filtering request focuses on a set of (one or more) entity and event types from a large conceptual schema and returns the corresponding filtered schema with the knowledge of interest to the user when applying a contextualization function.

In our implementation we provide users with a web-based interface to ease the construction of the focus set. The user is able to include entity and relationship types into the focus set through three different components.

First of all, we construct a word cloud with the top-25 most relevant entity and event types of Magento where more relevant ones are depicted in a larger font size. This format is useful for quickly perceiving the most prominent entity and event types by inexperienced users. Selecting a single entity or event type name within the word cloud, includes such entity or event type in the focus set.

Alternatively, the interface contains a search bar, which provides an auto-completing functionality that helps discovering the names of the existing entity and event types of Magento. The names of the selected entity and event types are shown in the search bar.

In addition to it, we include an alphabetical list to explore all the entity and event types of Magento. The user selects a single letter of the English alphabet from the list and then obtains an enumeration of those entity and event types whose name starts with that letter. Each item in the list shows also its attributes and participations in relationships. The user may select the entity or event types of interest, which are then included in the search bar, and additionally change the multiplicities of (some of) their attributes or participations in relationships, or even select default values for those attributes whose type is an enumeration. Note that we preceded each item in the alphabetical list with an icon showing the type of the schema element (entity type, event type, participation in relationship type, or owned attribute). By changing multiplicities of selecting default values the user applies a contextualization function.

The user may also select the final size of the filtered schema in order to indicate the amount of knowledge she wants to obtain as a result. As an example, next screenshots show the filtering prototype when the user selects the entity type BundleProduct as the input focus set and selects a default value for its owned attribute priceMethod. By using our prototype, the user discovers that such entity type descends from the entity type Product, and that is related to the entity types Website and SCItemOfBundleProduct. Note that the attribute priceMethod of BundleProduct shows its default value as Static.

Quant a

Documentació

 

Presentation

Related publications

Contacte

For any question or suggestion, feel free to contact us by sending an email to avillegas@essi.upc.edu

Treball Futur

Suggeriments

 

In the following, we suggest some future work to be done regarding the evolution of the Filtering Engine for Large Conceptual Schemas:

  • Validation with real users of large conceptual schemas.
  • Extend the relevance metrics taking into account instances.
  • Extend the filtering catalog with addition filtering requests.
  • Combine the filtering methodology with existing approaches from the literature.