The FAST Gagdet Ontology v0.3 (M36)

Copyright © 2007-2011 FAST Project Consortium (FP7-ICT-2007-1-216048).

This work is licensed under a Creative Commons Attribution License. This copyright applies to the FAST Gadget Ontology (FGO) and accompanying documentation in RDF. Regarding underlying technology, FGO uses W3C's RDF technology, an open Web standard that can be freely used by anyone.

Introduction

The EU FAST Project (FP7-ICT-2007-1-216048) sets out to develop end-user-focussed tools for building intelligent, interconnected Web gadgets. In a visual development environment, users can drag & drop building blocks, customise them and link them together to create their own, custom-built gadget, which they can then deploy to a gadget platform like iGoogle or EZWeb.

Internally, each gadget and its building blocks are defined in RDF, using the terminology defined by this document: the FAST gadget ontology (FGO). The overview section lists all classes and properties defined in the FGO. For a more detailed introduction to FAST (including a more extensive PDF version of the FGO documentation), its architecture, software prototypes, etc., we would like to direct you to the collection of FAST Documentation documents.

The Basic Conceptual Model

One of the main ideas of FAST is that each gadget consists of so-called screens: individual units of interaction, which the user of the gadgets visits one after the other. E.g., in a gadget for buying something in an online store, there could be a login screen, followed by a search screen, a selection screen and finally a check-out screen. Each screen has its own building blocks, such as a form or a any number of operators. In order for the screens to interact with services like the online store, they are linked to resources, which are basically wrappers around backend web services. Several screens together build a so-called screenflow, which can then be packaged and deployed as the actual gadget the end user will see. The layering of all these basic concepts can be seen in the figure below.

The next figure looks closer at the features of individual screens. These are forms, resources and operators, which are all specialisations of the general screen_component concept. Each such screen component may or may not have an action or trigger associated with them, which declaratively define their behaviour in terms of their own functionality or functionality they can trigger in other building blocks.

Regarding their implementation, different kinds of building blocks in FAST can either be defined hard-coded as a piece of source code, or they can be defined declaratively in the terms of the FAST ontology (using pipes, operators, etc.). In the former case, a building block such as a screen would have been implemented and added to the FAST platform by an engineer, whereas in the latter case, ordinary users of the FAST platform would have assembled the building block using the tools available in the GVS. This principle is reflected in the figure below, showing how certain kinds of building blocks aggregate either a Definition or Code, whereas other kinds of building blocks are always hard-coded. It should be noted that, in theory, there is no reason why not any kind of building block could be defined either way. However, the concrete set of building blocks which can be defined declaratively or in code is changing dynamically according to the current state and plans of the FAST project.

Another central concept in FAST is the idea that, rather than explicitly defining the order in which screens are shown to the user in a gadget, the order is determined automatically. This happens through the use of pre-conditions and post-conditions: a screen will only show up once all its pre-conditions are fulfilled, and it will produce post-conditions for other screens once the user is done with it. This idea is extended from screens to other kinds of building blocks in FAST, to determine the general flow of data. The figure below illustrates how the different kinds of building blocks relate to the concepts of pre- and post-conditions. While all building blocks can essentially have such conditions, only screens and screen flows directly aggregate both. However, in the case of the three different kinds of screen components (form, resource and operator), the relation to a pre-condition is only established through their actions, which represent their basic functionality. For all building blocks, both pre- and post-conditions are entirely optional.

This ontology defines terms for modelling semantic, interoperable gadgets or widgets. It has been developed as part of the EU project 'FAST' (FAST AND ADVANCED STORYBOARD TOOLS), FP7-ICT-2007-1-216048.

Overview

Classes

Class: `Action`

Label	Action
sub-class-of	`fgo:BuildingBlock`
in-range-of	`fgo:hasAction`
status	testing

An action represents a specific routine which will be performed when a certain condition is fulfilled within a certain screen component. Examples are methods of a Web service (e.g., getItem) or functionality to update or change the contents of a form.

Look for usage of this class on Sindice.

Class: `BackendService`

Label	Backend Service
sub-class-of	`fgo:BuildingBlock`
status	testing

A Web service which provides data and/or functionality to a screen. The actual backend service is external to FAST, and only available through a wrapper (the service Resource).

Look for usage of this class on Sindice.

Class: `BuildingBlock`

Label	BuildingBlock
super-class-of	`fgo:Action`, `fgo:BackendService`, `fgo:Condition`, `fgo:FormElement`, `fgo:Library`, `fgo:Pipe`, `fgo:Screen`, `fgo:ScreenComponent`, `fgo:ScreenFlow`, `fgo:Trigger`
in-domain-of	`fgo:contains`, `fgo:hasClone`, `fgo:hasIcon`, `fgo:hasPrototype`, `fgo:hasScreenshot`, `fgo:uses`
in-range-of	`fgo:contains`, `fgo:hasClone`, `fgo:hasPrototype`
status	testing

Anything that is part of a gadget. Tentatively anything that can be 'touched' and moved around in the FAST IDE, from the most complex units such as screen flows, down to atomic form elements like a button or a label in a form.

Look for usage of this class on Sindice.

Class: `Condition`

Label	Condition
sub-class-of	`fgo:BuildingBlock`
in-domain-of	`fgo:hasPattern`, `fgo:hasPatternString`, `fgo:isPositive`
in-range-of	`fgo:from`, `fgo:hasPostCondition`, `fgo:hasPreCondition`, `fgo:to`
status	testing

