Web Spa

1. WebSpa Monica Macoveiciuc and Constantin Stan Faculty of Computer Science, Alexandru Ioan Cuza University, Iasi Abstract. WebSpa is a tool that allows the quick, intuitive (and even fun) interrogation of arbitrary SPARQL endpoints. WebSpa runs in the web browser and does not require the installation of any additional software. The tool manages a large variety of pre-deﬁned SPARQL endpoints and allows the addition of new ones. An user account gives the possibility of saving both the interrogation and its results on the local computer, as well as further editing of the queries. The application is written in both Java and Flex. It uses Jena and ARQ application programming interface in order to perform the queries, and the results are processed and displayed using Flex.

2. Introduction The Web is a universal medium for information and data exchange. Exploiting the huge amount of knowledge distributed on the Web is a significant challenge. Humans can understand the information, but it takes great effort to find and combine data from such a large number of sources; on the other hand, computers can easily browse through millions of pages in no time, but they are not capable of understanding the content. The Semantic Web is an extension of the World Wide Web, “in which information is given well-defined meaning, better enabling computers and people to work in cooperation”[1]. RDF (Resource Description Format), together with SPARQL, provide a powerful mechanism for describing and interchanging metadata on the web. RDF is the W3C standard for encoding knowledge. It is a structure for describing and interchanging metadata on the Web in numerous forms and purposes. SPARQL is both a query language and a remote access protocol. A SPARQL endpoint enables users (human or machine) to query a knowledge base via the SPARQL language. Results are typically returned in one or more machine-processable formats. Therefore, a SPARQL endpoint is mostly conceived as a machine-friendly interface towards a knowledge base. WebSpa is a web based application that manages SPARQL endpoints and allows users to perform interrogations over them. It provides pre-defined SPARQL endpoints and supports the addition of new ones. Anyone can use the application, but an user account is required in order to performs certain operations, such as adding endpoints, saving and later editing a query. The results are displayed in the browser and they can also be stored locally, in XML format. The application is written in both Java and Flex. It uses Jena and ARQ application programming interface in oder to perform the queries, and the results are processed and displayed using Flex. This paper describes the WebSpa application, as well as the way it is built. The first chapter contains a brief explanation of the concepts of SPARQL and SPARQL endpoint, and the technologies used for building the application - Java (Jena, ARQ) and Flex. The next chapter presents the interface, functionality and storage capabilities of the application. The front and back-end are then described and. Conclusions are drawn and perspectives are suggested in the final chapter.

3. Technologies 1 SPARQL SPARQL[2] (which is pronounced “sparkle” and has as recursive acronym - SPARQL Protocol and RDF Query Language) is an RDF query language. It’s a fresh W3C Recommendation about which Sir Tim Berners-Lee said that “will make a huge difference”. RDF is pretty foundational to the Semantic Web. Until SPARQL’s launch, RDF had a data model, a formal semantics, and a concrete serialization (in XML), but what it didnt have was a standard query language. SPARQL came in place and now offers to the Semantic Web and to Web 2.0 a common data manipulation language in the form of expressive query against the RDF data model. Using WSDL 2.0, SPARQL Protocol for RDF describes a very simple web service with one operation, query which is available with both HTTP and SOAP bindings. This operation is the way you send SPARQL queries to other sites and the way you get back the results. The HTTP bindings are REST-friendly and a simple SPARQL protocol client takes little amount of code in order to implement. SPARQL consists of 3 separate specifications. The first one is the query language specification (which makes up the core). The second is the query results XML format (which describes an XML format or serializing the results of an SPARQL queries - SELECT, ASK). The third specification is the data access protocol (which uses WSDL 2.0 to define simple SOAP and HTTP protocols for remotely querying RDF databases - or any data repository that can be mapped to the RDF model). Altogether it consists of a query language, a mean of con- veying a query to a query processor service and defining the XML format in which the results will arrive. Some issues are not addressed yet by SPARQL. The most notable is that it can’t modify an RDF dataset (it’s read-only). As we mentioned previously, RDF is build on the triple pattern (a 3-tuple consisting of subject, predicate, and object). Similar to RDF, SPARQL is built on the triple pattern, which also consists of a subject, predicate and object. SPARQL allows to match patterns in an RDF graph using triple patterns, which are like triples except they may contain variables in place of concrete values (the variables are used as “wildcards” to match RDF terms in the dataset). The SELECT query can be used to extract data from an RDF graph, returning it as an array result set. For more complex graph patterns one should use required and/or OPTIONAL data. UNION queries are also a way of dealing with selecting alternatives from the dataset. It is possible to apply ordering to the

