Synth

Synth is a development environment for building applications that are modeled

according to SHDM method. It provides a set of modules that receives, as input, models
generated on each step of SHDM and produces, as output, the hypermedia application
described by these models. Synth also provides an authoring environment that facilitates
the adding and editing of these models by a GUI that can run on any web browser.

A modular software architecture

A modular software architecture [Gauthier & Ponto, 1970; Parnas, 1972] was
designed, regardless of implementation technology, supporting the development of
applications modeled by SHDM. This software architecture consists of a set of modules,
each one responsible for maintaining and interpreting the models generated in each step
of SHDM. Each module is composed by an ontology in RDFS or OWL, for the
representation of their models, and an interpreter that gives semantics to these models,
besides the basic semantics of RDFS and OWL languages in which they are represented.
These modules work together, interpreting their models and communicating with each
other to generate the application runtime in accordance with the definitions of each
model.
Figure 1 shows a conceptual view of the modular software architecture for
applications modeled by the method SHDM. The gray boxes with rounded corners
represent the modules and the white boxes represent the components of each module.

interprets

uses

Business Logic
Model
Interpreter

uses

Interfaces
Model
Interpreter

Domain
Model

Naviga on
Model
Interpreter

Domain
Ontology

Naviga on
Model

Business Logic
Model

Interfaces
Model

Naviga on
Ontology

Business Logic
Ontology

Interfaces
Ontology

Naviga onmodule

BusinessLogicmodule

Interfacesmodule

Domainmodule
Legenda
query
queryor
store
vocabulary

RDF(S)/OWLmappinglayer
Framework RDF 1

FrameworkRDF 2

FrameworkRDF N

Store, inferencesand querylayer

Persistencemodule

Figure 1 Conceptual view of the software architecture

The persistence module deals with access and manipulation of application data.
This module is composed of two layers: a storage, inferences and query layer and a
RDF(S)/OWL mapping layer.
The storage, inferences and query layer provides a unique interface for access
multiple environments and platforms for RDF data. By applying the Adapter design
pattern [Gamma et al., 1995], this layer converts the access interfaces of RDF data
environments in a single interface known by the RDF(S)/OWL mapping layer. As
examples of RDF data environments, we can mention Jena 1 and Sesame2 frameworks and
databases that implement the SPARQL3 protocol (SPARQL Endpoints). The storage,
inferences and query layer should also be able to distribute queries to various data
repositories, local or remote, combining their results. This requirement is intended to
1 http://jena.sourceforge.net
2 http://www.openrdf.org
3 http://www.w3.org/TR/rdf-sparql-protocol/

allow the use of data distributed according to the recommendations of the project Linking
Open Data, especially those data available under SPARQL Endpoints.
The RDF(S)/OWL mapping layer provides a view of the data and meta data,
originally persisted as RDF triples, as primitives of the programming language in which
the application is implemented. In general, these primitives are objects, attributes and
classes of class-based object-oriented programming languages. However this architecture
does not impose the use of a specific programming language, and those that include other
kind of primitives such as associative arrays [Luckham & Suzuki, 1979] and prototypes
[Lieberman, 1986] can be used.
Four other modules were designed: domain module, navigation module, business
logic module and interfaces module. Each of these modules is responsible for maintain
and interpret their related models. All that modules have similar organization, composed
by an ontology, a model specification and an interpreter of that model. Only the domain
module has no interpreter because the semantic of the domain model is the same of
RDFS and OWL and the persistence module provides an interpreter for them on the
RDF(S)/OWL mapping layer.

Module collaboration
The sequence diagram below illustrates the collaboration sequence between the
modules in a normal case of hypertextual navigation. The user interaction always happens
through the external operations of the business logic model, available as Web Services.
External agents invoke external operations by sending HTTP requests [Berners-Lee et al.,
1999] to the application. In this sense, external operations fulfill the same role of the
controller from the MVC (model-view-controller) standard [Burbeck, 1987, 1992],
coordinating user interactions, obtaining data from the domain model, asking the view to
generate the interface and, finally, delivering the result to the user or external agent.

