Introduction

Within Semantic Components, there exists a strong relationship between record descriptions and the components of the layout of an application. In fact, in many cases, attributes describing records get bound to elements (components) of an application layout. This is one nature of the semantic component: they behave according to the target record(s), attribute(s) for given schema(s). This combination is what we call the Semantic Component Layout.

 Schema

Interaction between a resultset and a semantic layout

The schema above shows the interaction between four major pieces of the Semantic Component Library:

1. Target Resultset
2. Application (MXML) Layout
3. Schema
4. Rendered User Interface

The general purpose of an application that uses the Semantic Component Library is to interact with a structWSF instance to get resultsets of records for some given request, and to interact/display them in some useful user interface. An application is generally composed of multiple pieces, and not each piece is related to the semantic components.

The schema above shows a part of such an application: it gets a record description from a structWSF endpoint (the target resultset), and it feeds it to a canvas [the application (mxml) layout] that is composed of multiple components (semantic or otherwise). This canvas tries to display all of the information it has received about the record to the user via the rendered user interface. The schema is used to automatically bind attributes and their values to specific rendering components.

As explained in the sGenericBox tool documentation page, the generic box only tries to display the attribute/values of a record that have not been bound to any other component of the layout. It is what you can notice in the schema above: all of the attributes that have not been bound to any other semantic component get displayed in the generic box. (In this sense, then, the sGenericBox acts as a "catch all" to display information that is not otherwise specified to be displayed with a specific widget.)

All of this residual information in the example above gets rendered using the sText component, except for the thumbnail that has been rendered using the sImage control according to the schema used to describe the subject of the resultset.

To see better how this works, let's take a look at the interaction between a semantic application canvas, and the generic box:

Interaction between the sGenericBox and the sHBox

In the schema above, we see that the parent canvas of the generic box is an sHBox. This semantic HBox is the application layout component where all of the components used to display information about a specific record are defined. In this case, we say that a record X is "bound" to a canvas Y. In this case, the canvas Y is the sHBox component. This component will check what attribute(s) of the record has been bound to what child components. Then, once it determines what attributes have been bound, and which ones are still unbound, it creates the sGenericBox to displays all of the remaining values of the unbound attributes.

For its part, the sGenericBox takes all of the unbound attributes as targetAttributes, and creates an sControl for each of the unbound attribute. Then, the sControl tries to bind each of the unbound attributes to a semantic component, according to the input schema. In the worse case, the value of the attribute will be rendered with a sText control.

This cascading mechanism ensures that specific data and structure (schema) get rendered with their most tailored component, but each fallback step also directs the rendering to the next appropriate tier of presentation display.

Application developers can specify what control should be bound to what attribute (bound variables in the MXML layout). Or the application developer can specify what attribute is supposed to be bound to what semantic control in the schema (foaf_thumbnail description in the schema).

Normally, the data publisher that uses a structWSF instance to publish its data will use the SCO ontology to specify how he thinks that his data should be rendered by applications (in this case, using the semantic component library). Yet, if only the schema is used in an application, it will still comply to the data publisher's rules to display that information (using what visualization tool). However, the application developer always has the control and latitude to re-define that schema that comes with the data source (structWSF instance), or to redefine the behavior directly in the description of the application layout (MXML file) by using the bound variables.