4. results, jump forward through results using OFFSET, and LIMIT the amount of data returned. The SPARQL Query Results XML Format specification includes several relevant examples. Given its obvious simplicity and regular structure, manipulating this format with XSLT or XQuery is fairly trivial. The syntax shortcuts make writing queries much simpler. These are especially useful with repetitive graph patterns and long URIs. SPARQL presents itself as being the missing and long waited part from the Semantic Web and Web 2.0. A SPARQL endpoint is a conformant SPARQL protocol service as defined in the SPROT (SPARQL Protocol for RDF) specification. A SPARQL endpoint enables users (human or other) to query a knowledge base via the SPARQL language. Results are typically returned in one or more machine-processable formats. Therefore, a SPARQL endpoint is mostly conceived as a machine-friendly interface towards a knowledge base. Both the formulation of the queries and the human-readable presentation of the results should typically be implemented by the calling software, and not be done manually by human users. At the time, there is no agreed description for a SPARQL endpoint. Endpoint descriptions can be used to announce endpoint capabilities and contents, support discovery through service directories, supply browsing and federation hints. 2 Jena and ARQ Jena[3] is an open source Semantic Web framework for Java. It provides an API to extract data from and write to RDF graphs, which are presented as an abstract “model”. This model can be queried through SPARQL and updated through SPARUL[4]. Jena uses the concept of graph for dealing with the data: the nodes correspond to URIs, while the edges are the triples. The graphs are represented through the Model interface, which has different implementations: a memory-based one, one which uses a relational database etc. The memory-based model is the simplest and easier to use one. A triple is represented through an interface called Statement. A statement cor- responds to an edge in the graph and consists of three parts:

5. – the subject - the resource from which the arch leaves - implements the Re- source interface; – the predicate - the property (the label of the arch) - implements the Property interface; – the object - the resource that is pointed by the arch - implements the Re- source or the Literal interface. The components of the statement have a common base - the RDFNode interface. The object component is more complex. A statement can be used as the object component of the triple, since RDF allows nested statements. Objects implementing the Container, Alt, Bag, or Seq interface can also be used as objects. An RDF Model is represented as a set of statements. Accessing the components of the statement can be achieved through the getSubject, getPredicate and getObject methods of the Statement class. The API provides methods for the most common operations: – addProperty - adds a new statement (triple) to the model; – listSubjects - lists the subject component of each triple from the model; – listObjects - lists the object component of each triple from the model; – write - writes the model in RDF XML format to the output stream given as parameter; – read - reads the statements in RDF XML format into a model. ARQ is a query engine for Jena that supports the SPARQL language. In addition to implementing SPARQL, ARQ’s query engine can also parse queries expressed in RDQL[5] or its own internal query language. 3 Flex The Flex framework provides the declarative language, application services, components, and data connectivity developers need to rapidly build rich Internet applications (RIAs) for the browser or desktop. Flex 3 is a powerful framework that provides enterprise-level components for the Flash Player platform in a