In this sequence diagram, the user sends a message to the business logic module
invoking the method execute e informing the name of an operation, in this case
context, and some parameters for this operation. After that, the external operation
invokes the method get_context from the navigation module with the context identifier
AllPerson which invokes the method dsl from the domain module with the context
query expression, obtained from AllPerson context specification. The domain module
just pass the same message to the persistence module, that is responsible for receive the
context query expression, convert it to an equivalent Federated SPARQL query
expression, execute this query, get the results in RDF triples and maps that results in the
programming language primitives. This mapped data is returned to the domain module
and passed to the navigation module, which generates the context instance with its nodes
based on that received data and returns this context instance to the business logic module.
Then, the business logic module invokes the method generate_interface on the
interfaces modules with the context instance, which returns the interfaces. Finally, the
business logic module returns the result to the user.

Implementation architecture
Synth is implemented with Ruby on Rails, a MVC framework for web applications
development. Under this aspect, Synth is an application built according with the MVC
pattern. However, was kept the modular organization where each module presented on
the conceptual view is implemented as a composition of one or more components of the
MVC. The figure below presents the stack of software components that compose the
Synth general architecture.

Synth
Ruby on Rails
ActiveRDF
Jena
RDF data
Every data in Synth is maintained as a RDF graph. It includes not only the
instances of domain data, but also the metadata about the models and meta models of
SHDM. Everything about the application, domain data, hypertextual navigational
specification, business logic and interfaces are expressed in RDF(S) and OWL. There is
no need to change the Synth source code to make a LDA because it is possible to define
almost any aspect of an LDA as RDF data, thanks to the Synth modules that interprets its
models.
The Jena framework was used to given an API for manipulating the RDF
programmatically. It covers the role of the store, inferences and query layer on the
persistence module. The ActiveRDF is a library for accessing RDF from Ruby programs.
It maps the RDF data in Ruby primitives, role of the RDF(S)/OWL mapping layer.
ActiveRDF provides an API that facilitates CRUD operations on Ruby programs. It has a
adapter for Jena.

The choice for Ruby on Rails was motivated by the choice for the Ruby language.
As demonstrated by [Orena et al. 2008], because of the dynamic and open nature of the
Semantic Web, scripting dynamic languages are suitable for the development over this
environment, thanks to its dynamically typed objects, multiple heritance and relaxation of
strict object conformance to class definition presents a good mapping for the specification
of RDFS classes. Languages, such as Smalltalk, Perl, Python, and Ruby, are dynamically
typed, typically allow higher-order constructs (e.g. passing methods to methods) and
support complete reflection, both introspection (obtaining information on objects at
runtime) as intercession (modifying objects at runtime), all desirable characteristics for
LDA development.

Authoring environment GUI

Synth provides an authoring environment GUI of HTML forms that can be
accessed from a web browser and allows the creation and edition of the SHDM models
primitives. Through this interface it is possible run the application while it is built and
validate it in each step of its development. The figure below shows one of the screens
from Synth GUI. This is the screen for listing the application contexts.

Each tab on this screen is related to a specific step of SHDM. When the user click
on a tab, sub tabs for editing the primitives related with the selected step are presented.
So, it has Domain for the Domain Modeling, Navigation for Hypertextual Navigation
Modeling, Interface for Interface Modeling and Behavior for Business Logic
Modeling.
Synth also provides the RDF Scaffold, a generic RDF editor that allows the
execution of the CRUD operations for the local application RDF database in the same
way that it could be done on some well known RDF browsers and wikis like Tabulator,
Disco or OntoWiki. The figure below presents one screen of the RDF Scaffold.

Context Query Expression Languages

Synth provides many ways to specify the selection rules for a context that denotes
the set of resources that compose its nodes. The selection rules are expressed as context
query expressions. These expressions can be specified on one of these query languages:
SPARQL, a DSL hosted on Ruby with the ActiveRDF API and SynthQL, a query
language created specially for Synth which can represent the most common context
queries on a LDA.
The list below is an example of a parameterized query in SPARQL that means All
resources which rdf:type is foaf:Person, dc:creator is the value of the parameter person
and dc:created is the value of the parameter creation_date . Notice that this expression

is a valid Ruby string. This string is interpolated with the value of the parameters on the
array [ person, creation_date ] on runtime.
%{
PREFIXrdf:<http://www.w3.org/1999/02/22rdfsyntaxns#>
PREFIXbibo:<http://purl.org/ontology/bibo/>
PREFIXdc:<http://purl.org/dc/terms/>
SELECTDISTINCT?sWHERE{?srdf:typetrack:TabIssue.
?sdc:creator<%s>.
?sdc:created"%s".}
}%[person,creation_date]

