Escolar Documentos
Profissional Documentos
Cultura Documentos
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
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.
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.
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
4 http://jena.sourceforge.net/ARQ
5 http://jena.sourceforge.net
6 http://jena.sourceforge.net/ARQ/service.html
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
:AllTabIssuesashdm:Context;
shdm:context_name"AllTabIssues";
shdm:context_title"AllTabIssues";
shdm:context_query"selects{
aTRACK::TabIssue
datasets:issue_tracker
}".
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.
The figure below is the same specification on the Synth authoring environment
graphical interface.
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.