New Mapping Semantic Component In JavaScript

Frederick Giasson

 

I am please to announce the release of the new sWebMap Semantic Component in JavaScript. This new mapping component is a standalone JavaScript application that can be integrated on any new or existing web sites and that interact with an Open Semantic Framework (OSF) instance to search, browse, filter and display with geographically-located information on an interactive map.

Features

The sWebMap is a rich mapping tool that can easily be integrated on any webpage, and that can be extensively customized. The sWebMap does support these features:

  • Full text search for searching and displaying results on a map
  • Extensive filtering capabilities
    • Filtering by dataset source
    • Filtering by type
    • Filtering by attribute/value
    • Filtering of records that belongs to a specific geographic region
  • Display of record on the map using:
    • Different markers depending on the type of record to display (determined by the ontologies)
    • Polygon shapes for records that refers to a geographic region
    • Polyline shapes for records that refers to a geographically-located path
  • Templating of records in a resultset depending on their type
  • Templating of records’ preview, displayed in an overlay window, depending on their type
  • Persist records on the map accros searches and filtering operations
  • Supports map sessions
    • Save map sessions
    • Load saved map sessions
    • Delete saved map sessions
    • Share saved map sessions
  • Supports a multiple-maps mode
    • Three focus maps are available under the main map
    • Each map focus on a particular region of the main map
    • User can switch between focus map to see different records in different region

 

Normal Mode

Here is what the default sWebMap, in normal mode, using a few datasets related to the city of Iowa looks like. You can also interact with this sWebMap instance directly on the Citizen DAN demo website here.

Multiple Windows Mode

Here is what the default sWebMap, in multiple windows mode, using a few datasets related to the city of Iowa looks like. You can also interact with this sWebMap instance directly on the Citizen DAN demo website here.

 

 

Under the Hood: The Open Semantic Framework

Each sWebMap component communicates with an OSF (Open Semantic Framework) instance. More specifically, a sWebMap component will send Search/Filtering queries to a geo-enabled structWSF Search web service endpoint.

Depending on the options you had specified when you created the sWebMap control, each time you move (option), zoom (option) or change the filtering criterias, this will send a query to the Search endpoint. The sWebMap control then requests JSON formatted resultset and display the results to the user.

This means that to implement the sWebMap component on your website, you will need to have:

Download

You can immediately download the entire code source from this GitHub reposiroty:

Installation

Installing the sWebMap component is really easy. In fact, you only have to load a few JavaScript and CSS files, to defined a <div></div> container for the map, and to create a sWebMap component object, which is a single line of code.

Additionally, you can initialize the sWebMap component with one of the multiple options available.

Refer you to the Usage section of the sWebMap component to know exactly how to install and setup a sWebMap component instance.

Resources

Here are some additional resources related to the sWebMap component:

 

Semantic Components : the Genesis

Frederick Giasson

Everything started with this prototype: structSearch. The goal was to figure out if Flex, and some of its open source libraries, were about to make a good data visualization framework for Structured Dynamics. As it turned out, it was making more than a good data visualization framework, as the Semantic Component Library is now one of the central libraries maintained by Structured Dynamics.

It was about one year ago.

But it is more than a demo, it is more than just a new data visualization framework. It is a set of technologies, it is a process by which you can do data integration, management, publication and visualization faster, better and for a fraction of the price. It is what we do at Structured Dynamics, and we hope continuing to share our findings to help communities to move faster, better and for the best.

What we do here is to demonstrate one of the facet of this new architecture.

strutSearch

The structSearch demo is interesting because it is a good example of what we call an Ontology Driven Application. Basically, the user interface of the application behave differently depending of the data that it gets as input.

In the example below, the structSearch tool gets all its data from a call to a structWSF instance where the Semantic Sweet Tools List dataset is hosted. You can try a search with the acronym “rdf“:

[kml_flashembed publishmethod=”static” fversion=”10.0.0″ movie=”http://fgiasson.com/flex/demos/structSearch/structSearch.swf” width=”500″ height=”700″ targetclass=”flashmovie” fvars=”baseAppUrl=http://fgiasson.com/flex/demos/structSearch/”]Get Adobe Flash player

[/kml_flashembed]

Note: if you have issues loading this Flash movie, it may be because the feed reader you are using, and what it does with some of the code within this blog post. I would suggest you to go to the website directly to experiment this tool.

How it works

The general workflow is somewhat simple; it is composed of only three parts:

1.����� A Resultset (which is composed of one or multiple records descriptions)

2.����� An application layout (a MXML file)

3.����� And a rendered user interface

These three steps are shown in this image (click to enlarge):

Semantic Component Layout
Semantic Component Layout

The complete process is discussed on the TechWiki. The structSearch demo leverages one of the semantic components: the sGenericBox. This box is a generic record infobox: it tries to display all the information related to a record�s description that is not handled by any other part of the application layout layer. So, most of the attributes/values are handled by the application, but for all the remaining, unhandled, attribute/values, they get listed in the generic box.

What is interesting with this three steps workflow that the users starts with one thing: a set of attributes/values describing a record. Then, they build a user interface that binds different attributes to controls that will be used to display their values. Finally, depending on a record’s description, and the application layout, the user interface generated will looks like/behave differently.

Why?

There is no magic in there, and the idea of adaptive user interfaces is certainly not new. However, what I think that people should keep in mind after reading this blog post is that the this specific workflow, along with these specific technologies helps the: integration, management, publication and visualization of different data sources. I hear you saying: yes and what? There are hundred of systems that tries to do this. Yes, that is true. But I would answer to that question with another question: yes, but at what price? By this I mean: can you develop as quickly and effectively as you could with these new methods, processes and technologies?

At least, this is what we figured out.

fvars

Semantic Components

Frederick Giasson

For few months now at Structured Dynamics we have been developing what we call “Semantic Components“. A semantic component is an ontology-driven component, or widget, based on Flex. Such a component takes record descriptions, ontologies and target attributes/types as inputs and outputs some (possibly interactive) visualizations of the records. Depending on the logic described in the input schema and the input records descriptions, the semantic component may behave differently to optimize its own layout/behavior to users.

The purpose of these semantic components is to have a framework of adaptive user interfaces that can be plugged directly to structWSF Web service endpoint instances. The goal is to plug some data, schema and target attributes into these components, and then to let them change their behaviors and appearances depending on the input data and schema.

The picture is simple. We tell the components: here is a set of records serialized in structXML, here is a set of schema serialized in irXML, and here are the target attributes and types I want the components to display. Then, different components get selected and behave differently depending on how the schema have been defined, and how the records have been described.

Ultimately, development time is saved because developers don’t have to hard-code the appearance and the behavior of the user interfaces depending on the data and schema that the user interface was receiving at a certain point in time: the logic is built-in to the components.

Overall Workflow

These various semantic components get embedded in a layout canvas. By interacting with the various components, new queries are generated (most often as SPARQL queries) to the various structWSF Web services endpoints. The result of these requests is to generate a structured results set, which includes various types and attributes.

An internal ontology that embodies the desired behavior and display options (SCO, the Semantic Component Ontology) is matched with these types and attributes to generate the formal instructions to the semantic components. These instructions are presented via the sControl component, that determines which widgets (individual components) needs to be invoked and displayed on the layout canvas.

Semantic Components Framework

New interactions with the resulting displays and components cause the iteration path to be generated anew, again starting a new cycle of queries and results sets.

As these pathways and associated display components get created, they can be named and made persistent for later re-use or within dashboard invocations.

A Shift in Design Perspective

There is a bit of a user interface design shift here. User interfaces have always been developed to present information (data) to users, and to let them interact with it. When someone develops such an interface, he has to make thousands of decisions to enable the user interface to cope with different data description situations. Our semantic component framework tries to remove some of this burden on the shoulders of the designer so that it takes these decisions itself. Such decisions are in the range of:

  • The text control X displays the value of an attribute Y. If the attribute Y doesn’t exist in the description of a record A, then we have to remove it from the user interface.
    • Note: if the text control X gets removed from the interface, there is a good chance that we may have to change other controls as well so that the user interface remains usable to the users.
  • If the text control X gets removed, then there is no reason why its associated icon image should remain in the user interface, so let’s provide accommodations to remove it as well.
  • Some attributes describing the records have values that are comparable with related attributes, so let’s compare these values in a linear chart
  • Some records may be useful baselines for comparison with other records, so let’s allow that to be externally specified, too.
  • All these decisions are true for record A, but not for record B since we have a value to display for the text control X, so let’s behave differently by displaying the text control X and its associated icon image.
  • Etc.

All of these kinds of decisions are now made by the semantic components within our new framework depending on how the input records are described and what ontologies (schema) drive the system.

Thus, the designer can now put more time and effort on the questions of general layout and behavior, themes and styles for her applications, without caring much about how to display information for specific records descriptions.

Perhaps most significantly is that the behavior and presentation of information can now be described within these records and schema, an activity that users and knowledge workers can do directly, thus bypassing the need for IT and development. A new balance gets established: developers focus on creating generic tools (widgets or components); consumers of data (users and knowledge workers) determine how they want to display and compare their information.

Unbelievably Fast Implementation

While this shift or change may appear on its face to require some big new framework, the fact is we have been able to accomplish this with simple approaches leading to simple outcomes. Structured Dynamics has been able to put in place a complete Web portal of integrated data that publish all its data in several serialization languages, with many utilities by which users can interact with the data, slice and dice it, visualize it, and filter and manipulated it … and all of this in within two weeks of effort for one developer!

One good example of this is the Citizen Dan demo, composed of Census data and stories related to the Iowa City Metropolitan Area that Mike presented at SemTech 2010 (and some screenshots).

Oh, and did I mention? This system handles text, images, tags, maps, dashboards, numeric data and any kind of structure you can throw at it. And all with the same set of generic components (to which we and others are adding).

More Information

Here is some more information about the semantic component framework and its related pieces:

This is an alpha version of the library. We would also welcome any contributor to the project! We hope you like what you see and that you will be able to leverage it the way we did so that you, and your team, can save as much time as we did!