The SPARQL syntax should be the same accepted by the ARQ 4 query machine, part
of Jena5 framework. This SPARQL syntax implements some features of SPARQL 1.1 that
still in development and supports the Federated SPARQL query6 that is important for
specifying datasets on the context queries.
The list below presents various examples of query expressions in the DSL hosted in
Ruby with the ActiveRDF API.
TRACK::TabIssue.find_all
TRACK::TabIssue.alpha(DC::title)
TRACK::TabIssue.find_by.dc::title("sometitle").execute
john=Resource.new("http://users#user1")
TRACK::TabIssue.find_by.foaf::maker(john).execute
TRACK::TabIssue.find_by.dc::title("Error").foaf::maker(john).execute
MY::Annotation.find_by.my::annotates(issue).execute

Below is described each one query expression:

1.
2.
3.
4.

All resources which rdf:type is track:TabIssue;

All resources which rdf:type is track:TabIssue ordered by dc:title;
All resources which rdf:type is track:TabIssue and dc:title is some title;
All resources which rdf:type is track:TabIssue and foaf:maker is the resource
denoted by the URI http://users#user1;

4 http://jena.sourceforge.net/ARQ
5 http://jena.sourceforge.net
6 http://jena.sourceforge.net/ARQ/service.html

5. All resources which rdf:type is track:TabIssue, dc:title is Error and

foaf:maker is the resource denoted by the URI http://users#user1;
6. All resources which rdf:type is my:Annotation and my:annotates is the same
value of the parameter issue passed during the navigation.
The goal of SynthQL context query language is abstract the syntax of SPARQL for
the most commons query expressions on a LDA. This approach tries to minimize the
need of knowledge about SPARQL covering a large set of common expressions with a
simple syntax.
The list below is a context query expression expressed in SynthQL. This query
means All resources which rdf:type is track:TabIssue, part of dc:title is error,
foaf:maker is the same value of the parameter user passed during the user navigation,
ordered by dc:title, limited in 100 results and the query should be launched on the
datasets identified by local and issue_tracker.
selects{
typeTRACK::TabIssue
dc::titlelike"error"
foaf::makeruser
orderDC::title
limit100
datasets:local,:issue_tracker
}

A SynthQL query expression always begins with selects, followed by a pair of

curly brackets. Inside the curly brackets should be informed, in any order, reserved
clauses and pairs property/value. The reserved clauses are type, a (equivalent to
type), order, reverse_order, limit, like and datasets. Anything that is not a
reserved clause is a pair property/value. The pairs property/values compose the
conditions of the query, specifically the WHERE clause of SPARQL.

Semantic Issue Tracker

In this section is presented the Semantic Issue Tracker application as an example of
a LDA created with Synth. An Issue Tracker is a system for management creation, update
and solving issues about some service or product reported by clients or collaborators. A
Semantic Issue Tracker is an Issue Tracker in which the data are described in RDF.
The domain model (ontology and instances) of this application is the data from
Tabulator7 Issue Tracker available on http://tabulator.org/wiki/tabulator/tracker with some
extensions on the ontology for supporting user annotations. Those raw data was provided
on a SPARQL endpoint to support queries by using the Joseki SPARQL Server 8. The
aspects about hypertextual navigation, business logic and interface of this application
were modeled according with SHDM.
The figure below shows a class diagram in a UML style notation that represents the
application ontology. The main classes are track:TabIssue, representing the issues with an
hierarchy of subclasses for the issue state, user:User and wf:Message. The class
track:TabIssueCategory represents issue categories. The class my:Annotation extends the
original ontology for supporting user annotations.

7 http://www.w3.org/2005/ajar/tab
8 http://www.joseki.org

The figure below is the diagram that represents the context schema for this
application. The context schema is an artifact of SHDM for representing the hypertextual
navigation in a high level of abstraction. In this diagram the dashed boxes are the indexes
(accessing structures, like a list with links) and the white boxes inside the grey boxes are
the contexts. The arrows represent the navigation between contexts and indexes.

track:TabIssue
IssuesByCategory
IssuesByState
IssuesByMaker
ListTabIssuesIdx
AllTabIssues
AllTabIssuesIdx

wf:Message
MessageByIssue

user:User
MakerByIssue
ModifierByIssue
SubscriberByIssue
Alpha