6. markup language format recognizable to anyone with HTML or XML development experience. The Flex Framework provides components for visual layout, visual effects, data grids, server communication, charts, and much more. MXML is the language developers use to define the layout, appearance, and be- haviors of a Flex application. ActionScript 3, an object-oriented language based on industry-standard ECMAScript, is the language that defines the client-side application logic. Your MXML and ActionScript are compiled together into a single SWF file that makes up your Flex application. Because the compiler is available both as a standalone utility in the Flex 3 SDK and as part of Adobe Flex Builder 3 software, developers can choose to develop in the Eclipse based Flex Builder IDE or in an IDE of their choice. Flex includes a pre-built class library and application services that help developers assemble and build RIAs. These services include data binding, drag-and-drop management, the display system that manages the interface layout, the style system that manages the look and feel of interface components, and the effects and animation system that manages motion and transitions. The component library provides all of the user interface controls that developers need, from simple buttons, checkboxes, and radio buttons to complex data grids, combo boxes, and rich text editors. Use the provided containers to design complex, adaptive lay- outs with ease, and use (or modify) the visually stunning skins to achieve an ideal look and feel. The Adobe AIR runtime extends web applications to the desktop, creating new opportunities for more engaging, higher performing online/offline applications. The Flex framework provides native support for the new AIR APIs, and Flex Builder 3 provides all the tools necessary to build, debug, package, and sign applications built on Adobe AIR. Most Flex applications that are designed using just the Flex framework are as follows: On one side, you have properly decoupled and reusable view components, that know nothing about the rest of the application, dispatching events and using data binding from parents and to children views. On the other side, a main application container (the Application root tag) acts both as a controller and a model, sometimes delegating tasks to some “utils” classes that handle things such as RPC communications. In other words, a big Master object, which can quickly take the form of a hideous spaghetti-code monster. If the application is quite simple, and no long time maintenance is required, this might be not such a bad choice. Using Events and dataBinding, Flex can achieve a very good view components decoupling. But your main view container will either have to handle all the logic by itself, or explicitly delegate it to a controller class with which it will then be very tightly coupled. The main problem is that user interaction events dis-

7. patched by the views cannot directly communicate with a separate application controller, unless it is a view. To have a separate controller handle these events and take actions, the events have to climb the display list up to the main application container (the root application tag) which may then lead them to the controller.

8. WebSpa 4 Functionality WebSpa is a tool with which one can interrogate arbitrary SPARQL endpoints in a more intuitive way. It provides pre-deﬁned SPARQL endpoints and supports the addition of new ones. Anyone can use the application, but an user account is required in order to performs certain operations, such as adding endpoints, saving and later editing a query. The results are displayed in the browser and they can also be stored locally, in XML format. The interface is easy to use and intuitive. The top bar contains user-related information: the name of the currently logged user, a form for either registering, logging in or out. The top right menu can be used for both login and register, by ticking or un-ticking the “I’m new” checkbox. The submit button changes according to this action, into either “create”, or “log in”. The menu contains three groups of actions: Query Result More

9. The first group contains actions related to the queries. A logged user can choose to create, open or save a query. The same actions are present in the second menu group, but they are related with the results of the query. The last menu item provides information about the application. The screen is divided in two parts - the top window is bound to the query, while the bottom window is used for managing the results. The first one contains a menu which helps a less trained user to write queries. The “select endpoint” dropdown contains predefined SPARQL endpoints. A user that has created an account can add and remove his own endpoints. These actions can be performed through the group of options next to the menu - “Refresh”, “Save”, “Delete”. The next dropdown contains predefined RDF Schemas that are automatically inserted in a query when the user selects one. The “template” menu contains four options, corresponding to the four types of SPARQL queries supported - SELECT, ASK, DESCRIBE, CONSTRUCT. When a user selects one of these items, a pattern of the query is written in the query window. The user can then personalize this pattern. For example, choosing the “SELECT” option inserts the following content: SELECT DISTINCT ?s ?p ?o

10. WHERE { ?s ?p ?o . } The “Statement” menu contains code editing features (comment/uncomment or indent/remove indent), selection applicable stateaments and example (fill in) statements. The last item of the bar is a group of buttons that provide quick access to the most important actions - creating a new query, opening an existing one, saving a query. A bar with options divides the screen in two windows. It contains items that help users manage the queries. The “Run Query” button runs a query, and the provided results are displayed in the window below. This query can be given a name and saved in the database for later use. A user can choose to load his saved queries, which can then be edited or saved as new queries. 5 Front-End The front-end, realized in Adobe Flex Builder, is using as backbone the Adobe Flex Framework 3.2.0. Not using a stronger MVC constrain from the framework side has its advantages and/or disadvantages and this was discussed in previous material. As most of the projects built with Adobe Flex Builder, WebSpa is an Web application (means that it runs in Flash Player - the Adobe runtime for web browsers). The whole project targets as Player the version 10.0.0 of Flash Player. This is a technical requirement because this version of the Player offers an unprecedented API when comes to work with files: saving and opening local files on the client’s machine. Previous versions of Flash Player made this possible only via server side scripts (server was used as a proxy). From now on we’ll refer to Adobe Flex Builder simply with Flex. The project has as “entry point” the WebSpa.mxml file. This is where things

