Fridolin Wild (OU), Katja Buelow (OU), Bernhard Hoisl (WUW), Robert Koblischke (WUW), Markus Essl (BIT MEDIA), Traian Rebedea (PUB-NCIT), Vlad Posea (PUB-NCIT), Thomas Markus (UU), Eline Westerhout (UU), Sonia Mandin (UPMF), Hendrik Drachsler (OUNL), Gaston Burek (UTU), Hristo Kostov (IPP-BAS), Alex Simov (IPP-BAS)
Authors (Partner)
Fridolin Wild (OU), Katja Buelow (OU), Bernhard Hoisl (WUW), Robert Koblischke (WUW), Markus Essl (BIT MEDIA), Traian Rebedea (PUB-NCIT), Vlad Posea (PUB-NCIT), Thomas Markus (UU), Eline Westerhout (UU), Sonia Mandin (UPMF), Hendrik Drachsler (OUNL), Gaston Burek (UTU), Hristo Kostov (IPP-BAS), Alex Simov (IPP-BAS)
Contact Person
Fridolin Wild (OU)
WP/Task responsible
OU/WUW
EC Project Officer
Ms. M. Csap
Abstract (for dissemination)
This deliverable d2.3 reports on the current state of integration of the services developed in this iteration of the project: it outlines the current state of interop-erability of the services version 1 with respect to data sources, services, and widgets. Additionally it reports on freshly developed integration components such as localisation facilities, corporate design facilities, inter-widget communication facilities, and authentication facilities. It additionally provides guidelines on how to deploy these integration components to achieve deep integration along the planned integration threads for the ‘version 2’ iteration.
Keywords List
LTfLL, services LTfLL Project Coordination at: Open University of the Netherlands Valkenburgerweg 177, 6419 AT Heerlen, The Netherlands Tel: +31 45 5762901
Table of Contents
Executive Summary
3
1. Introduction........................................................................................ 4 2. Service infrastructure report ................................................................ 6 2.1 Infrastructure for each task............................................................. 6 2.1.1 Positioning Service (T4.1) ......................................................... 7 2.1.2 CONSPECT: Monitoring Conceptual Development (T4.2) .............. 8 2.1.3 Chat and Forum Analysis and Feedback Service (T5.1) ...............10 2.1.4 PENSUM: Summary writing (T5.2) ............................................12 2.1.5 Formal Learning Support System (T6.1)....................................13 2.1.6 Informal Learning Support System (T6.2) .................................14 3. Elgg report ........................................................................................17 3.1 Wookie plug-in for Elgg..................................................................17 3.2 Communication between wookie and Elgg .......................................19 3.3 Wookie widget development guide..................................................21 3.4 State of widgetisation ....................................................................24 Task T4.1 positioning .......................................................................24 Task T4.2 monitoring conceptual development ...................................25 Task T5.1 chat & forum analysis and feedback ...................................27
D2.3 Services v1 integrated
Task T5.2 summary writing ..............................................................29 Task T6.1 Formal Learning Support System .......................................30 Task T6.2a Social component of public knowledge ..............................31 Task T6.2b Social component of public knowledge ..............................32 3.5 Guidelines: localisation and corporate design in a distributed environment.......................................................................................33 3.5 Guideline: inter-widget communication ...........................................36 3.6 Guideline: authentication with openID ............................................42 4. Summary & Outlook ...........................................................................46 Annexes ................................................................................................47 A. Installing Wookie for Elgg ................................................................47 B. LSA Infrastructure ..........................................................................48 C. Streamlined Cognitive Walkthrough..................................................49 D. Description of the exposed services of all service prototypes. .............50 T4.1 Positioning...............................................................................50 T4.2 Services ..................................................................................57 T5.1 Feedback and Analysis Service related .......................................62 T5.2 Summary Writing .....................................................................67 T6.1 Formal Learning Support System ...............................................72 T6.2a Social component of public knowledge......................................74 T6.2b Social component of public knowledge......................................84 References ............................................................................................88
2 LTfLL -2010-212578
D2.3 Services v1 integrated
Executive Summary
This deliverable d2.3 reports on the current state of integration of the services developed in this iteration of the project: it outlines the current state of interoperability of the services version 1 with respect to data sources, services, and widgets. Additionally it reports on freshly developed integration components such as localisation facilities, corporate design facilities, interwidget communication facilities, and authentication facilities. It additionally provides guidelines on how to deploy these integration components to achieve deep integration along the planned integration threads for the ‘version 2’ iteration. The description of work defines this deliverable to be a report on "the general utilities and resources (update 1) and the software integrating the services of WP4-6 for use in personal competence development and the corresponding documentation". It focuses on the objectives 1, 4, and 5 relating to the learning technology strand in the work package and the objectives 2 and 3 relating to the language technology strand. It should be noted that the lead in the learning technology tasks (Task 4.2) has rotated: BIT MEDIA has passed the lead on to the new partner OU. This deliverable complements the service descriptions documented in the deliverables d4.2, d5.2, and d6.2 with the interoperability perspective. It technically paves the way for the realisation of the planned integration threads that will be elaborated under the auspices of WP3 'scenarios'. It also serves as input for WP7's validation providing a consolidated overview on the status quo of the service prototypes. Preparatory work for this deliverable included the organisation of a joint developer workshop hosted by WUW in Vienna in December 9-10, 2009, during which the first versions of the SUM diagrams have been elaborated and technical integration discussions were conducted to investigate possible interfaces between the service prototypes and their technical feasibility (many of which are documented in d4.2, d5.2, and d6.2). The workshop in Vienna also conducted a usability inspection in form of a streamlined cognitive walkthrough (Spencer, 2000) to perform alpha testing of the service prototypes (Annex C), helping to make them fit for the validation performed in WP 7. 3 LTfLL -2010-212578
D2.3 Services v1 integrated
1. Introduction
The main challenge for this work package is to create interoperability along two lines of work: interoperability of the learning tools and interoperability of the language technology supporting these learning tools. The purpose of this sought interoperability is manifold: it is to allow for integration of the heterogeneous services developed within the project; it is to allow for their flexible recombination to serve the fulfilment of learning tasks spanning the developed prototypes; it is to pave the way for commercial and non-commercial uptake. In a concertation activity with other TEL projects (namely Role and Stellar) as part of the Mash-Up Personal Learning Environments (MUPPLE'09) workshop we co-organized at the European Conference for Technology-Enhanced Learning (EC-TEL'09), we have elaborated an interoperability framework for personal learning environments in which we move (Palmer et al., 2009). From the dimensions of interoperability identified in this framework – i.e. screen, data, temporal, social, activity, and runtime interoperability – we have been prioritizing achievements on the screen, data, and temporal dimension for this phase of the project. This framework complements and refines the architectural layers outlined in deliverable d2.1. In other words, the focus for this iteration lay on creating widgets, creating web service interfaces, negotiating data formats, and enabling 'live' interwidget communication. The relation of this deliverable to the previous ones is as follows. D2.1 outlined the initial concept, whereas d2.2 documented the services as well as this could be done for showcases. D2.3 now technically documents the first release of the LTfLL service prototypes and provides integration components needed for the 'deep' integration along the planned integration threads. There are limitations of this service 1.0 wave that need to be mentioned: this wave was planned to have widgets 'side by side'; deeper integration is to be realised through the user workflow. This, however, is the basis for the final deep integration as being investigated currently in the upcoming scenario threads in WP3. 4 LTfLL -2010-212578
D2.3 Services v1 integrated
With the service usage models documented in section 2 and the en detail service descriptions in the annex, we provide a more technical documentation that (not only) serves developers. The rest of this deliverable is organised as follows. Section 2 provides the infrastructure report about the WP4/5/6 service prototypes. It is complemented with en detail information in the annex. Section 3 focuses on the integration platform Elgg with the widget engine wookie. It provides guidelines on how to develop wookie compliant widgets, documents the extensions we have developed for both the community platform Elgg and the widget runtime environment wookie. It gives an insight in the state of widgetisation of the WP4/5/6 service prototypes including screenshots. And, last but not least, it documents the developed integration facilities for localisation, realising a corporate design, realising inter-widget communication, and realising distributed authentication. The deliverable is wrapped up with a summary and conclusion.
5 LTfLL -2010-212578
D2.3 Services v1 integrated
2. Service infrastructure report
As outlined in deliverable 2.1, the infrastructure relates mainly to three layers: data sources, services, and widgets. We group within this infrastructure report our findings on data sources and services, whereas the subsequent section of this report (titled 'Elgg report') focuses on the widgets.
2.1 Infrastructure for each task To give an overview on the services and data sources, the following section utilises so-called service usage models (SUMs). SUMs provide a way to link the business processes of an application with the application's service structure and its internal service organisation (cf. e-Framework, 2010a). Figure 1 depicts the structure of the SUM diagrams. To ease understanding, we have added a layer on top of the business processes that groups together related business processes. In the subsequent LTfLL SUM diagrams, the top two layers relate to the business process. The boxes in the middle represent user- or system-facing services, whereas data sources are listed at the bottom of the diagram. This overview is complemented with en detail descriptions of the services and interfaces in the annex.
6 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 1. Generic Service Usage Model (e-Framework, 2010b).
2.1.1 Positioning Service (T4.1) For task 4.1 and its quantitative feedback subservice the LSA space and corpus management infrastructure as described in the annex is utilized. By default a course is automatically provided with a customized semantic space, based on a course specific selection of text material. Depending on the existence of newly available data (uploaded course learning material or newly added answers), the semantic space may be updated. All the T4.1 related data as well as the required corpora are stored in a database on the same server. 7 LTfLL -2010-212578
D2.3 Services v1 integrated
To generate the qualitative feedback subservice (the distinct phrase lists) Java code is executed on the already graded answers.
Figure 2. Service Usage Model for the T4.1 positioning service.
2.1.2 CONSPECT: Monitoring Conceptual Development (T4.2) The service for monitoring conceptual development consists of two parts. The first part deals with the set-up of the latent-semantic spaces used as a projection space for the semantic structures in the texts provided during the usage of the service. This set-up includes the upload and management of a corpus of text material (typically containing a large number of generic background documents and domain-specific documents). From this corpus, latent-semantic spaces can be created and particular configuration settings can be made. The computationally expensive calculation of the latent-semantic spaces can be scheduled here as well. This part is shared with the task T4.1
8 LTfLL -2010-212578
D2.3 Services v1 integrated
prototype. The services in this ‘set-up’ part are run very rarely by administrators. Learners will never have to deal with this part of the service.
Figure 3. Monitoring conceptual development: SUM diagram.
The second part deals with the services used while using the monitoring tool for analysing the conceptual development. This encompasses all the services that are dynamically called when learners (and more knowledgeable others like tutors or teachers) engage in learning activities. This side of the service can be broken down in five components: managing evidence, managing representations, inspecting, comparing, and sharing. The evidence management provides facilities to add RSS and ATOM feeds to the system. These feeds come from, for example, a blog-like learning diary or a discussion board. The system provides functionality to add new feeds and update existing ones. A list of feeds stored for the current user allows to manage the evidence feeds. The raw texts contained in these feeds are 'converted' into latent-semantic representations in the second component. This 'conversion' includes project9 LTfLL -2010-212578
D2.3 Services v1 integrated
ing the text into the latent-semantic space and returning a graph structure of the contained (latent) semantics of the texts. The service provides functionalities for the users to list the existing concept graphs, update them, and add new ones. The latter two thereby are automatically managed by the evidence management. Internally, a function to compute the graph structures from the raw texts serves the other functions. Whenever a feed is updated, a new version of the conceptual representation is created to provide a version history. Grouped into the column 'inspecting', the visualisation functions of the service can be listed as viewing a graphical force-directed lay-out and a function to view the underlying data. A rendering engine thereby provides the functionality to create the graphical representation. Filtering refers to functionality not yet implemented: in the future, additional filtering possibilities within the graphs and across the graphs shall ease access for the user. In the column 'comparing', the combine functionality is used by the user to create an agreement diagram that visualises the difference between two graphs with colour codes: the user can distinguish visually the overlap (= concepts shared between two graphs) and the particularities of the two graphs compared (those concepts covered only in one of the two graphs). This functionality is the basis for compiling the emergent reference model: by combining several graphs of individuals, a reference model can be established that is more representative of the domain to be covered in a specific learning activity. The last column 'sharing' groups together those functions that are needed to communicate conceptual representations: by sharing a link-with-a-password (like Google docs allows), students can offer a graph to a tutor or peer. When accepting such a link, a copy of the graph is stored in the accepting users storage space before inspecting it. Public sharing allows all other users of the system to find the conceptual graph and inspect it. Tagging again refers to future functionality: it is meant to improve access possibilities to the stored graphs.
2.1.3 Chat and Forum Analysis and Feedback Service (T5.1) The Chat & Forum Analysis and Feedback Service consists of two distinct types of services: analysis related services and data management services.
10 LTfLL -2010-212578
D2.3 Services v1 integrated
All the analysis services have been implemented in Java using AXIS2 and Tomcat for the server and JSON and XML for communication.
Figure 4. SUM diagram of the Chat & Forum Analysis and Feedback Service (5.1)
The analysis consists of a NLP pipe mainly based on the Stanford NLP software (http://nlp.stanford.edu/software/), Jazzy for spell-checking and correction (http://jazzy.sourceforge.net/) and BART for coreference resolution (http://www.bart-coref.org/). The analysis also uses WordNet and LSA for determining semantic relations between different concepts and utterances in the conversation. Service integration into the joint LSA infrastructure has already been started. Furthermore, cue-phrases, a pattern search, coreferences and semantic similarities are used to discover implicit links between the messages and build a conversation graph. After computing this graph, the service also employs several SNA and graph algorithms. The results are stored on the server in an XML file that contains textual feedback for the conversation as a whole and for each participant, plus different scores includ-
11 LTfLL -2010-212578
D2.3 Services v1 integrated
ing grades for each participant and for each utterance, by taking into account the content or information of the message and the collaboration. The management services are implemented in PHP using REST-like calls and JSON. The communication between the management and the analysis services is done using the service calls. The management information is stored in a MySQL database and the analysis results are stored in the output XML files (only partial) and in binary files (the complete information resulted from the analysis). 2.1.4 PENSUM: Summary writing (T5.2) Pensum is a service which helps students to summarize their courses in a specific course domain. There are two applications: the first for the student and the second for the teacher. Both are based on a mysql database in which different data are stored (course texts, syntheses, etc). The code of pensum is written in HTML, JavaScript, PHP, and Perl. It uses JSon (Ajax) for the communication with server functionalities. The help Pensum provides consists of 1/ three types of feedback generated with the help of an LSA application (the synthesis coherence, the relevance of synthesis sentences, the course ideas not included in the synthesis), 2/ the possibility to search different additional texts to support the understanding of the student (results of researches linked to showcase), and 3/ in the possibility to comment the synthesis (the student and the teacher can add comments about a synthesis). The analysis is partially using WP2's joint LSA infrastructure and will completely be transferred in the next months.
12 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 5. SUM diagram of PenSum (5.2).
2.1.5 Formal Learning Support System (T6.1) The main services supporting Formal Learning Support System are language pipe and Semantic Search. The first one facilitate the semantic annotation of learning materials. It is using a domain ontology and concept annotation grammar. The main processing steps are: tokenisation, POS tagging, coreference relation annotation and concept annotation. Part of speech annotation is used as a filter for the concept annotation. For example, concept for "help" is related to the noun help, but not to the verb. The co-reference relations are used for distribution of the conceptual information within the annotated learning materials. The semantic search exploit the lexicon mapped to the ontology to formulate queries in terms of concepts from the ontology. These queries are evaluated over the repository in the common semantic framework. The matching documents are retrieved and shown to the user.
13 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 6. SUM diagram of the FLSS (6.1).
2.1.6 Informal Learning Support System (T6.2) The Ontology Enrichment service can be used to enrich a domain ontology on the basis of information extracted from social networks and DBpedia. The input to the enrichment process is an ontology in either OWL or RDF. Within LTfLL the LT4eL ontology is used as the input ontology. The service queries various sources (other ontologies, RDF instances, lexica, etc) stored in an RDF-store and augments the seed ontology. The enriched ontology then gets returned or is made available through some URI. The Ontology Based Search supports knowledge discovery via semantic search and user friendly ontology browsing (in hypergraphs). The search is based on tags from social networks that are automatically associated with concepts from the ontology. What the learner sees is a widget that contains a JavaScript-based visualisation. This visualisation requests a graphML file from a web service and can send additional queries made through the interface in Json to the web service to influence the returned graphML-document. The interface also provides an interface for search requests through keywords and can display the documents and their meta-data from social media automatically. 14 LTfLL -2010-212578
D2.3 Services v1 integrated
The data aggregation service gets data from the learner's social networking accounts on flickr.com, delicious.com, youtube.com, slideshare.com (also others can be added) and uses RDF vocabularies like Dublin Core, SIOC, MOAT to transform the data into semantic data and store it into a semantic repository. Further this data will be used for more advanced user-oriented services like search, recommendation and profile generation.
Figure 7. SUM diagram for the informal learning support service (6.2)
The Search and Recommendation Based on Folksonomies uses the data extracted about the user's social network by the aggregation service in order to provide search and recommendation services for the learner. Based also on the learner's aggregated data a semantic profile is generated as an APML (Attention Profile Mark-up Language) file. Both search and recommendation
15 LTfLL -2010-212578
D2.3 Services v1 integrated
use clustering algorithms for users and tags in order to rank the best-suited resources for the learner.
16 LTfLL -2010-212578
D2.3 Services v1 integrated
3. Elgg report
From the beginning of the project, WP2 was heading for a very open solution to integration. Therefore, the idea of creating individual services glued together in a PLE – the MUPPLE paradigm (Wild et al., 2008) – was adapted to meet the needs of project partners. As our approach was steadily evolving with the submissions of reports D2.1, D2.2, and the integration report (D4.1b) it became manifest in this deliverable by a precise description of the actual software and techniques used for the technical integration. Hence, in this section we describe our development approach for integrating widgetbased services in a showcasing platform (namely 'Elgg') thus generating a highly flexible PLE. For more information on Elgg and for details on the motivation of the choice please refer to the integration report (D4.1b).
3.1 Wookie plug-in for Elgg Wookie is a widget engine that implements the W3C widget 1.0 proposal. It is designed to provide widget run-time functionality to a wide range of applications. Web applications that integrate widgets are called 'widget containers'. Widget containers take care of support activities like user management, access rights, content management and so on, while the Wookie engine supplies the functionality to add widgets to the mix. When a widget is created, direct interactions are done only with the widget engine, and not the container – the container may sometimes set preferences a widget may use (like the user’s name to display in a widget), but for the most part the services offered by the widget engine are called. Developing a widget for Wookie means that it can be delivered in a range of web platforms including software like Wordpress, Elgg, Moodle, and so on. Wookie enables widgets to be used in these applications through the use of plug-ins. This means there is some code that is native to the web application’s framework that can talk to Wookie and request widgets (cf. Wilson, 2008). In LTfLL we have chosen Elgg as a showcase platform to integrate our widgets (cf. Integration Report D4.1b). There was an existing Wookie plug-in for 17 LTfLL -2010-212578
D2.3 Services v1 integrated
Elgg, but it was outdated. Both the Wookie engine and Elgg were further developed and the plug-in interface did not match the new architecture. Therefore, WP2 updated the plug-in based on the existing one by taking the newest Moodle plug-in as a template (which was by that time the most evolved). The plug-in was designed to work with the newest versions of Elgg (1.6.1) and the Wookie engine (0.8). A first release of the plug-in (Hoisl, 2009a) was reviewed by professionals and integrated in update version 2.1 (Hoisl, 2009b). In the meantime further developments were done (e.g. OpenID integration) and a new version is currently used in the WP2 infrastructure that is going to be released.
Figure 8. Snapshot of a (random) selection of widgets integrated in Elgg.
As Figure 8 above shows, the plug-in allows for fluent integration of widgets in Elgg. A drop-down menu was implemented that enables users to choose among all available widgets provided from the wookie engine. The height and width of the widget to be displayed can be specified by the user, as well. If the dimensions are set, the values override the default manifest file definitions of the widget's configuration file (config.xml). Access to the widget can be restricted to logged in users only, to specific groups, or just to friends. In
18 LTfLL -2010-212578
D2.3 Services v1 integrated
addition, the widget can be declared private (only visible to the user her/himself) or public (visible to everybody). Future planned developments for the end-users (learners/tutors) are an alternative view of choosing widgets not only by a drop-down list but also by a widget gallery displaying the widgets' names as well as an icon and a short description (the wookie interface already exists). As the view displayed in Figure x is a good way for the role of a tutor to select widgets, a learner most probably will not change a widget in a certain context. A tutor has to decide for which exercise which widget is appropriate and the learner may change only the appearance of the specific widget. Further plug-in developments will head in this direction. With the help of an additional plug-in, multiple tabs allow to arrange selections of widgets into separate pages. In the picture, the tabs are visible at the top: 'Dashboard', 'browse', 'search'. New tabs can be created by the user, arrangements can be changed by dropping widgets or adding new ones from the widget directory. Future plans include to add a mechanism to preconfigure these arrangements for the users of Elgg to provide arrangements of widgets along the upcoming integration threads in accordance with the joint theoretical model.
3.2 Communication between wookie and Elgg The Elgg plug-in developed within WP2 for widget integration uses the Wookie REST API. The API provides functionalities such as requesting a new widget instance, getting a list of available widgets, adding participants to a widget instance, setting properties, working with shared data, etc. To date, only the core functionalities have been implemented in the Elgg plug-in. As an example, we show a request statement for a new widget instance as it is done by the function getWidget() in the plugin's file functions.php: Before the plugin is capable of invoking such a request, the URL to the Wookie engine as well as the API key must be set (in file functions.php). The API key is a unique key identifying an individual web application and must be requested from the Wookie engine by using its administration interface. As most parameters of the above REST request are self-explanatory, we provide here only some background information not visible on first sight:
19 LTfLL -2010-212578
D2.3 Services v1 integrated
- servicetype: Widgets are divided in service types each serving a different purpose. This parameter is important only where it does not matter which individual widget should be displayed as long as it is of the defined service type, e.g. 'chat'. - widgetid: If no servicetype is defined, the unique URI of the widget (Global Unique Identifier, GUID) must be provided instead. - userid: An identifier (e.g., a user ID) issued by an application, representing the current viewer of the widget instance. In the case of Elgg, the global variable $vars stores application-specific values (like user ID) and is passed through to the plugin. - shareddatakey: The key generated by an application representing a specific context. By default, different widgets are not able to share state information due to privacy concerns. Widgets having the same shareddatakey (along with some other parameters) can share data that is stored in the database of the Wookie engine (details are discussed in one of the next sections). By invoking this request, Wookie will return an XML answer consisting of the URL of the widget instance, the title of the widget, the default height and width, and a 'can maximize' flag according to the widget's manifest file. This information is used by the plug-in to display the widget in Elgg. For further information on wookie's REST API, have a look at (Wilson and Gardler, 2009). Future developments regarding the plug-in's internal logic and its technical aspects will be done by implementing the full set of functionalities the Wookie engine provides via its RESTful interface. Furthermore, for a future version it would be a benefit for administrators to input the URL and API key via the settings of the plug-in immediately through the browser rather than editing the files directly. Another extension would be integrating widgets from different Wookie engines. This would mean restructuring the internal plug-in logic to handle URLs of different Wookie engines on a per widget basis. Future work will investigate this direction and the outcome will be reported in the next deliverable. The plug-in installation instructions can be found in the Annex A.
20 LTfLL -2010-212578
D2.3 Services v1 integrated
3.3 Wookie widget development guide Generally (and also defined by our internal WP 2 development guidelines) widgets are designed to work without executing server-side code directly, but by calling web-services using AJAX. This approach has many advantages; however, software developers need to have some design rules in mind while creating widgets and services. As previously mentioned, widgets consistist of only pure HTML, JavaScript functions, CSS, and can embed images. Furthermore, a widget must follow a particular file structure: -
The widget manifest file (config.xml), which describes the widget An HTML start page, typically index.html One or more JavaScript files that implement the widget’s functionality One or more style sheets that control the appearance of the widget An icon for the widget A thumbnail image for the widget Additional media assets such as images
Widgets can also support internationalisation by organising these files into localised folders (ISO two-letter language code). Each localised folder can contain files that override the defaults when the widget is deployed in a particular location. By using JavaScript as an interaction scripting language, Wookie offers builtin functions to handle preferences, shared data, event notifications, and calls to external web-services. It is possible to: - Store and retrieve users' preferences, or any other settings unique to the widget. - Maintain data shared among all instances of a widget in a common context; for example, a chat log and buddy list for a chat widget. - Send events between widgets in the same context; for example, if a user sets their location in one widget on their profile page, the widget can send a message to other widgets on the same page. - Handle calls to external web services and feeds through a proxy service. This is important, as otherwise a widget cannot communicate with other services as this poses a security risk.
21 LTfLL -2010-212578
D2.3 Services v1 integrated
For all of these services, a widget can make use of the shared Widget object that Wookie makes available via injected JavaScript code. This means that by uploading a widget to the Wookie engine it adds lines to HTML files loading JavaScript libraries providing these functionalities. For working with external web-services and APIs, a widget needs to implement an AJAX request and handle the response, and to do so without breaching the security restrictions of the user's browser. Wookie handles the latter aspect by providing a built-in proxy service that allows the calling of services through the same Wookie server that is serving the widget, avoiding 'Same Origin Policy Violation' errors. Any servers a widget needs to call must be listed in Wookie’s whitelist (entered through the Wookie administration interface). To invoke an external service from a widget, a proxy URL needs to be constructed by calling Widget.proxify(url) which returns a 'proxified' version of a URL. There are many JavaScript frameworks and libraries (like jQuery, Prototype, Dojo Toolkit, MooTools, Yahoo! UI Library etc.) that simplify the development process; for example, handling AJAX calls is convenient and easy to maintain. Before a widget can be deployed on a Wookie server, it needs a manifest file that describes the widget and provides some configuration details that the engine can use when it renders the widget in a container application. The manifest file must be called config.xml, must be located at the root of the widget’s file structure, and must conform to the W3C Widgets Packaging and Configuration specification (W3C, 2009). Different language versions of the manifest file can also be provided in localized folders, as described earlier. The key things to consider for the manifest file are: - It must have a root element called with attributes for the height and width of the widget. This is important, as many containers will display the widget based on this information. - It must have a and preferably also a . - If an icon should be provided for a widget, an element with a src attribute must be set to the filename of the widget's icon. - The element with the src attribute should be set to the filename of the start file; this will default to index.html, but it does not hurt to make this explicit. 22 LTfLL -2010-212578
D2.3 Services v1 integrated
- If the widget uses external services, must be included. - Optionally, an element can be provided as well as a element containing copyright information. There are many other settings which can be stated in the widget manifest file - for more details we refer to the previously mentioned W3C specification (W3C, 2009). Widgets must be packaged as ZIP archives that contain all the files that make up the widget. It must be ensured that the files are in the root folder of the archive and not nested inside a subfolder; otherwise, the Wookie server would throw an error. Once an archive is created, it can be uploaded to the Wookie server by using the management interface. When the widget has been uploaded, a service type must be allocated and any services required need to be added to the proxy whitelist. If a widget needs event notifications, it is mandatory to include the following line in the manifest file: Event notifications are useful when locking/unlocking widgets or dealing with shared data. If some users are not allowed to make any changes to a widget, it can be locked (Widget.lock()) and, of cource, unlocked again (Widget.unlock()). The shared data API is Wookie's internal interface for storing and accessing data that can be shared among all instances of a widget that share a common context (e.g., for handling collaborative and social functionality). In principle there are three methods with which shared data can be (1) set, (2) appended, and (3) retrieved: (1) Widget.setSharedDataForKey(key, value), (2) Widget.appendSharedDataForKey(key, value), and (3) Widget.sharedDataForKey(key, callback). Setting and retrieving data is done asynchronously. In the case of getting data, the method specified as callback is invoked after data fetching has been finished. Whenever a shared data value is set or appended, widgets receive an event notifying them of the changes. A widget can handle notifications by setting a function as the event handler, for example: Wid23 LTfLL -2010-212578
D2.3 Services v1 integrated
get.onSharedUpdate = handleSharedUpdate. This sets the handleSharedUpdate method to be invoked whenever there is an event notifying the widget that a shared data value has been updated. If the need arises for generating an instance-specific shared data key, method Widget.instanceid_key returns a unique identifier for the widget instance. Authentication mechanisms are provided by using OpenID in conjunction with the Wookie plugin for Elgg currently running on our development server. We needed to extend the functionality of Wookie at this point because ticketbased access granting is not supported in version 0.8 of the Wookie engine (but will be in version 1.0). Details on OpenID and our implementation are provided in section 3.6. For further information regarding the development of widgets, we refer to the Wookie Widget Developer's Guide (Wilson, 2008).
3.4 State of widgetisation In this section, a rough overview on the implemented widgets is given. For each task, one selected mini application is demonstrated and described to outline the state of the ongoing widgetisation. More details on the implemented and planned widgets can be found in the deliverables d4.2, d5.2, and d6.2. Task T4.1 positioning For task 4.1, we are fully utilizing the LSA spaces generated by the space management framework as presented in section 2.2 to calculate the quantitative feedback values (answer scores). For 4.1 every step in the user interface is implemented as its own XML web-service. In our HTML based prototype implementation for the T4.1 task, each of these services is called via Javascript AJAX calls and the received data is displayed appropriately. Since every step is implemented in its own web-service/module, the modules may be freely combined and encapsulated with each other.
24 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 9. Live Feedback view (task 4.1).
In Figure 9 you see a sample of the system generated feedback for a student answer. On top in the "Answer Score" section, the quantitative feedback is displayed, indicating a general score for the answer's coverage of the question, derived by standard LSA based semantic comparison. The "Phrase Scores" section displays the qualitative feedback, listing "distinct" phrases which occur predominantly in either highly graded or poorly graded answers. Task T4.2 monitoring conceptual development Figure 10 shows the overview of the current user's concept graphs. These graphs represent the semantic structure contained in the texts from an RSS or ATOM feed added to the system. By clicking on the name of the graph, the user navigates to a page that provides more details -- and links to the graph visualisation. Facilities to delete, share, and combine complement the functionalities for inspecting. By setting two check boxes in the column 'combine' and clicking on show, an agreement graph is calculated, stored in this list of graphs, and displayed. This is depicted in Figure 11: concepts that are only in the one graph are marked yellow, from the other graph blue. If they are 25 LTfLL -2010-212578
D2.3 Services v1 integrated
shared in both graphs, they are displayed in green (the colour resulting when mixing blue and yellow).
Figure 10. Snapshot of CONSPECT (task 4.2).
26 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 11. Zoomed comparison conceptogram in the fullscreen mode of CONSPECT (task 4.2).
Task T5.1 chat & forum analysis and feedback The C&F-AFS consists of several widgets that are communicating with the PHP and Java-based services. The assignment and conversation management widgets are using the PHP management services to permit tutors to add, edit and delete assignments and chat or forum conversations related to these assignments. The support and feedback widgets use the XML files that are generated by the Java services that analyze the conversations. These widgets are used for displaying the conversation and participant textual feedback, for visualizing the conversation in order to determine the discussion threads and collaboration, for proving feedback at the utterance level and for searching the relevant participants and utterances given a search query. In the screenshot (Figure 12) of the conversation visualization widget, after selecting the assignment and conversation that is going to be analyzed, the following information is provided to the user:
27 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 12. Conversation visualization widget used for inspecting the
collaboration and discussion threads in a chat
- In the top part of the widget, the conversation graph is displayed together with the explicit links (colored in green) and the implicit links discovered by the analysis (in red). The participants to the conversation are on the vertical axis, while the identifiers of the utterances are presented on the horizontal one. Each utterance is a rectangle that has the vertical position of its issuer and the horizontal position of its id. The graph is used to assess the degree of collaboration and to emphasize the discussion threads that are present in the chat. Clicking on an utterance colors the thread that the utterance is part of. In order to see the text of all 28 LTfLL -2010-212578
D2.3 Services v1 integrated
the utterances of the thread, select the “Conversation thread” tab in the bottom part of the screen. - The area in the middle part of the widget is used to display the collaboration evolution graphic that changes with each utterance in the conversation. Graph algorithms are used to compute this measure for each utterance. Other graphics that have an evolution through the entire conversation are also displayed in this area. - The bottom area of the widget consists of three tabs. The first one is used for changing the visualization options: zooming, highlighting the utterances in each thread, displaying time information, etc. The second tab is for present the text of the utterances in a selected thread. The last tab is used for discovering special threads like repetitions of concepts or more advanced threads based on patterns.
Task T5.2 summary writing The student has written a synthesis about the course texts and asks the service for feedback. As can be seen in Figure 13, the computer has calculated feedback. The feedback indicates 1/ the coherence of each synthesis sentence with the next and previous sentence, 2/ the relevant of synthesis sentences and 3/ if the ideas of course texts are in the synthesis. The feedback 1 and 2 are shown at the bottom of the screen. Two views are available. The displayed view in the screenshot is a view with a table. The other view indicates the same feedback in tool tips that appear when the student hovers over the sentences of his synthesis. The feedback 3 is displayed on the course text. The sentences that are not semantically close from the synthesis’s sentences are underlined. After reading the feedback, the student selects another action (modify the synthesis, fill his notepad, read other courses, synthesize another course domain, or disconnects).
29 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 13. Snapshot of PenSum, the summary writing service.
Task T6.1 Formal Learning Support System
Figure 14. Snapshot of the FLSS.
30 LTfLL -2010-212578
D2.3 Services v1 integrated
The system provides facilities for annotating, reading and updating learning materials. The main components of the user interface are ontology browsing, course browsing, learning object browsing, annotation editing, and updating. The ontology provides domain concepts for the annotation and search. The course is represented as a set of learning documents. These documents are annotated in order to be searched in. The structure of the document is presented in two ways: text presentation for reading, annotated format for exploration of the annotation and for adding new annotation. A summary of the concept annotation of the document is presented in a table view for quick navigation in the annotation of the document. The user (tutor or learner) can add additional documents to be annotated automatically on the basis of the language pipe. The annotated document is stored in the repository of the system. The user can also perform a semantic search over the already annotated learning materials. Task T6.2a Social component of public knowledge
Figure 15. Snapshot of semantic search (task 6.2a).
The semantic search from task 6.2a is based on an automatically enriched version of the LT4eL ontology. The domain ontology has been enriched using 31 LTfLL -2010-212578
D2.3 Services v1 integrated
a combination of reference ontologies and social media data. It starts by taking input from a tag analyzer service and queries reference ontologies extensively to relate the tags to concepts. Various heuristics are employed to discover their taxonomic relations with existing concepts in the domain ontology. If the concept(s) from the reference ontology passes the tests, it is added with the supposedly correct taxonomic relation to the domain ontology. The service combines and reasons about the inputs from similarity measures, a reference ontology and a tag concept-linker. The learner can enter one or more terms in the search box. These terms entered are mapped to concepts from the enriched ontology. As a result, an ontology fragment is displayed that contains these concepts. In addition, the system provides the learner with a list of Delicious bookmarks that match the query. Once an ontology fragment has been created, the learner can browse through the ontology to get more information on the domain. Clicking on a concept puts this concept in the centre and shows how it is related to other concepts. The document list is adapted each time a new concept is clicked as well. To enhance the learning process even further, a definition is shown when the learner clicks on a term. When the learner wants a more extensive description, he can click on 'read more...' to go to the Wikipedia page of the term. Task T6.2b Social component of public knowledge The 6.2b widgets are developed according to the standards mentioned above. The image above shows the three widgets developed inside this task: - a search widget that displays resources and users from the learner's social network. Each row displays a link to the resource, the username and link of the user that created or tagged the resource and also the tags used for describing the resource. - a recommendation widget that shows the best suited bookmarks, videos, presentations and images for the current user. - a profiling widget that shows the tags that best describe the learner and that also allow the learner to download a file containing this profile.
32 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 16. Snapshot of the three widgets developed in task 6.2(b)
3.5 Guidelines: localisation and corporate design in a distributed environment For version 2, the widgets created in this project should share the same appearance so that their origins are easily recognized. Therefore we propose a strategy for realising a common look & feel across the developed widgets. The first thing to do for this is to think about what parts a widget should consist of. When putting widgets into a container platform like Elgg, the user chooses whether to include one widget or several. The user will also put in some widgets that are not related to the project, but useful in a learning context. Therefore, it is important that a logo is displayed in the widget. This has two drawbacks: (1) the visual impression of the container can be overwhelmed by repeated elements and (2) the already quite limited size for the actual content is further reduced. Another important part of the widget is the title of it and an easy way to find help. Widgets developed in this project are not self-explanatory so this is quite crucial for the user experience. To aid the partners in creating similar widgets, a template system was created. The parts of the widget that are common to all widgets are stored in a 33 LTfLL -2010-212578
D2.3 Services v1 integrated
template directory to separate this design part from the rest of the code. A JavaScript library was created that generates the necessary parts of the user interface, so that the basic HTML of the original widget is not cluttered with design parts.
Figure 17. A widget sample based on the template.
The widget template contains the colours in the following table. The widget developer may try to use colours matching those colours so that widgets generated in this project look similar.
Colour Name
Value
Darker Blue
#1d4f8a
Brighter Blue
#6cb1d8
Green
#9add5b
Background
White (#ffffff)
Text
Black (#000000)
The template is located at this url: https://ltfll.svn.sourceforge.net/svnroot/ltfll/Wp2/widgets/_template
To create a new widget based on this template, it is first needed to export this directory using Subversion (SVN) like in this command: svn export https://ltfll.svn.sourceforge.net/svnroot/ltfll/Wp2/widgets/_template
34 LTfLL -2010-212578
D2.3 Services v1 integrated
The template already contains everything to be a widget - but it will only display (place your content here). The widget developer needs to replace line 18 with custom HTML. The JavaScript code should be placed into the file scripts/index.js, so that the HTML is not cluttered with programming logic. 1.
2.
3.
4.
5.
6.
7.
8.
9.
10. 11. 12. 13. 14. 15. 16. 17.
18. (place your content here) 19.
20. 21. 22.
Listing 1. File index.html after template initialisation.
Widgets can easily be localized by placing files in language-specific folders. The widget container will deliver a localized file depending on the browser language settings - the widget developer does not need to care about that. Nevertheless, a lot of things can be done the wrong way. To make the application easily translatable, it is necessary to put all strings into a single resource file. Text displayed to the user must not be mixed with the widget 35 LTfLL -2010-212578
D2.3 Services v1 integrated
code. String concatenation must not be used because the word order in different languages might be different. The best possible way is to use place holders for values to be filled in. Therefore, several JavaScript functions were created to extract the string resources from the resource files and to replace the placeholders with actual values. The strings in the default language should be placed in strings.js, which is located in the root directory of the widget. After the template initialization strings.js contains only the minimal information that is needed for the widget. The application title needs to be modified to something meaningful. 1. Strings={ 2. ApplicationTitle: '(place your widget title here)' 3. ,HelpLink: 'Help' 4. }; Listing 2. File \ after template initialization.
Using the previously mentioned GetString() function, it is possible to separate the generated HTML code from the variables in a clean way to support easy localization. In the following example, the HTML code is placed in index.js - because the code does not contain user presented text. The GetString() function expects two parameters - the string that contains the placeholders and an object with properties for each placeholder. The returned string (in the variable html) would contain the replaced values. If this were a user-presented text, the string would be placed in strings.js.
1. var htmlTableRow = "
${Word}
${Count}
" 2. var html = Tools.GetString(this.htmlTableRow, {Word: word.word, Count: word.count, Width: width}); Listing 3. Example for using localization functions.
3.5 Guideline: inter-widget communication The context of sharing data between widgets is a crucial one because we are targeting not only a side-by-side widget integration (for version 2 of the ser36 LTfLL -2010-212578
D2.3 Services v1 integrated
vices), but also want to have the possibility to model basic workflows. Therefore, widgets must have the ability to share data between certain contexts and must also be able to trigger and listen to events invoked by different widgets. By now the Wookie engine is using Comet style to send events and share data according to a 'sibling rule'. This means that state is shared between widgets which have (a) the same GUID (i.e. same type of widget), (b) the same API key (i.e. originating from the same system or application) and (c) the same shared data key, of course. This is perfectly fine if we want, for example, to implement a chat widget where different users can interact with each other using the same type of widget in the same application. But as we want to go beyond this simple data sharing mechanism, we have to either extend the Wookie engine functionalities or use alternative communication techniques. We have investigated different communication strategies (HTML 5 postMessage API, AJAX over service back-end, session/cookie based etc.); every method had its advantages and disadvantages. After carefully weighing the pros and cons, we decided that it would be best to add needed functionalities to the Wookie engine instead of using other external techniques. This technique has the advantage that Wookie is further developed with functions where requirements for inter-widget communication have already arisen from the community some time ago. As the code changes needed for implementing the functionality in Wookie seemed manageable, we thought that this solution is also the most cost effective. Last but not least, we believe that it is a good idea to have all widget based functionality provided by only one software package. In the scope of our services, we need to share data mostly between the different widgets of one user. This meant by heading towards the option to adapt the Wookie source code that we had to implement a different sibling rule. Therefore, we modified Wookie's data sharing policy so that data sharing is restricted only to (a) the same API key, (b) the same shared data key, and (c) the same user ID (or user session). This implies replacing the restriction of the same GUID with the same user ID (or user session). Of course, the Elgg plugin had to be modified, as well. This is one reason (but not the only one) why we are using a slightly modified and extended version that is not yet publicly available. For this version, we have adapted the Wookie REST calls to transmit the Elgg User ID as shareddatakey instead of Elgg's GUID of dashboard widget instances. 37 LTfLL -2010-212578
D2.3 Services v1 integrated
Wookie implements some additional features, which are extensions of the W3C Widgets specification and not now supported in the same way by other widget engines. For inter-widget communication, Wookie's shared data API is of special interest. Its methods allow not only for storing and accessing data throughout various instances of a widget but also invoking specific events after a shared variable is set (like updating a widget or displaying different contents and the like). The methods sharedDataForKey(), setSharedDataForKey() and appendSharedDataForKey() are of paramount importance. As these are asynchronous, a callback handler must be provided.
Widget.instanceid_key() attribute
The read-only identifier generated by the widget engine for a widget instance.
Widget.sharedDataForKey(key, cb) method
Returns the value of shared data for key, or 'undefined' if there is no match. When completed, invokes function cb with the return value.
Widget.setSharedDataForKey(key, val, cb) method
Sets the value of shared data for key to value, overriding any existing value. If there is no match, creates a new shared data entry for key with value. When completed, invokes cb with the return value.
Widget.appendSharedDataForKey(key, Appends the value of shared data for key with value. If there is no matching val, cb) key, creates a new shared data entry method for key and sets it to value. When completed, invokes cb with the return value.
Widget.onSharedUpdate event
Called when a shared data entry is updated with the shared data key affected.
The communication flow and update mechanisms are based on the Direct Web Remoting (DWR) engine (Marginian and Walke, 2010). DWR allows for the interaction of Java code on the server (in the case of Wookie: managing data storage and distribution procedures) and JavaScript code executed 38 LTfLL -2010-212578
D2.3 Services v1 integrated
within the browser. The necessary JavaScript sources are generated automatically, as well as the marshalling of data. Normally, the update notice on shared data is sent to the client as a response to the next HTTP request ('piggyback'); nonetheless, DWR provides reverse AJAX functionality (push) to publish updates to definable groups of clients rapidly in order to ensure an effective update mechanism. Wookie is taking advantage of the DWR feature reverse AJAX by using the polling method (the browser sends a request to the server in regular and frequent intervals to check if there are some updates) for pushing data from server to browsers. We used the newest Wookie engine version from the SVN repository (revision 886096 2009-12-02 19:08) to implement our modification. As this version was not the official beta release (which was version 0.8) there were, of course, some code changes and some changes also affecting the widget manifest file. There, the push-feature has to be switched on, which can be done by inserting the following line in the config.xml:
The communication flow and JavaScript functions to implement the use of shared data among different widgets as well as event notifications are displayed in Figure x. The init() function is called on load and retrieves at first the shared data key for the specific widget instance, which has been defined previously during widget initialization request. This key is necessary to detect update notifications intended for a specific widget instance. The callback function initSharedKey is called with the key as parameter - it simply sets it to the globally available variable sharedKey. Next, instanceID - thus a unique widget instance identifer - is retrieved and set using Widget.instanceid_key function. Finally, the update handler is registered. Widget.onSharedUpdate() is a function called from the server via remote execution when performing a shared update notification. In this case the function is assigned the value of handleSharedUpdate, with the shared data key as parameter. Thus, if on a shared update the update key is identical to the instance’s shared data key and the corresponding if-clause in function handleSharedUpdate() returns true. Widget.sharedDataForKey() then retrieves the shared data value for the key msg. At last the callback handler refreshPage is invoked doing something like refreshing the page or updating its content (not displayed here). The Widget object (as well as helper functions for browser type and version 39 LTfLL -2010-212578
D2.3 Services v1 integrated
detection) is provided by Wookie through a JavaScript wrapper file called wookie-wrapper.js.
Figure 18. Code example using the shared data interface.
If we assume to have two widgets that need to talk to each other, an exemplary workflow can be seen in Figure x. There, Alice initiates the shared update by setting a new value to the shared variable msg (1). As in this example both Alice and Bob are listening for shared updates (2), also both widgets are retrieving the newly set variable from Wookie (3). In the end, Wookie serves the variable to both clients and a call-back handler (refreshPage()) is invoked. In both cases, it updates the page with the data retrieved. Of course, it is also possible that just one or more than two widgets are listening to shared updates and filtering the variables that are supposed to trigger an event. Events are defined on a per-widget basis that means on a shared update, different behaviours of different widgets can be realized.
40 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 19. Workflow example using the shared data interface.
With our extension of Wookie, we implemented two additional data sharing policies: besides “DEFAULT” (the sibling rule described at the beginning of this section), the first allows for an update over all currently instantiated widgets, no matter what type (“ALL”), while the second is emulating a peruser update (“SAMEUSER”), which is based on the HTTP-session-ID. Of course, another user identification then through sessions would be possible as the user ID of the embedding web application (Elgg) is exposed to Wookie (further work). In order to activate the new mechanisms, Widgets have to call DWRInit() in their init() function. Moreover, the administration user interface was extended to give easy access to the new data sharing options. Therefore, a new page to Wookie's administration interface was added allowing for the control of the three different data sharing policies. As our modifications to the Wookie server are quite new, they still need to be tested extensively which will be done in the next couple of weeks. As further work, we will also investigate in conjunction with the WP3 threads if we need additional data sharing policies (e.g., different users plus different widgets) and if needed implement them. In the near future - after the test and docu-
41 LTfLL -2010-212578
D2.3 Services v1 integrated
mentation phase - we also plan to contribute to the Wookie community by committing our changes to the SVN repository.
3.6 Guideline: authentication with openID According to studies (Davies, 2007), young people rank the theft of personal details with 65% as the worst thing someone could steal, followed on the next rank with 22% by the mobile phone. Government agencies, such as the Information Commissioner’s Office (ICO) warn that at the same time "almost six in ten have never considered that what they put online now might be permanent and could be accessed years in the future" (ICO, 2007). Digital traces left in learning obviously touch upon data of a very sensitive nature about the individual. Especially when monitoring conceptual development, data about what a learner most probably knows suddenly become available in condensed, digital, and machine-processible form. For many, the computer is merely an outsourced part of the brain. To provide adequate protection of this desired privacy, the T4.2 service prototype CONSPECT has investigated the use of openID for authentication and access control using capability-based credentials for authorisation. The main advantage of openID thereby is that it provides possibilities for anonymity (or more precisely: pseudonymity). Individuals are not restricted in their choice of an identity provider and they retain control of what they want to expose in their digital profile. Identity-resolution can take place only in the mind of the users. When logging onto a system using an openID (step 1 in Figure 20), the system contacts the identity provider to generate a shared secret (steps 2-3). Then the user is redirected to the identity provider to validate the request (log on to the identity provider, grant access using the shared secret). Given that everything went fine and the user validated the login request, the user then enters the system – authenticated with his openID.
42 LTfLL -2010-212578
D2.3 Services v1 integrated
Figure 20. OpenID workflow (Thompson, 2008).
Additionally, granting access based on credentials rather than identity provides the means to establish trust between the users: access to snapshots of data is granted through explicit acts of disclosing a 'password protected' URL to carefully selected communication partners. This can serve as a construction principle for growing more complex, but still implicit trust relationships on top of data access to privacy-sensitive information. Capability-based credentials as such (when key- or ticket-bound, not name-bound) regulate access control better and can replace identity-based credentials of centralised authentication and authorisation protocols (cf. Bhatti et al., 2007; Miller et al., 2003; Levy, 1984).
Figure 21. Ticket-bound credential in URL granting access to a conceptogram.
43 LTfLL -2010-212578
D2.3 Services v1 integrated
When inspecting a conceptogram, the owner can decide to share a 'private' link to this exact conceptogram with any other person e.g. via email. The conceptogram thereby is only a 'one point in time' visualisation of the data contained in a feed, not the feed itself. When the recipient of such a link clicks on it, she/he has to log on to CONSPECT where a copy of the conceptogram is stored into her/his list of conceptograms. Further extensions of this, e.g. with expiring links, are under discussion. WP2's extended Wookie plugin for Elgg supports basic OpenID authentication. Elgg does not support OpenID logins out-of-the-box, but a plugin exists providing these functionalities. The implementation passes through the OpenID from the Elgg container to the Wookie container and further on to the widget. This means that the authentication mechanism is not part of the Wookie engine functionality, but in the hands of the widget itself. This method was much more cost effective compared to implementing the whole OpenID authentication technique in Wookie, but it has the trade-off that every widget has to integrate OpenID functionality on its own. It is not too difficult as WP2 has distributed examples showing how to do it and many open-source libraries for nearly every programming language exist. Nevertheless, we are looking forward to Wookie engine v1.0 where ticket based authentication methods will be integrated internally. Since the OpenID protocol does not force the identity provider to release any private information such as the email address, the OpenID identifier itself is the only remnant stored within Elgg. This identifier is stored as an Elgg metadata entity in the database and is read from the plugin by using the global Elgg variable $vars. This has the advantage that the OpenID plugin remains untouched and only the Wookie plugin had to be modified. Subsequently, the Wookie plugin hands over the OpenID as a parameter openid_identifier in the widget calling URL. Since the widget page is HTML, a JavaScript regular expression is used to parse the URL for the openID parameter, so that it can be handed over to the widget which is taking care of the authentication process. For example, in the case of CONSPECT the freely available PHP OpenID Library (JanRain, 2009) provides the necessary routines to cope with the OpenID authentication methods. As for now, our OpenID approach seems to be sufficient, but as future work we have noted to switch to Wookie's internal authentication system once available. There are also internal discussions about extending a token-based authentication and authorization mechanism for web-services that should be 44 LTfLL -2010-212578
D2.3 Services v1 integrated
implemented directly in Wookie. WP2 proposed and is moderating a discussion of whether we really need more authorization methods than the ones directly described and already developed. We will report on the progress and outcome of this issue in the upcoming deliverables.
45 LTfLL -2010-212578
D2.3 Services v1 integrated
4. Summary & Outlook
Within this deliverable, we have documented the state of interoperability of the version 1 service prototypes. Focus lay on creating widgets, creating web service interfaces, negotiating data formats. The Elgg report documents our efforts to bring together and manage the distributed components and allow for their flexible recombination along the planned integration threads. Additional integration facilities have been reported upon and guidelines pave the way for deep integration in version 2 of the service prototypes. These facilities include support for localisation, corporate design, inter-widget communication, and authentication. Many initial ideas on deep integration have been proposed (see D4.2, D5.2, D6.2), additional ideas are being investigated. Under the auspices of WP3, these integration threads will be matured and jointly realised within the scope of WP2/4/5/6. WP7 will monitor their validity. The main challenge for the upcoming ‘version 2’ development wave resides in the extension of interoperability to serve the flexible recombination of the functionalities within the service prototypes along these integration threads.
46 LTfLL -2010-212578
D2.3 Services v1 integrated
Annexes
A. Installing Wookie for Elgg These are the installation instructions for Wookie v0.8, Elgg v1.6.1, and the plugin v2.1. For the plugin to work, Elgg and the Wookie engine must be configured and running. - Download the plugin and place it in [elggDir]/mod/ - Adapt the file [elggDir]/mod/wookie/views/default/widgets/wookie/functions.ph p: o $vars['entity']->wookie_url (URL to the Wookie engine, e.g. http://augur.wu.ac.at:8080/wookie/) o $vars['entity']->wookie_api_key (Each individual web application needs its own API key which can be generated from Wookie's administration interface.) - Enable the plugin via the tool administration panel in Elgg - Now you should be able to add Wookie widgets to your dashboard. This can be done by choosing the features you want to add to your page by dragging them from the widget gallery, to any of the three widget areas of your dashboard, and position them where you would like them to appear.
47 LTfLL -2010-212578
D2.3 Services v1 integrated
B. LSA Infrastructure We are using the statistical programming language R and develop the "lsa" package (Wild, 2009) for the calculations needed in our LSA infrastructure. More details on the change history of the 'lsa' package can be found in the package history. An additional release is planned. In order to be able to calculate sufficiently large semantic spaces that include a sufficient amount of terms and documents with a reasonable amount of memory needed, a sparse Term-Document-Matrix (TDM) is required. To create these sparse matrices, we have built and improved the "tm" textmining R package (Feinerer, 2010) and modified the code to allow for an even less resource intensive building of the TDM as well as additional weighting and filtering preprocessing options as required by our workpackage tasks. Since the default SVD in R as called by the "lsa" package cannot handle these sparse (column oriented) matrices, we are using the SVDLIBC (Rohde, 2009), an external C library to perform the sparse SVD. To interface the sparse matrix created by R to this library and the output back to R, interface functions have been written in R, which produce and read text files the SVDLIBC is able to handle. This additionally offers the advantage that the singular value decomposition can be stopped when the requested amount of singular values have been calculated. The HTML based web interface for the semantic space generation and management communicates with these modules via rapache (Horner, 2009), an apache module allowing for execution of R code on our apache webserver. Once the spaces are calculated, they are stored on hard disc and may be loaded into memory for faster access by using RServe (Urbanek, 2009).
48 LTfLL -2010-212578
D2.3 Services v1 integrated
C. Streamlined Cognitive Walkthrough Guiding questions 1) Will the user know what to do at this step? 2) If the user does the right thing, will they know that they did the right thing, and are making progress towards their goal? Ground rules 1. 2. 3. 4.
No designing No defending a design No debating cognitive theory The usability specialist is the leader of the session
49 LTfLL -2010-212578
D2.3 Services v1 integrated
D. Description of the exposed services of all service prototypes. Subsequently, the exposed (and only the exposed!) services of the prototypes developed in the tasks of WP4/5/6 are documented. This documentation serves the further, ‘deep’ integration as planned together across the project. Several of the prototypes do already work together. One prominent example is the re-use of the LSA-space calculation and evaluation services in the tasks T4.1, T4.2, and its initial uptake in T5.2 (and planned T5.1 integration).
T4.1 Positioning
Name
Autograde Answer
Description
Calculate a grading measure for an answer to a question based on LSA and already graded answers.
A flex graph rendering engine that takes graphML as input and renders it visually using a force-directed lay-out.
URI
http://augur.wu.ac.at/conspect_1/libs/fossa.swf
Method
REST / GET text : string "http://url" The url has to point to a graphML file such as:
Parameter
deliverables1 FF9900 0.5 000000 This is more information about deliverables. data/skin.xml 1 skin2 66CC66 0.8 FF6633 This is more information about patient. data/skin.xml 2 socialnet3 0099CC 1 996633 This is more information about socialnet. data/socialnet.xml 4
57 LTfLL -2010-212578
D2.3 Services v1 integrated
0.413 000000 plan12 where did this planning come from? 999999 plan13 where did this planning come from? 3 8
test
Embedding
Output Format
A rendered graph.
58 LTfLL -2010-212578
D2.3 Services v1 integrated
Output Sample
Name
agreement.rws: Calculate Graph Agreement
Description
The service accepts two URLs pointing to graphML files as input and returns a graphML file combining both while marking differences visually.
Data (optional, none only with POST) Output Format
HTML : list of feeds of the user
Output Sample
T5.1 Feedback and Analysis Service related
Name
Chat and Forum Analysis Service
Description
Computes the feedback for a chat conversation or a discussion forum, by using a NLP pipe, WordNet, LSA and a domain ontology (facultative), plus SNA and graph algorithms. The input conversation shall be annotated with textual feedback for the whole conversation and for each participant, implicit references, speech acts, argumentation acts, grades for each utterance and for each participant, SNA scores.
linkToChat: URL The only mandatory parameter is an URL to an XML input file that contains a chat conversation or
62 LTfLL -2010-212578
D2.3 Services v1 integrated
a discussion forum. response: string (optional) Output format (e.g. application/json) Data (optional, none only with POST) Output Format
XML / SOAP (if the parameter response is not present) JSON (if the parameter response=application/json) E.g.: JSON format {"processMainResponse":{"return": "http:\/\/ltfll-lin.code.ro\/axis2\/axis2-web\/ ltfll\/out\/xmlchat_12_out.xml"}}
The output contains an URL to the location where the output XML file is stored on the server. This XML file contains the original conversation, plus annotations that are made by the system and are used for providing feedback and support the learners and tutors:
Output Sample
Name
Search Chat and Forum Service
Description
Given a query defined by the user, it searches for relevant utterances and participants for a chat conversation and discussion forum.
linkToChat : URL The only mandatory parameter is an URL to an XML input file that contains a chat conversation or a discussion forum. query: string The search query. response: string (optional) Output format (e.g. application/json)
Data (optional, none only with POST)
64 LTfLL -2010-212578
D2.3 Services v1 integrated
Output Format
XML / SOAP (if the parameter response is not present) JSON (if the parameter response=application/json) E.g.: JSON format {"searchConversationResponse":{"return":"http:\/\/ltflllin.code.ro\/axis2\/axis2web\/ltfll\/out\/xml\/search_out_chat_25.xml"}} The output contains an URL to the location where the output XML file is stored on the server. This XML file contains the results of the search (both utterances and participants), ordered descending by relevance:
Output Sample
This is the last question that I want you to think about in my lesson of today.all of you submitted solutions, then let me ask a question of each of you.I now ask the question, are these all the same? Do you have any question, such as This is the next question.T
Course and Assignment Management related Name
List Courses, List Domains
Description
Lists the courses available in the database. Lists the domains available in the database.
id : integer (optional) Only returns the assignment with this id cid : integer (optional) Only returns the assignments that are in the course associated with cid
Data (optional, none only with POST) Output Format
JSON An array with the information about the assignments, packed as JSON.
Output Sample
[{"0":"18","assignment_id":"18","1": "Collaborative Technology","assignment_name": "Collaborative Technology", "2": "Comparison between web technologies used for collaboration: blog, chat, wiki, forum, etc.","assignment_topic": "Comparison between web technologies used for collaboration: blog, chat, wiki, forum, etc.","3":"1","assignment_active":"1","4": "chat\r\nblog\r\nforum\r\nwiki\r\ncompany","assignment_concepts": "chat\r\nblog\r\nforum\r\nwiki\r\ncompany","5":"2010-01-25 19:45:43","assignment_date": "2010-01-25 19:45:43","6":"1","assignment_type":"1","7":"1", "course_id":"1"}]
Name
Insert/edit/delete assignment
Description
Creates a new assignment for a course in the database. Edits an existing assignment from the database. Deletes an assignment from the database.
31 ; 81 ; 1 ; Quelques mails extraits de la liste de discuss ion... ; 2 ; bold ; none ; underline ; #000000 ; #000000 32 ; 8 ; 2 ; Mail d'une étudiante à la liste de son groupe de... ; 2 ; bold ; none ; none; #000000 ; #000000 34 ; 8 ; 3 ; chers collègues de la classe virtuelle ; 1 ; none; italic; none; #000000 ; #000000
68 LTfLL -2010-212578
D2.3 Services v1 integrated
Name
Display Add Texts
Description
Display the course texts selected by the student http://augur.wu.ac.at/summary-writing/pensum_test/engine.inc.php
URI function DisplayAddText() Method
GET
Parameter
username : string addtext : integer (id of additional text)
Etes-vous au contraire plus réticent face. ;0 à des productions qui vous paraissent transgressiv... ;0 pour la langue ? ;1
69 LTfLL -2010-212578
D2.3 Services v1 integrated
Name
Record synthesis
Description
Record the synthesis sentence by sentence in the database http://augur.wu.ac.at/summary-writing/pensum_test/engine.inc.php
URI function RecordSynthesis() Method
GET
Parameter
Data : array [synthesis_id][sentences[linessynthesis_sentence, linessynthesis_endparag]]
Data (optional, only with POST) Output Format
Boolean
Output Sample
True
Name
Feedback 1
Description
Compute and display the feedback on the coherence between consecutive sentences of the synthesis http://augur.wu.ac.at/summary-writing/pensum_test/engine.inc.php
URI function Feedback1() Method
GET
Parameter
File_username : string synthesis : integer (id of synthesis)
Data (optional, only with POST) Output Format
Array [] ; the elements are the numbers of the sentences in the synthesis which have a semantic proximity with the next sentence below a threshold
Output Sample
1 ;4 ;6 ;18 ;23
Name
Feedback 2b
Description
Compute and display the feedback on the relevance of sentences of the synthesis http://augur.wu.ac.at/summary-writing/pensum_test/engine.inc.php
URI function Feedback2b()
70 LTfLL -2010-212578
D2.3 Services v1 integrated
Method
GET
Parameter
File_username : string synthesis : integer (id of synthesis)
Data (optional, only with POST) Output Format
Array [] ; the elements are the numbers of the sentences in the synthesis which have all the semantic proximities with each sentence of course texts below a threshold
Output Sample
8 ; 9 ;21 ;23
Name
Feedback 3
Description
Compute and display the feedback on the resume of sentences of course texts in the synthesis http://augur.wu.ac.at/summary-writing/pensum_test/engine.inc.php
URI function Feedback3() Method
GET
Parameter
File_username : string synthesis : integer (id of synthesis)
Data (optional, only with POST)
Output Format
Array [course_id.”_”.count(sentence)][] ; For each course text (course_id), we compute the number of sentences of the course (count(sentence)) and we put in an array, the number of sentences of course text which have all the semantic proximities with each sentence of the synthesis below a threshold. 4_53: 5 10 11 37 45
Output Sample
48 6_43: 6 16 18 23 41
71 LTfLL -2010-212578
D2.3 Services v1 integrated
Name
New Seance
Description
Compute and record in the database the number of days where the student logs on http://augur.wu.ac.at/summary-writing/pensum_test/engine.inc.php
URI function NewSeance() Method
GET
Parameter
Username : string synthesis : integer (id of synthesis)
Data (optional, only with POST) Output Format
Boolean
Output Sample
True
Name
Feedback Counter
Description
Compute and record in the database the number of feedback asked by the student on a synthesis http://augur.wu.ac.at/summary-writing/pensum_test/engine.inc.php
URI function FeedbackCounter() Method
GET
Parameter
Username : string synthesis : integer (id of synthesis)
Data (optional, only with POST) Output Format
Boolean
Output Sample
True
T6.1 Formal Learning Support System Name
Language Pipe
Description
The service takes as input plain text in English and produces an annotated XML document, containing: morphological and part-of-speech tagging
semantic annotations
72 LTfLL -2010-212578
D2.3 Services v1 integrated
coreference relations
Implemented as RESTful (HTTP-based) service. The service invocation follows an asynchronous pattern, including submission of text content, checking progress status and result retrieval. Deployment URL
http://www.bultreebank.bas.bg:8080/csf/pipe/
API Specification
1. Publish resource for annotation
method: POST url: /post/ parameters: none message body: plain text for annotation response: sessionID - identifier for the running annotation task (used for checking status and result retrieval) example: POST http://www.bultreebank.bas.bg:8080/csf/pipe/post/
2. Check process status
method: GET url: /status/ parameters: 'id' - status identifier received after operation 1 message body: none response: 'true' or 'false' - meaning completed or in progress accordingly example: GET http://www.bultreebank.bas.bg:8080/csf/pipe/status?id=1234567
3. Retrieve result
method: GET url: /result/ parameters: 'id' - status identifier received after operation 1 message body: none response: annotated XML document or warning message if the processing is still not completed example: GET http://www.bultreebank.bas.bg:8080/csf/pipe/result?id=1234567
Name
Semantic Search
Description
The service exposes functionalities for searching in document annotations based on lexical terms and ontology concept URIs. The query expressions can be enriched by domain ontology expansion.Implemented as RESTfull (HTTPbased) service.
Deployment URL
http://augur.wu.ac.at:8080/semsearch/
API Specification
1. Semantic Search
method: POST or GET (both supported) url: /search/ parameters: 'q' - the query expression, whitespace separated set of terms interpreted as alternatives. Each term is mapped to its corresponding ontology concept URI.
73 LTfLL -2010-212578
D2.3 Services v1 integrated
This enables the query to be expanded by ontology information 'lang' (OPTIONAL) - the language of the input terms. Defaults to English. 'noexpand' (OPTIONAL) - if provided with value 'true' or 'y', query expansion is disabled and only exact matches are returned 'out' (OPTIONAL) - formating of the result. 'html' value produces browsable web page whileany other value results in a simple list of URIs (targeted to machine interaction) message body: none response: List of URIs of documents matching the search criteria example: GET http://augur.wu.ac.at:8080/semsearch/search?q=XML&lang=en&out=html
2. Retrieve a document by URI
method: GET url: /resource/ parameters: 'id' - the URI of the desired document (url-encoded) 'compress' 'y'/'n' to enable/disable data compression: the former returns zipped data (recommended use) while the latter provides plain RDF/XML representation message body: none response: RDF representation of a document example: http://augur.wu.ac.at:8080/semsearch/resource? id=http%3A%2F%2Fwww.bultreebank.org%2Fresources%2FXML_Tutorial. xml&compress=y
T6.2a Social component of public knowledge
Name
DBpedia
Comment
Every operation outputs xml by default, but can also generate json by setting the optional response parameter to json.
URI
http://augur.wu.ac.at:8080/wp62_axis/services/DBPedia Check whether a tag exists in dbpedia.
Input: 1. existsInDBpedia
type existsInDBpedia tag - optional, nillable; type string Name of a tag
Output:
2. getAlternativeLexicalisations
type existsInDBpediaResponse return - optional; type boolean True when the tag exists as a lexicalisation in dbpedia
Retrieve alternative lexicalisations for a tag.
74 LTfLL -2010-212578
D2.3 Services v1 integrated
Input:
type getAlternativeLexicalisations tag - optional, nillable; type string Name of a tag
Output: type getAlternativeLexicalisationsResponse
return - optional, unbounded, nillable; type string List of lexicalisations
Retrieve shared dbpedia categories given two tags.
Input: type getCommonAncestors 3. getCommonAncestors
tag1 - optional, nillable; type string Name of a tag
tag2 - optional, nillable; type string Name of a tag
Output: type getCommonAncestorsResponse
return - optional, unbounded, nillable; type string List of dbpedia category names
Retrieve possible concept URIs for a tag.
Input: 4. getConceptsURIs
type getConceptsURIs tag - optional, nillable; type string Name of a tag
Output:
type getConceptsURIsResponse return - optional, unbounded, nillable; type string List of concept URIs
Retrieve lt4el concept URIs given a specific tag.
Input: 5. getLT4eLConceptsURIs
type getLT4eLConceptsURIs tag - optional, nillable; type string Name of a tag
Output:
type getLT4eLConceptsURIsResponse return - optional, unbounded, nillable; type string List of concept URIs
Retrieve dbpedia properties which hold between two tags. 6. getProperties
Input: type getProperties
75 LTfLL -2010-212578
D2.3 Services v1 integrated
tag1 - optional, nillable; type string Name of a tag
tag2 - optional, nillable; type string Name of a tag
Output:
type getPropertiesResponse return - optional, unbounded, nillable; type string List of property URIs
Check whether the tag is present as a lexicalisation in the lt4el ontology.
Input: 7. isInLT4eLOntology
type isInLT4eLOntology tag - optional, nillable; type string Name of a tag
Output:
type isInLT4eLOntologyResponse return - optional; type boolean True when the tag exists as a lexicalisation in the lt4el ontology
Check whether two tags are synonyms.
Input:
8. isSynonym
type isSynonym tag1 - optional, nillable; type string Name of a tag
tag2 - optional, nillable; type string Name of a tag
Output: type isSynonymResponse
return - optional; type boolean True when the two tags can be resolved to concepts which are synonyms
Name
Definition
Description
A Webservice to retrieve a definition for a concept or keyword.
Comment
Every operation outputs xml by default, but can also generate json by setting the optional response parameter to json.
URI
http://augur.wu.ac.at:8080/wp62_axis/services/Definition Method to retrieve a concept given a single keyword.
1. getDefinition
Input:
type getDefinition term type string A keyword or some term for which a definition exists
76 LTfLL -2010-212578
D2.3 Services v1 integrated
lang type string Language tag (i.e. 'en','nl',...)
context type string Full URI to an ontology identifier
Output: type getDefinitionResponse return - optional, nillable; type string
Method to extract a definition given the full URI of a concept.
Input: type getDefinitionByConcept
2. getDefinitionByConcept
concept type string Full URI to a concept of some ontology that is loaded
lang type string Language tag (i.e. 'en','nl',...)
context type string Full URI to an ontology identifier
Output: type getDefinitionByConceptResponse
Name
return - nillable; type string A raw string with the requested definition
DisambiguateTaggingService
Comment
Every operation outputs xml by default, but can also generate json by setting the optional response parameter to json.
URI
http://augur.wu.ac.at:8080/wp62_axis/services/ DisambiguateTaggingService Resolves a list of terms to concepts by disambiguating them.
Input: 1. mapTermsToConcepts
type mapTermsToConcepts queryString - optional, nillable; type string A space separated list of terms which need to be disambiguated
Output: o
Name Comment
type mapTermsToConceptsResponse return - optional, nillable; type string A list of term, concept pairs
OntologyDocumentSearch Every operation outputs xml by default, but can also generate json by
77 LTfLL -2010-212578
D2.3 Services v1 integrated
setting the optional response parameter to json. URI
http://augur.wu.ac.at:8080/wp62_axis/services/OntologyDocum entSearch Retrieve a list of documents by providing a single concept.
Input: type getDocuments
1. getDocuments
concept - optional, nillable; type string A concept URI
lang - optional, nillable; type string Language tag (i.e. 'en','nl',...)
contextURI - optional, nillable; type string Full URI to an ontology identifier
sortingMethod - optional, nillable; type string Name of the document sorting method (recent, popular, specific)
Output:
type getDocumentsResponse return - optional, nillable; type anyType A list of document URI, title pairs
Retrieve a list of documents by providing a seach query.
Input:
2. getDocumentsByKeywords
type getDocumentsByKeywords keywordString - optional, nillable; type string A space separated list of search terms
languagetag - optional, nillable; type string Language tag (i.e. 'en','nl',...)
sortingmethod - optional, nillable; type string Name of the document sorting method (recent, popular, specific)
queryexpansion - optional, nillable; type string Whether to apply query expansion (1=enabled, 0=disabled)
contextString - optional, nillable; type string Full URI to an ontology identifier
Output:
Name
type getDocumentsByKeywordsResponse return - optional, nillable; type anyType A list of document URI, title pairs
OntologyManagementService
78 LTfLL -2010-212578
D2.3 Services v1 integrated
Comment
Every operation outputs xml by default, but can also generate json by setting the optional response parameter to json.
URI
http://augur.wu.ac.at:8080/wp62_axis/services/OntologyManag ementService Add a new property between two concepts.
Input:
1. addNewProperty
type addNewProperty subject - optional, nillable; type string Full URI of a concept
predicate - optional, nillable; type string Full URI of property
object - optional, nillable; type string Full URI of a concept
context - optional, nillable; type string Full URI to an ontology identifier
Output:
type addNewPropertyResponse return - optional; type boolean True when modification succeeds and false otherwise
Add a new resource to an ontology.
Input: type addNewResource
2. addNewResource
subject - optional, nillable; type string Full URI of a concept
predicate - optional, nillable; type string Full URI of property
object - optional, nillable; type string Full URI of a concept
context - optional, nillable; type string Full URI to an ontology identifier
Output:
type addNewResourceResponse return - optional; type boolean True when modification succeeds and false otherwise
Load an ontology.
Input: type addOntology 3. addOntology
ontologyLocation - optional, nillable; type string Full URL to an ontology in RDF+XML format
Output:
type addOntologyResponse return - optional, nillable; type string Full URI to an ontology
79 LTfLL -2010-212578
D2.3 Services v1 integrated
identifier Export the ontology in RDF/XML.
Input: type exportOntology 4. exportOntology
context - optional, nillable; type string Full URI to an ontology identifier
Output: type exportOntologyResponse
return - optional, nillable; type string Raw RDF/XML of ontology
Retrieve all the lexicalisations in some ontology.
Input: type getAllLexicalisations 5. getAllLexicalisations
context - optional, nillable; type string Full URL to an ontology in RDF+XML format
Output: type getAllLexicalisationsResponse
return - optional, nillable; type anyType List of lexicalisations
Calculate the number of steps needed to reach another concept from some other concept.
Input: type getDistance
6. getDistance
concept1 - optional, nillable; type string Full URI of a concept
concept2 - optional, nillable; type string Full URI of a concept
context - optional, nillable; type string Full URI to an ontology identifier
Output: type getDistanceResponse
return - optional; type int Number of steps in ontology (properties)
Retrieve all possible lexicalisations for a specific concept. 7. getLexicalisationForConcept
Input: type getLexicalisationForConcept
concept - optional, nillable; type string Full URI of a concept
lang - optional, nillable; type string Language tag (i.e.
80 LTfLL -2010-212578
D2.3 Services v1 integrated
'en','nl',...)
context - optional, nillable; type string Full URI to an ontology identifier
only_single - optional; type boolean Whether to only return a single lexicalisation
Output:
type getLexicalisationForConceptResponse return - optional, nillable; type anyType List of lexicalisations
Calculate the numxber of classes in some ontology.
Input: type getNumberOfClasses 8. getNumberOfClasses
context - optional, nillable; type string Full URI to an ontology identifier
Output:
type getNumberOfClassesResponse return - optional, nillable; type string Number of classes in ontology identified by context
Retrieve a list of ontological properties which hold between two tags (automatically resolve them to concepts).
Input:
9. getProperties
type getProperties concept1 - optional, nillable; type string Full URI of a concept
concept2 - optional, nillable; type string Full URI of a concept
context - optional, nillable; type string Full URI to an ontology identifier
Output:
type getPropertiesResponse return - optional, nillable; type Set
o
empty - optional; type boolean
List of properties Check whether concept2 is in a subclass of concept1 at some level.
Input:
type inHierarchy concept1 - optional, nillable; type string Full URI of a concept
concept2 - optional, nillable; type string Full URI of a concept
context - optional, nillable; type string Full URI to an ontology
10. inHierarchy
81 LTfLL -2010-212578
D2.3 Services v1 integrated
identifier
Output:
type inHierarchyResponse return - optional, nillable; type Set
o
empty - optional; type boolean
Retrieve and store an external ontology locally and make it available at some context. 11. loadOntology
Input: type loadOntology
context - optional, nillable; type string Full URI to an ontology identifier
Associate a list of terms with the most likely concepts through disambiguation.
Input: 12. queryStringToConcepts
type queryStringToConcepts query - optional, nillable; type string
lang - optional, nillable; type string Language tag (i.e. 'en','nl',...)
context - optional, nillable; type string Full URI to an ontology identifier
Output:
type queryStringToConceptsResponse return - optional, nillable; type anyType A list of concepts
Remove a resource from an ontology.
Input: type removeResource
13. removeResource
resource - optional, nillable; type string Full URI of a concept
context - optional, nillable; type string Full URI to an ontology identifier
Check whether a resource is present in the ontology.
Input: 14. resourceInOntology
type resourceInOntology
resource - optional, nillable; type string Full URI of a concept
context - optional, nillable; type string Full URI to an ontology identifier
82 LTfLL -2010-212578
D2.3 Services v1 integrated
Output: type resourceInOntologyResponse return - optional; type boolean True when the resource is present in the ontology and false otherwise
Execute a sparql query.
Input: type sparqlQuery
query - optional, nillable; type string
Output: type sparqlQueryResponse
return - optional, nillable; type ResultSet
o
15. sparqlQuery
resourceModel - optional, nillable; type Model
closed - optional; type boolean
empty - optional; type boolean
lock - optional, nillable; type Lock
reificationStyle - optional, nillable; type ReificationStyle
o
resultVars - optional, nillable; type anyType
o
rowNumber - optional; type int
Name
VisualizationService
Comment
Every operation outputs xml by default, but can also generate json by setting the optional response parameter to json.
URI
http://augur.wu.ac.at:8080/wp62_axis/services/VisualizationS ervice Create a minimal describing graph starting from a single concept.
Input: type createGraph
1. createGraph
context - optional, nillable; type string Full URI to an ontology identifier
seedConcept - optional, nillable; type string Full URI to a con-
83 LTfLL -2010-212578
D2.3 Services v1 integrated
cept of some ontology that is loaded
lang - optional, nillable; type string Language tag (i.e. 'en','nl',...)
depth - optional; type int Depth of breadth first search for concepts to include starting from the seed concepts
Output:
type createGraphResponse return - optional, nillable; type string A raw json representation of the graph
Create a minimal describing graph based on a list of search terms.
Input:
2. createGraphFromQuery
type createGraphFromQuery queryString - optional, nillable; type string A space separated list of search terms
context - optional, nillable; type string Full URI to an ontology identifier
lang - optional, nillable; type string Language tag (i.e. 'en','nl',...)
depth - optional; type int Depth of breadth first search for concepts to include starting from the seed concepts
Output: type createGraphFromQueryResponse
return - optional, nillable; type string A raw json representation of the graph
username : string type : string (can be known or unknown - returns results only from known people or from
84 LTfLL -2010-212578
D2.3 Services v1 integrated
everybody) pw: password/token for authentication Data Output Format
xml ...
Output Sample
Name
Search for users
Description
Searches the learner's network for users for a given query.
URI
http://141.85.37.58:8090/users/
Method
GET
Parameter
resulttype: GraphML or XMLlist usr: string pw: string (authentication token or password) n: integer - number of results tags: list of tags space separated
Searches the learner's network for users for a given query.
URI
http://141.85.37.58:8090/resources/
Method
GET
Parameter
resulttype: GraphML or XMLlist usr: string pw: string (authentication token or password) n: integer - number of results tags: list of tags space separated
Data Output Format
GraphML or XMLlist according to the given parameters
Output Sample
Sample for GraphML: same as above Sample for XMLlist
86 LTfLL -2010-212578
Generates an attention profile of the learner consisting in the tags that the learner and his peers are using and monitoring and their importance for the learner.
URI
http://141.85.37.58:8091/apml
Method
GET
Parameter
email: string (the mail of the user) title: string (the title of the document) ss: string (user account on slideshare.net) dl: string (user account on delicious.com) yt: string (user account on youtube.com) fl: string (user account on flickr.com) file: string (the name of the file if the user wants to download it)
Data Output Format
APML 0.6
Output Sample
APML in ELGG SNA APML Generator ...
87 LTfLL -2010-212578
D2.3 Services v1 integrated
References
Bhatti, Rafae; Bertino, Elisa; Ghafoor, Arif (2007): An Integrated Approach to Federated Identity and Privilege Management in Open Systems, In: Communications of the ACM 50(2), ACM Press, pp. 81 – 87 Davies, Gemma (2007): Data Protection, Topline Report, Tri Media Harrison Cowley e-Framework (2010a): Definitions of Service Usage Model Description Elements, online at http://www.e-framework.org/tabid/746/Def ault.aspx?Filters=S, last access: Feb 10, 2010 e-Framework (2010b): Generic Service Usage Model, online at http://www.eframework.org/Default.aspx?tabid=760, last access: Feb 10, 2010 Feinerer, I. (2010). tm: Text Mining project.org/web/packages/lsa/index.html, last
Package. http://cran.raccess on 2010-01-26.
Hoisl, B. (2009a). Elgg Community Wookie Widgets 2.0. http://community.elgg.org/pg/plugins/hoisl/read/322307/wookie-widgets20, last access on 2009-12-21. Hoisl, B. (2009b). Elgg Community Wookie Widgets 2.1. http://community.elgg.org/pg/plugins/hoisl/read/323321/wookie-widgets21, last access on 2009-12-21. Horner, J. (2009). rapache: Web application development with R and Apache. http://biostat.mc.vanderbilt.edu/rapache/, last access on 2010-01-10. ICO (2007): 4.5 million young Brits’ futures could be compromised by their electronic footprint, Press Release of the Information Commissioner’s Office, Ministry of Justice of the UK, Friday 23 November, 2007 Janrain, Inc. (2009). PHP OpenID Library. enabled.com/php-openid/, last access on 2009-12-21.
http://www.openid
Levy, Henry (1984): Capability-Based Computer Systems, Digital Equipment Corporation
88 LTfLL -2010-212578
D2.3 Services v1 integrated
Marginian, D. and Walke J. (2010). Direct Web Remoting - Easy Ajax for Java. http://directwebremoting.org/, last access on 2010-01-26. Miller, Mark; Yee, Ka-Ping; Shapiro, Jonathan (2003): Capability Myths Demolished, Technical Report SRL2003-02, Systems Research Laboratory, Johns Hopkins University Palmér, M.; Sire, S.; Bogdanov, E.; Gillet, D.; Wild, F. (2009): Mapping Web Personal Learning Environments, In: Proceedings of the second international workshop on Mash-Up Personal Learning Environments (MUPPLE'09), ECTEL'09, Nice, France Rohde, D. (2009). SVDLIBC SVD C Library. mit.edu/~dr/SVDLIBC/, last access on 2010-01-10.
http://tedlab.
Spencer, Rick (2000): The Streamlined Cognitive Walkthrough Method, Working Around Social Constraints Encountered in a Software Development Company, In: Proceedings of the CHI 2000, April 1-6, The Hague, Amsterdam, ACM Press, pp. 353-359 Thompson, Bernie (2008): OpenID protocol diagram, online at: http://leancode.com/ 2007/02/23/openid-protocol-diagram/, last access: November 19, 2009 Urbanek, S. (2009). RServe - Binary R Server. http://www.rforge.net/ Rserve/index.html, last access on 2010-01-10. W3C (2009). Widget Packaging and Configuration - W3C Candidate Recommendation 01 December 2009. http://www.w3.org/TR/widgets/, last access on 2009-12-21 Wild, F., Mödritscher, F., and Sigurdarson, S.E. (2008). Designing for Change: Mash-Up Personal Learning Environments. In: eLearning Papers, 2008(9), ISSN: 1887-1542. Wild, F. (2009). An LSA Package for R. http://cran.rproject.org/web/packages/lsa/index.html, last access on 2010-01-26. Wilson, S. (2008). Wookie - Widget Developer's Guide, online at https://svn.apache.org/repos/asf/incubator/wookie/trunk/docs/widget_dev_g uide_09.doc, last access: February 10, 2010
89 LTfLL -2010-212578
D2.3 Services v1 integrated
Wilson, S. and Gardler, R. (2009). Wookie REST API. http://incubator.apache.org/wookie/wookie-rest-api.html, last access on 2009-12-12.
Feb 12, 2010 - fault a course is automatically provided with a customized semantic space, ..... uploading a widget to the Wookie engine it adds lines to HTML files loading ..... six in ten have never considered that what they put online now ...
Feb 12, 2010 - The second part deals with the services used while using the ..... aspect by providing a built-in proxy service that allows the calling of services.
Jan 31, 2016 - D6.1.2: NUBOMEDIA Testbed and simulated load validation v2. 1. NUBOMEDIA: an ... NUBOMEDIA: an elastic Platform as a Service (PaaS) cloud ...... extension with at least 1 network adapter for single node deployment.
Jan 25, 2016 - NUBOMEDIA: an elastic Platform as a Service (PaaS) cloud .... 4.3.3 Network Function Virtualization Orchestrator . .... Figure 1. The NUBOMEDIA development model (right) is based on the popular tree tier development.
Jan 27, 2015 - D4.2.1: Multisensory and Multi-Domain Media Element ... NUBOMEDIA: an elastic PaaS cloud for interactive social ... 10-01-2015 Ivan Gracia.
Jan 27, 2015 - D3.4.1: Elastic Media Manager v1. NUBOMEDIA: an elastic PaaS cloud for interactive social multimedia. 2 ...... Figure,10,Run,time,structure,of,a,topology,. .... network configuration to a new virtual resource. Therefore in ..... Openst
Jan 27, 2015 - 610576. Project web page: ... Adapt â remix, transform, and build upon the material for any purpose, even .... 10. 2.5 Implementation status: ar-âmarkerdetector . ..... an image on top of every face detected in video frames.
Jan 22, 2014 - D3.1.1: NUBOMEDIA virtual infrastructure v1. 1. NUBOMEDIA: an elastic ... NUBOMEDIA: an elastic Platform as a Service (PaaS) cloud ..... The Networking service, code-named neutron, provides an API that lets you define.
Jan 31, 2016 - NUBOMEDIA: an elastic Platform as a Service (PaaS) cloud for interactive social .... 3.1.1 Description of current SoTA . ... 3.2 Orchestration and Management of Real-âTime Network Functions with guaranteed QoS14. 3.2.1 ...
May 4, 2017 - Query deployment status: Depending on the application specific deployment configuration requirements, the deployment procedure on the PaaS and on the media plane could take a few seconds or longer. For long procedures, the user always h
Jan 7, 2014 - NUBOMEDIA: an elastic PaaS cloud for interactive social multimedia. D6.1.1. Version. 1.0 ... Connected and Social Media ... 2.1 Network connectivity . ... 10. Setup testbed . ..... describe the best method to replicate the testbed.
Jan 22, 2015 - D2.1: State-of-the-art revision document v1. NUBOMEDIA: an elastic PaaS cloud for interactive social multimedia. 10 have one or more copies ...
Sep 22, 2005 - new transit bus purchases are for natural gas-fueled vehicles. 4. While the assumptions of GHG benefits of natural gas-fueled vehicles may be based on the best information publicly available today, they are highly uncertain because of
Sep 22, 2005 - business district driving cycle, total GHG emissions from natural ...... 1800. 1. 2. 3. 4. 5. 6. 7. 8. Number of runs. CO. 2 em isssions (g/m ile).
Jan 27, 2015 - NUBOMEDIA. Project title: NUBOMEDIA: an elastic Platform as a Service (PaaS) cloud ..... Figure 1: Software Defined Network Architecture [1] .
Jan 27, 2015 - D4.1: Distributed Media Pipeline Middleware v1. Project acronym: NUBOMEDIA. Project title: NUBOMEDIA: an elastic Platform as a Service (PaaS) cloud ...... processes belonging to different computers in an IP network.
Jan 27, 2015 - D4.3.1: Media Elements for Social and Immersive Environments v1. NUBOMEDIA: an .... 10. 4.1 Implementing social and group real-âtime communications . .... the most popular are the transcoding and mixing ones. .... networks, depend he
Jan 27, 2015 - Connected and Social Media ... NUBOMEDIA: an elastic PaaS cloud for interactive social multimedia ..... Figure 10 Shared cluster architecture .Missing:
Sep 1, 2010 - Learning. LTfLL -2008-212578. Project Deliverable Report ..... The integration involves data communication between both services. This ... format extensions(e.g. .txt, .doc, .pdf) or entering URLs as indicated in visual .... mining, cor
May 6, 2016 - Trading â Equity and Index Derivatives. Technology. Back-office â Futures. Regulation. Tour de la Bourse. P.O. Box 61, 800 Victoria Square, ...