The hypertextual navigational model and, consequently, the context schema

presented above can be represented in RDF triples with more details that could not be
represented in that graphical notation.
In this application the context AllTabIssues is the major context and is composed
by the set of resources which type is track:TabIssue. The list below is the specification of
this context expressed in the Turtle notation of RDF.

:AllTabIssuesashdm:Context;
shdm:context_name"AllTabIssues";
shdm:context_title"AllTabIssues";

shdm:context_query"selects{
aTRACK::TabIssue
datasets:issue_tracker
}".

The main property of a context is shdm:context_query, that is a query expression

that denotes the set of resources that compose the nodes of the context. In the list above,
the query expression is specified in SynthQL and represents all resources which type is
track:TabIssue on the dataset identified by issue_tracker .
A dataset is specified with the voiD vocabulary. The list below is the specification
of the issue_tracker dataset.
:issue_trackeravoid:Dataset;
dcterms:title"issue_tracker";
dcterms:description"TabulatorIssueTrackerDataset";
void:sparqlEndpoint<http://example.com/sparql>.

The major property of a dataset is void:sparqlEndpoint that carries the address of

the SPARQL endpoint that responds to the queries.
The list below is the specification of IssuesByMaker context. This is a
parameterized context and it is expected to receive the parameter user during the
navigation.
:IssuesByMakerashdm:Context;
shdm:context_name"IssuesByMaker";
shdm:context_title"IssuesbyMaker";
shdm:context_query"selects{aTRACK::TabIssue
foaf::makeruser
datasets:issue_tracker
}";
shdm:context_parameters[
aSHDM::ContextParameter;
shdm:context_parameter_name'user'.
];

This query stands for all resources which type is track:TabIssue and the value of
the property foaf:maker is the same passed by the parameter user on the dataset
issue_tracker . The figure below is the same specification of IssuesByMaker context
inside the Synth authoring environment graphical interface.

The next figure is the resulting page of navigation on the IssuesByMaker context
with the selected user is Joyce.

In SHDM it is possible to enrich the navigational node, which is a resource

accessed in some navigational context, with some especial attributes, called navigational
attributes. For that it is necessary to specify the navigational attributes for some class in
some context in a way that, if a resource of the specified class is accessed in the specified
context, this resource will be enriched with the specified navigational attributes. This is
called in context class specification. The list below is a in context class specification for
the class track:TabIssue and the AllTabIssues context.
:TabIssueInAllTabIssuesashdm:InContextClass;
shdm:in_context_class_classtrack:TabIssue;
shdm:in_context_class_context:AllTabIssues
shdm:computed_attributes[
ashdm:ComputedNavigationAttribute;
shdm:navigation_attribute_name"Annotations";
shdm:computed_value_expression"
issues=MY::Annotation.find_by.my::annotates(self)
issues.execute.to_a.map{|a|a.rdfs::comment.first}
".
];

The figure below is the same specification on the Synth authoring environment
graphical interface.

In this specification, the computed navigational attribute Annotates are added to

the resources of the class track:TabIssues accessed on the context AllTabIssues. This
computed navigational attribute is a string listing the annotations of the track:TabIssue.
The figure below is the resulting page of navigation on the context AllTabIssues
presenting the computed navigational attribute Annotates highlighted inside of the
dashed box.

The list below is the specification of the ListTabIssueIdx index. In this example
some navigational attributes are omitted to save space, but they are very similar to the
presented navigational attribute.
:ListTabIssueIdxashdm:ContextIndex;
shdm:index_name"ListTabIssueIdx";
shdm:index_title"TabulatorIssueList";
shdm:context_index_context:AllTabIssues;

shdm:context_anchor_attributes[
ashdm:ContextAnchorNavigationAttribute;
shdm:navigation_attribute_name"Issue";
shdm:navigation_attribute_index_position1;
shdm:context_anchor_label_expression"self.dc::title";
shdm:context_anchor_target_context:AllTabIssues;
shdm:context_anchor_target_node_expression"self".
];

This index is based on the context AllTabIssues and has the navigational attribute
which is a context anchor. This context anchor shows the dc:title of the TabIssue and the
target is the resource in which the current index entry is based on the context
AllTabIssues. The figure below presents the complete specification of this index on
Synth.

The figure below is the resulting of the navigation on the ListTabIssueIdx index.