11. start to happen. In this MXML file the layout and content of the header and of the footer of the application are described. Also this class manages users (creates, logs in or logs out users) and offers an application menu. Into the project we created a Config class which acts as configuration data holder. This class holds data as the server paths, project internal data and other type of data. Changing the project’s server side application location is much easier this way. After 1 line edit and a recompile the application is “good to go”. All properties within this class are static. All styles within the application (if altered) are managed from a *.css file (Main.css). For the other pages within the project we used MXML components. This fact assures us the possibility of an easy extension in the future if desired. We’ve got the About.mxml and ClassicWebSpa.mxml. The About page is quite self ex- plainable. The ClassicWebSpa is our SparQL interrogation tool which interacts with the Java server side for providing results to queries written by users. Inside this page the user is presented the option to refresh / save / delete endpoints or to save / load queries on the server side and have access to them via his account. This option is available only if the user is logged in. Also the use has the option to create new / open / save queries or results locally. We even offer the option to save under 2 different file formats (*.wsq which stands for WebSpaQuery and *.wsr which stands for WebSpaResult). This is offered to the user in order to manage/locate files related with our application more easily. Basically our application aids the user to execute a SparQL query against an endpoint and retrieve the result of that query for a later manipulation. The application menu offers pretty much the same functionality as the ClassicWebSpa page, plus the connection to the About page. For the whole communication between front-end and back-end we use an wrap- per class that automates the server calls (offers the server side script, the GET parameters, the POST parameters and the callback on execution success). This make things much more readable and easy to manage in the rest of the classes. For local files management we use two static classes which handled pretty well saving / opening queries or/and results. For the future the project may be extended easily because of the decoupled way things function within it. 6 Back-End The back-end is written in Java, using the Jena framework and the ARQ support for SPARQL that it provides. The code is organized in three packages: webspa.persistance

12. webspa.servlet webspa.sparql The package webspa.servlet contains the central point of the application, the class WebSpaServlet. It is a servlet that communicates with the Flex front-end of the application and redirects each call to the appropriate method. The servlet is also responsible with starting the SQL transaction, as well as with committing the changes. The servlet contains a HibernateBean object, whose methods are called for each action. The requests comming from the front-end are analyzed in order to determine which method to be accessed, based on the value of the “fn” parameter. Once the method identified, it is passed some general parameters - the request, response and the EntityManager object (used for managing the communication with the database tables). Some of the methods require additional parameters, such as boolean values or certain parameters specified in the request. Each of the HibernateBean’s methods return the response as a String variable, which is then passed to Flex for further processing, using the HttpServletResponse’s PrintWriter object: if (method.equalsIgnoreCase("create-user")) { response.getWriter().write(hBean. registerUser(request, response, entityManager)); } The method that executes the SPARQL query is accessed differently. A SparQL object is created and its executeSpaQuery method is called, with the following parameters: the query’s text, the endpoint’s URL and the PrintWriter object. The method itself is responsible with writing the response to this object. Package webspa.persistance contains the classes used for the persistence layer of the application, which is implemented with Hibernate and JavaPersistence API (JPA). The data is stored in a MySQL database. There are five classes mapped to the database tables: class User - table USERS - manages the users of the application. class EndPoint - table ENDPOINT - stores endpoint information, such as the url, the type (default or added by user), the status etc. class UserEndPoint - table USERENDPOINT - contains a one to many mapping between an user and his additional endpoints. class Model - table MODEL - stores RDF Schemas. class Query - table QUERY - stores save queries. Each class has attached an .hbm.xml file, that specifies the mapping between