The pre- or post-condition of a building block. If the building block is a screen flow, each target platform will use these conditions in its own way, or may also ignore them. E.g., in EzWeb pre- and post-conditions correspond to the concepts of slot and event. A condition is made up of individual facts, where each fact is represented internally as an RDF triple, usually involving a variable of blank node.

Look for usage of this class on Sindice.

Class: `Form`

Label	Form
sub-class-of	`fgo:ScreenComponent`
in-domain-of	`fgo:hasFormElement`
in-range-of	`fgo:hasForm`
status	testing

A form is the visual aspect of a screen: its user interface. Each form is made up of individual form elements.

Look for usage of this class on Sindice.

Class: `FormElement`

Label	Form Element
sub-class-of	`fgo:BuildingBlock`
in-range-of	`fgo:hasFormElement`
status	testing

Form elements are UI elements in a particular screen, such as buttons, lists or labels.

Look for usage of this class on Sindice.

Class: `Library`

Label	Library
sub-class-of	`fgo:BuildingBlock`
in-domain-of	`fgo:hasLanguage`
in-range-of	`fgo:hasLibrary`
status	testing

Libraries are references to external code libraries required for the execution of a particular building block at runtime.

Look for usage of this class on Sindice.

Class: `Operator`

Label	Operator
sub-class-of	`fgo:ScreenComponent`
in-range-of	`fgo:hasOperator`
status	testing

Operators are intended to transform and/or modify data within a screen, usually for preparing data coming from service resources for the use in the screen's interface. Operators cover different kinds of data manipulations, from simple aggregation to mediating data with incompatible schemas.

Look for usage of this class on Sindice.

Class: `Pipe`

Label	pipe or connector
sub-class-of	`fgo:BuildingBlock`
in-domain-of	`fgo:from`, `fgo:to`
status	testing

Pipes are used to explicitly define the flow of data within a screen, e.g., from service resource to operator to a specific form element.

Look for usage of this class on Sindice.

Class: `Resource`

Label	Resource
sub-class-of	`fgo:ScreenComponent`
in-range-of	`fgo:hasResource`
status	testing

A service resource in FAST is a wrapper around a Web service (the backend service), which makes the service available to the platform, e.g., by mapping its definition to FAST facts and actions.

Look for usage of this class on Sindice.

Class: `Screen`

Label	Screen
sub-class-of	`fgo:BuildingBlock`
in-domain-of	`fgo:hasForm`, `fgo:hasOperator`, `fgo:hasResource`
status	testing

An individual screen; the basic unit of user interaction in FAST. A screen is the interface through which a user gets access to data and functionality of a backend service.

Look for usage of this class on Sindice.

Class: `ScreenComponent`

Label	Screen Component
super-class-of	`fgo:Form`, `fgo:Operator`, `fgo:Resource`
sub-class-of	`fgo:BuildingBlock`
in-domain-of	`fgo:hasAction`, `fgo:hasTrigger`
status	testing

Screens are made up of screen components, which fundamentally include service resources, operators and forms.

Look for usage of this class on Sindice.

Class: `ScreenFlow`

Label	Screen Flow
sub-class-of	`fgo:BuildingBlock`
status	testing

A set of screens from which a gadget for a given target platform can be generated.

Look for usage of this class on Sindice.

Class: `Trigger`

Label	Trigger
sub-class-of	`fgo:BuildingBlock`
in-range-of	`fgo:hasTrigger`
status	testing

Triggers are the flip-side of actions. Certain events in a building block can cause a trigger to be fired. Other building blocks within the same screen, which are listening to it, will react with an action.

Look for usage of this class on Sindice.

Class: `WithCode`

Label	With Code
union-of	`fgo:Form`, `fgo:Operator`, `fgo:Resource`, `fgo:Screen`
in-domain-of	`fgo:hasCode`, `fgo:hasLibrary`
status	testing

Any kind of building block that can be defined as a whole through code.

Look for usage of this class on Sindice.

Class: `WithDefinition`

Label	With Definition
union-of	`fgo:Form`, `fgo:Screen`
status	testing

Any kind of building block that can be defined declaratively in the GVS.

Look for usage of this class on Sindice.

Class: `WithPostConditions`

Label	With Post-condition
union-of	`fgo:Screen`, `fgo:ScreenComponent`, `fgo:ScreenFlow`
in-domain-of	`fgo:hasPostCondition`
status	testing

Those kinds of building blocks which can have post-conditions.

Look for usage of this class on Sindice.

Class: `WithPreConditions`

Label	With Pre-condition
union-of	`fgo:Action`, `fgo:Screen`, `fgo:ScreenFlow`
in-domain-of	`fgo:hasPreCondition`
status	testing

Those kinds of building blocks which can have pre-conditions.

Look for usage of this class on Sindice.

Properties

Property: `contains`

Label	contains
Type	`owl:ObjectProperty`
super_property_of	`fgo:hasForm`, `fgo:hasFormElement`, `fgo:hasOperator`, `fgo:hasResource`
domain	`fgo:BuildingBlock`
range	`fgo:BuildingBlock`
status	testing

Many kinds of components in FAST can contain other components: screenflows contain screens, screens contain forms, operators and resources, forms contain form elements, etc.