13. class variables and table columns. For example, the User class has the following variables: @Id @GeneratedValue(strategy = GenerationType.AUTO) private Integer uid; private String username; private String password; private String lastIp; @Column(name="created") private Timestamp creationDate; @Column(name="lastlogin") private Timestamp lastLoginDate; The tokens preceded by “@” are JPA annotations. The corresponding .hbm.xml ﬁle contains the mapping: <hibernate-mapping> <class dynamic-insert="false" dynamic-update="false" mutable="true" optimistic-lock="version" polymorphism="implicit" select-before-update="false" name="webspa.persistance.User" table="users"> <id column="UID" name="uid"> <generator class="increment"/> </id> <property column="username" name="username"/> <property column="password" name="password"/> <property column="lastip" name="lastIp"/> <property column="created" name="creationDate"/> <property column="lastlogin" name="lastLoginDate"/> </class> </hibernate-mapping> A class named HibernateBean is responsible with the communication with the database. HibernateBean contains methods for retrieving, saving and updating endpoints, queries and/or results. Each of the methods follows a similar pattern - validation of the parameters, creation and execution of the query, formatting and sending the result. The methods implemented are: registerUser loginUser logoutUser createEndPoint hideShowEndPoint saveQuery updateQuery checkUserById

14. checkField checkEndPointByUserUrl getLoggedUserId getEndPoints getModels getQueries Along with the class that communicates with the database, the package webspa.sparql contains the class SparQL. Using Jena and ARQ APIs, the class runs queries over SPARQL endpoints. The process of sending a query and getting a result is simple. First, a QueryExecution object is obtained using the ARQ’s class QueryExecutionFactory and its sparqlService method. This method requires two arguments - the query and the endpoint URL, both provided by the user through the interface. QueryExecution queryExecution = QueryExecutionFactory. sparqlService(endpoint, query); A pattern is used in order to determine the type of the query - SELECT, ASK, DESCRIBE, CONSTRUCT. Based on the type, diﬀerent methods are called: execSelect execAsk execDescribe execConstruct The ResultSetFormatter’s static method - asXMLString - is used for returning the results of the SELECT and ASK queries as XML. ResultSet results = queryExecution.execSelect(); printWriter.write(ResultSetFormatter.asXMLString(results)); The other to interrogation types retrieve the results as a Model object. These objects write directly to the PrintWriter that communicates with Flex, via their “write” method. Model model = queryExecution.execDescribe(); model.write(printWriter);

15. Conclusion and Perspectives WebSpa is a web based application that manages SPARQL endpoints and allows users to perform interrogations over them. It provides pre-defined SPARQL endpoints and supports the addition of new ones. Anyone can use the application, but an user account is required in order to performs certain operations, such as adding endpoints, saving and later editing a query. The results are displayed in the browser and they can also be stored locally, in XML format. The application is written in both Java and Flex. It uses Jena and ARQ application programming interface in order to perform the queries, and the results are processed and displayed using Flex. There are two versions of WebSpa - the classic one, which has been presented in this paper, and the graphical one, which is still under development. The latter allows the user to handle the RDF graph by visualizing its nodes and arches and directly manipulating them. Limitations of the Classic WebSpa refer mainly to the way content is displayed, eg. it might be a little difficult for the users to manually browse to the XML file in order to view the results. References [1] Tim Berners-Lee, James Hendler and Ora Lassila. The Semantic Web. Scientific American, May 2001. [2] W3C. SPARQL Query Language for RDF. http://www.w3.org/TR/rdf-sparql- query/ [3] Jena Project Page. http://jena.sourceforge.net/ [4] W3C. SPARQL Update. http://www.w3.org/Submission/SPARQL-Update/ [5] W3C. RDQL - A Query Language for RDF. http://www.w3.org/Submission/RDQL/ [6] Adobe Flex 3. http://www.adobe.com/ro/products/flex/ [7] ARQ - A SPARQL Processor for Jena. http://jena.sourceforge.net/ARQ/ [7] onica Macoveiciuc, Constantin Stan. Flex Framewoek Presentation.

Web Spa

Du liest eine Vorschau.

Hier ansehen

Web Spa

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Web Spa (20)

Aktuellste (20)

Web Spa