10101.5k

Transcription

10101.5k

iTEC Project
Title: ITEC-D10_2_V1-1-Appendixes
17092012.Docx
ITEC - WP 10
D10.2 - SUPPORT FOR IMPLEMENTING ITEC
ENGAGING SCENARIOS V2 - Appendixes
“This document has been created in the context of the ITEC project. All information is provided “as
is” and no guarantee or warranty is given that the information is fit for any particular purpose. The
user thereof uses the information at its sole risk and liability. The document reflects solely the views
of its authors. The European Commission is not liable for any use that may be made of the
information contained therein."
CONTRACT NO
2577566
DATE
31/07/2012
ABSTRACT
This document contains the appendixes to Deliverable D10.2 “Support for
Implementing iTEC Engaging Scenarios v2”. These appendixes are highly
relevant to describe the activities carried out by WP10 during the second
year of the project.
AUTHOR,
COMPANY
Luis Anido, Manuel Caeiro, Agustín Cañas, Manuel Fernández,
Rubén Míguez, Victor Alonso, Juan M. Santos (University of Vigo)
INTERNAL
REVIEWERS
Frans Van Assche, Jean-Noël Colin
WORKPACKAGE
WP 10
CONFIDENTIALITY
LEVEL1
PU
FILING CODE
Itec-D10_2_V1-1-Appendixes 17092012
1 PU = Public
PP = Restricted to other programme participants (including the EC services);
RE = Restricted to a group specified by the Consortium (including the EC services);
CO = Confidential, only for members of the Consortium (including the EC services).
INN - Internal only, only the members of the consortium (excluding the EC services)
Page 2/214
iTEC Project
17092012.Docx
TABLE OF CONTENTS
1.
Appendix I: LIST OF ABBREVIATIONS .................................................................................. 7
2.
Appendix II: CONTROL BOARDS ........................................................................................... 9
2.1.
Purpose ........................................................................................................................ 9
2.2.
Third Iteration ............................................................................................................... 9
2.2.1.
Documentation preparation ...................................................................................... 11
2.2.2.
Conclusions from the third iteration .......................................................................... 12
2.3.
3.
2.3.1.
Documentation preparation ...................................................................................... 15
2.3.2.
Conclusions from the fourth iteration........................................................................ 16
Appendix III: FULL SPECIFICATION OF THE SDE API ........................................................ 19
3.1.
Introduction ................................................................................................................. 19
3.1.1.
Availability................................................................................................................ 19
3.1.2.
Accessing the API.................................................................................................... 19
3.1.3.
References .............................................................................................................. 21
3.2.
General remarks ......................................................................................................... 21
3.2.1.
LARG....................................................................................................................... 21
3.2.2.
Requirement ............................................................................................................ 24
3.2.3.
Learning Activities and Learning Stories - Feasibility ............................................... 29
3.3.
4.
Fourth Iteration ........................................................................................................... 13
Methods ...................................................................................................................... 33
3.3.1.
Technical Localisation.............................................................................................. 33
3.3.2.
Resource Planning .................................................................................................. 41
3.4.
Method List ................................................................................................................. 83
3.5.
Errors.......................................................................................................................... 84
Apprendix IV: ENRICHMENT OF DATA ................................................................................ 87
4.1.
Issues on accessing to information sources ................................................................ 88
Page 3/214
iTEC Project
5.
17092012.Docx
4.1.1.
Access to information described in RDF .................................................................. 88
4.1.2.
Access to information not described in RDF ............................................................ 89
4.2.
Record Linkage........................................................................................................... 94
4.3.
Experiments performed............................................................................................... 96
4.3.1.
Some generic enrichment sources ........................................................................... 97
4.3.2.
Tool Enrichment Experiments ................................................................................ 100
Appendix V: INFORMATION EXTRACTION WRAPPERS .................................................. 116
5.1.
Wrappers generating RDF expressions from relational databases (RDB2RDF) ........ 116
5.1.1.
Triplify .................................................................................................................... 116
5.1.2.
Ultrawrap ............................................................................................................... 118
5.1.3.
Virtuoso RDF view ................................................................................................. 119
5.1.4.
D2RQ Platform ...................................................................................................... 120
5.1.5.
ODEMapster .......................................................................................................... 122
5.1.6.
RDBToOnto ........................................................................................................... 123
5.1.7.
RDB2OWL ............................................................................................................. 124
5.1.8.
W3C RDB2RDF ..................................................................................................... 124
5.2.
Wrappers generating RDF from XML documents (XML2RDF) .................................. 128
5.2.1.
GRDDL .................................................................................................................. 129
5.2.2.
Redefer .................................................................................................................. 129
5.2.3.
KREXTOR ............................................................................................................. 131
5.3.
Wrappers generating RDF from HTML (HTML2RDF) ............................................... 131
5.3.1.
GRDDL .................................................................................................................. 132
5.3.2.
RDF Web Scraper ................................................................................................. 132
5.3.3.
Piggy Bank ............................................................................................................ 133
5.3.4.
WebCat ................................................................................................................. 133
5.3.5.
On-to-Knowledge ................................................................................................... 135
5.3.6.
TISP/TISP++ ......................................................................................................... 136
Page 4/214
iTEC Project
A semantic scraping model for web resources ....................................................... 137
5.3.8.
THRESHER ........................................................................................................... 139
8.
Conclusions on the wrappers discussed ................................................................... 139
Appendix VI: METHODS AND FRAMEWORKS FOR RECORD LINKAGE IN RDF ............ 141
6.1.
Key-based Record Linkage solutions ........................................................................ 141
6.2.
Similarity-based Record Linkage solutions................................................................ 142
6.2.1.
SILK....................................................................................................................... 142
6.2.2.
LIMES .................................................................................................................... 144
6.2.3.
LINQUER............................................................................................................... 145
6.2.4.
SemMF .................................................................................................................. 146
6.2.5.
RDF-AI .................................................................................................................. 147
6.2.6.
RAVEN .................................................................................................................. 148
6.2.7.
ObjectCoref&Falcon-AO ........................................................................................ 149
6.2.8.
KnoFuss ................................................................................................................ 150
6.3.
7.
17092012.Docx
5.3.7.
5.4.
6.
Final comments on the tools discussed .................................................................... 151
Appendix VII: ONTOLOGY VERIFICATION ........................................................................ 152
7.1.
Scenario Design Information ..................................................................................... 152
7.2.
Tools & Technical Settings ....................................................................................... 158
7.3.
People ...................................................................................................................... 160
7.4.
Events ...................................................................................................................... 163
7.5.
Content ..................................................................................................................... 165
Appendix VIII: SDE API PRE-TESTING AND DEVELOPERS USER INTERFACES ........... 166
8.1.
Developers’ user interface ........................................................................................ 166
8.2.
Pre-testing user interface .......................................................................................... 168
8.2.1.
Technical Localisation............................................................................................ 169
8.2.2.
Resource Planning ................................................................................................ 173
8.2.3.
Validation ............................................................................................................... 181
Page 5/214
iTEC Project
9.
17092012.Docx
Appendix IX: DETAILS OF THE ONTOLOGY UPDATE ...................................................... 184
9.1.
Ontology Updates ..................................................................................................... 184
9.2.
Additions ................................................................................................................... 184
9.2.1.
ICT Competences .................................................................................................. 184
9.2.2.
Social Annotation ................................................................................................... 186
9.2.3.
Events ................................................................................................................... 187
9.2.4.
Learning Content ................................................................................................... 188
9.2.5.
Resource similarity analysis ................................................................................... 188
9.2.6.
Vocabularies .......................................................................................................... 189
9.3.
9.3.1.
9.4.
10.
Updates .................................................................................................................... 201
Concept Updates ................................................................................................... 201
Deletions................................................................................................................... 206
REFERENCES ......................................................................................................... 208
Page 6/214
iTEC Project
17092012.Docx
1. Appendix I: LIST OF ABBREVIATIONS
ACRONYM
API
CB
CC
DCMI
DILIGENT
FIPA
FOAF
GRDDL
GUI
HTML
IDEF5
IE
IEEE
ICT
IFP
ISBN
ITEC
JDK
JSON
KB
KBS
LA
LARG
LD
LMS
LRE
LOD
LS
MAUT
MAVT
MCDA
MCDM
OWL
RDCEO
RDF
REST
RSS
SDE
SKOS
SOA
SOAP
SPARQL
SWRL
TL
TOVE
MEANING
Application Programming Interface
Control Board
Creative Commons
Dublin Core Metadata Initiative
DIstributed, evoLvInG and loosely-controlled setting
Foundation for Intelligent Physical Agents
Friend of a Friend
Gleaning Resource Descriptions from Dialects of Languages
Graphical User Interface
Hypertext Markup Language
Integrated Definition for Ontology Description Capture Method
Information Extraction
Institute of Electrical and Electronic Engineers
Information and Communications Technologies
Inverse Functional Property
International Standard Book Number
Innovative Technologies for an Engaging Classroom
Java Development Kit
JavaScript Object Notation
Knowledge Based
Knowledge Based System
Learning Activity
Learning Activity & Resource Guide
Link Discovery
Learning Management System
Learning Resource Exchange
Linked Open Data
Learning Story
Multi-Attribute Utility Theory
Multi-Attribute Value Theory
Multiple Criteria Decision Analysis
Multiple Criteria Decision Making
Ontology Web Language
Reusable Definition of Competency or Educational Objective
Resource Description Framework
Representational State Transfer
RDF Site Summary
Scenario Development Environment
Simple Knowledge Organization System
Service-Oriented Architecture
Simple Object Access Protocol
Simple Protocol and RDF Query Language
Semantic Web Rule Language
Technical Localisation
Toronto Virtual Enterprise
Page 7/214
iTEC Project
ACRONYM
TS
UML
UPON
URI
URL
VBE
WI
W3C
XML
MEANING
Technical Setting
Unified Modeling Language
Unified Process for Ontology Building
Universal Resource Identifier
Universal Resource Locator
Vocabulary Bank for Education
Wrapper Induction
World Wide Web Consortium
eXtensible Markup Language
Page 8/214
17092012.Docx
iTEC Project
17092012.Docx
2. Appendix II: CONTROL BOARDS
2.1. Purpose
Along the second project year, Control Boards (CB) continued to perform their activities involving
knowledge engineers and iTEC experts to develop both the SDE and the underlying semantic
model. More specifically, two additional CB iterations took place. The first iteration this year (i.e.,
the third iteration globally) had as its objective to discuss and assess the several factors to be
considered when computing the relevance of resources (cf. D10.2 Sect. 1.2), whereas the aim of
the fourth iteration was to validate the semantic model. We describe below these two iterations,
and we also provide information on how to obtain the complete outcomes of this process.
2.2. Third Iteration
As discussed in D10.2 Sect. 1.2, the process of sorting the resources that potentially will satisfy a
given requirement defined for a Learning Activity is performed according to a utility function
establishing the ranking of each resource. In our case, according to the multicriteria
recommendation approach, this utility function is defined as the weighted sum of some marginal
utility functions, each of them ranking a resource according to a given factor. To identify the factors
to be considered for relevance calculation, WP10 members analysed the properties that describe
and characterise each type of resource. According to this analysis, a collection of factors was
identified. To validate these factors, to quantitatively assess them and to identify new ones, the
initial proposal from WP10 was introduced to a representative group of members from other WPs
in iTEC. The table below collects the people participating in this process.
Table 1. Control board participants for the discussion of recommendation factors
Name
Institution
Main Expertise
Will Ellis
EUN
Application of ICT in learning and teaching
David Massart
EUN
Information retrieval, metadata, interoperability,
standards
Elena Shulman
EUN
Digital curation, semantic interoperability, e-learning,
Library and Information Science
Mark Robinson
PROM
Local and Web Applications & new interaction (multitouch, etc.) web communities
Gill Leahy
PROM
Curriculum development and assessment, particularly
STEM subjects and interactive technologies.
Jean-Noël Colin
FUNDP
Identity, rights and access management
Hoang Minh Tien
FUNDP
identity management, access control management, web
application development.
Peter Claxton
SMART
Efficacy Research into IWB solutions
Khoi Trinh
SMART
Educational research. Large scale deployment of
technology solutions
Michael Boyle
SMART
Architecture and development of education software and
web-based technology
Page 9/214
iTEC Project
17092012.Docx
Neuza Pedro
FPCE
Teacher professional development
Paula Abrantes
FPCE
ICT, Educational Robotics
João Filipe Matos
FPCE
ICT educational integration
José Moura Carvalho
DGIDC
Educational use of ICT, Digital Learning Resources
Nuno Ratão
DGIDC
ICT
Axel Zahlut
ENIS for
BMUKK
Project management, Educational uses of ICT
Eugenijus Kurilovas
ITC
Data models for educational resources, learning design,
and services
Mehmet Muharremoglu
MONE
Pedagogical Coordinator
Ayse Düz
MONE
Semantic Web
Ferdinay Gulez
MONE
Yucel Tuzum
MONE
Teemu Leinonen
AALTO
Concept and interaction design, design methods,
pedagogy, learning science, learning tools, learning
environment
Tarmo Toikkanen
AALTO
Educational psychology, software development,
educational technology
Giusy Cannella
ANSAS
Researching innovative learning environment models
Giovanni Nulli
ANSAS
Researching IT settings in education
Ingrid Maadvere
TLF
Educational technologist (TEL)
Martin Sillaots
TLF
LOM, LOR, IMS CP, IMS DIR
Frank Bach
UNi-C
Learning scenarios, teacher training projects, Learning
materials
Lars Ingesman
UNI-C
Relational data analysis
Ola Berge
NCIE
Technology support for collaborative learning
Kris Popat
UB
David (Dai) Griffiths
UB
Mark Johnson
UB
Frans Van Assche
KULeuven
Learning Technology
Luis Anido Rifon
UVIGO
Semantic Web, LT Standards
Manuel Caeiro
Rodríguez
UVIGO
EML, LT Standards
Rubén Míguez Pérez
UVIGO
Semantic Web, Multimedia Learning Applications
Software Development, Java, C++, HTML, JavaScript,
Education, Creativity, Constructivist.
Learning Design, patterns, pedagogic scenarios,
competence, services, widgets.
Personal Learning Environments (PLE), IMS Learning,
Design, Learning activity design, Realistic Evaluation,
Institutional strategy, Educational ontology, RDF,
XForms / Rest / XQuery(XRX), HTML5, Processing,
Nodejs, NetLogo, Wookie
Page 10/214
iTEC Project
17092012.Docx
Juan M. Santos Gago
UVIGO
Semantic Web, LT Standards, Brokerage Systems
Michael Aram
KM
OpenACS and dotLRN
Bernd Simon
KM
Sue Cranmer
FULAB
Educational Scenarios/pedagogy
Maureen Haldane
MMU
Researching impact of learning technologies on teaching
and learning(particularly Interactive Whiteboards)
Cathy Lewin
MMU
Researching ICT in educational settings
Christian Gertsch
CTIE
Development of educational scenario and description
Karl Wimmer
CTIE
LOM-based application profile
Dov Winer
MAKASH
Psychologist/SW
Frantisek Jakab
ELFA
ICT in education, videoconference, rich media delivery
Miroslav Michalko
ELFA
Electrical Drives, Modelling of Electromechanical
Systems, and System Identification
Zoltan Szalay
ELFA
Implementation of ICT in education
Mônica Macedo-Rouet
CNDP
Evaluation of educational ICT resources (usability,
acceptability); public comm. of science.
Alexandre Lucas
CNDP
Project management, Educational uses of ICT, Distance
learning and collaboration
Attila Főző
EDUC
ICT based pedagogy, curriculum design
Ildikó Csordás
EDUC
Content development, LCMS design
Luk Vanlanduyt
EDUB
Authoring tools and Learning technologies
2.2.1. Documentation preparation
To support the discussion on the initial factors identified by WP10 we prepared a report to be
shared with Control Board members through Google Docs. This report is available at:
https://docs.google.com/document/d/1I430JBvgU5_Mh8EsBZjE-YIquegufSS9mgr5fJDNcX8/edit
The document included an introductory section discussing the issues to be tackled, and proposed
a way for Control Board members to actively contribute to the identification and definition of
recommendation factors. Then, we provided for each type of iTEC resource (i.e., Tools, Events
and People) an enumeration of the factors identified so far, together with a brief description of
each of them, and a statement about how each factor will be used (i.e., how it will contribute)
to compute the relevance of a resource.
Page 11/214
iTEC Project
17092012.Docx
Additionally, a questionnaire was submitted to Control Board members to indicate the
relevance, in a 1 - 102 scale, of each of the proposed factors according to their own
perception. This questionnaire is available at:
http://alen.det.uvigo.es/~jsgago/CB_FACTORS_RELEVANCE.docx
The official kick-off flashmeeting of the third iteration took place on Thursday February 9th 2012, at
11:00 CET. During this meeting, the WP10 leader introduced the SDE objectives related to
resource recommendation and discussed the content of the documents submitted to Control Board
members, together with the proposed contribution scheme. This meeting is available at
http://fm.ea-tel.eu/fm/1c2d4d-28845. The attendants to this meeting were:
•
•
•
•
•
•
•
•
•
•
•
•
•
Luis Anido (UVIGO)
Lars Ingesman (UNI-C)
José Moura Carvalho (DGIDC)
Ildikó Csordás (EDUC)
Maureen Haldane (MMU)
Kris Popat (UB)
Mehmet Muharremoglu (MONE)
Zoltan Szalay ELFA
Michael Boyle (SMART)
Ola Berge (NCIE)
Hoang Minh Tien (FUNDP)
Will Ellis (EUN)
Paula Abrantes (FPCE)
The period for comments and contributions from Control Board members was established from
kick-off meeting’s date to February 24th, 2012. Contributions along this period were included
in the document above. Assessments provided on the identified factors by each Control Board
member may be accessed at:
https://docs.google.com/spreadsheet/ccc?key=0Ak2XcOQtvVz7dGJFYnVkeVBZSWprUTRzWll4bVVyQmc#gid=0
2.2.2. Conclusions from the third iteration
The debate among Control Board members was fairly productive. Around 100 remarks were
included in the document. Note that many of the comments and subsequent responses helped
to analyse the implications of using some factors. Therefore, this debate was instrumental to
establish a weight for these factors.
Although these issues were already tackled in previous Control Board iterations, some
comments from Control Board members addressed issues related to the assignment of
specific values to some resource properties. As an example, several experts pointed out that a
good, continuously evolving vocabulary of tool functionalities is needed. They also indicated
that defining the degree of expertise of an individual in a given field is complex and fairly
2
1 being less relevant and 10 being most relevant.
Page 12/214
iTEC Project
17092012.Docx
subjective. Fortunately, we will not need an accurate definition of this property. For example,
the degree of expertise in a given field claimed by a specific individual may serve as a good
approximation of the actual expertise. However, we will study along the next year whether
some properties can be automatically computed or inferred, at least partially.
We may also point out the requests received to introduce new factors. For tools, it was
proposed to consider tools’ availability, students’ competences (besides lecturers’
competences), accessibility (more specifically, accessibility in special education settings),
number of operating systems or platforms supported, the producer or creator (the tools
created by a well rated individual who already created some tools will receive a higher
ranking), usability, and subject (some tools are more appropriate than others in specific
knowledge areas). In the case of people, it was proposed to consider availability and cost. For
events, it was proposed to take into account event’s language, schedule (in fact, how much it
overlaps with class time), type of activities performed, number of experts participating, age
range of the target audience, and Social Networks Server (people may want to join events with
people participating having a certain profile). These comments would be sent to the Project
Manager for consideration, together with the implications they pose in terms of new
developments and information needed for potential future implementation. We need a
compromise between the number of factors to be considered and the effort involved in
maintaining the necessary information. For example, if we would take into account the
availability of an individual or tool in a school, resources would be needed to keep this
information updated in the system.
Finally, we would like to stress that we got responses to the survey from at least a
representative of each institution represented at the Control Board. This provided a rich and
heterogeneous view to obtain initial weights for the marginal utility functions associated to
each factor (cf. D10.2 Sect.1.2).
2.3. Fourth Iteration
Among the evaluation activities of the ontology developed along the first project year, it was
proposed to validate it according to its coherence with respect to the real world. This task was
organized as an additional iteration of the control boards. More specifically, a control group was
created with experts in several iTEC WPs (cf. Table 2). Due to the specialized nature of the tasks
associated to this process, it was not considered necessary the participation of all Control Board
members.
Table 2. Control board participants for ontology validation
Name
Institution
Main Expertise
Luis Anido Rifon
UVIGO
Semantic Web, LT Standards
José Moura Carvalho
DGIDC
Educational use of ICT, Digital Learning Resources
Page 13/214
iTEC Project
17092012.Docx
Sue Cranmer
FULAB
Educational Scenarios/pedagogy
Neuza Pedro
FPCE-UL
Teacher professional development
Tarmo Toikkanen
AALTO
Educational psychology, software development, educational
technology
Will Ellis
EUN
Application of ICT in learning and teaching
Lars Ingesmann
UNI-C
ICT competencies for teaching, educational technology
Mehmet
Muharremoglu
MONE
Pedagogical Coordinator
Martin Sillaots
TLF
LOM, LOR, IMS CP, IMS DIR
Lars Ingesman
UNI-C
Relational data analysis
Luk Vanlanduyt
EDUB
Authoring tools and Learning technologies
Frans Van Assche
KUL
Learning Technology
David Massart
EUN
Information retrieval, metadata, interoperability, standards
Hoang Minh Tien
FUNDP
Authentication and authorization technologies
David Massart
EUN
Information retrieval, metadata, interoperability, standards
Kris Popat
UB
Widgets, educational technologies
Page 14/214
iTEC Project
17092012.Docx
2.3.1. Documentation preparation
The documentation provided to CB members consisted of a main document and several
supporting documents. The main document described the proposed ontology. This document is
available for download at:
https://docs.google.com/document/d/1tBZmscmksu7itgSLUT1AziX83G5ncqOUNf6JJGlMqg/edit?pli=1
The main document includes a summary of the ontology, based on simplified content and
diagrams. This summary is intended to facilitate the understanding of the ontology. In case CB
members requested detailed information about the ontology, they were offered the document
D10.1 (Anido, Santos, Caeiro, Míguez, Cañas, & Fernández, 2011), which completely describes all
elements and relations in the ontology.
Besides the main document, several documents were provided to support the realization of
structured interviews to gather the opinion of CB members. Five documents were produced for
each of the five information groups included in the ontology: Tools, People, Events, Organizations
and Groups, and LARG. Each of these documents included the questions below:
•
•
•
•
Question 1: Is there any concept or relation missing? Please refer any concept or relation
relevant in the real world according to iTEC aims, but not included in this proposal.
Question 2: Please refer any unnecessary or redundant concept or relation included in the
current proposal.
Question 3: Do you find any inconsistency or incoherence in the concepts and relations of
the current version of this proposal?
Question 4: Do you have any other comment/suggestion?
Due to the specific target of this CB, namely the validation of the ontology, three types of members
were defined according to their role in iTEC:
1. Partners whose work is tightly bound to some aspect of the ontology. These partners have
a clear vision on how these aspects relate to the real world. We ask these partners to
revise the sections below as thoroughly as possible:
• Frans van Assche (K.U. Leuven): People (section 3), Organizations and Groups
(section 4) and Events (section 5)
• Kris Popat (U. Bolton): Tools (section 7)
• Tarmo Toikkanen (AALTO): LARGs (Section 6)
• Bernd Simon (KM) LARGs (Section 6) and Shell modelling within Technical Setting
(Section 7)
2. Partners using, at least partially, most of the concepts discussed in this document. These
partners are requested to revise the sections they feel they are more familiarized with.
• Minh Tien Hoang (FUNDP)
• David Masart (EUN)
• Neuza Pedro (FPCE-UL)
• Lars Ingesman (UNI-C)
3. The rest of the CB members are asked to revise the document and, if desired, to provide
comments on those aspects more familiar or more interesting to them.
Page 15/214
iTEC Project
17092012.Docx
The main document was submitted to all CB members. Supporting documents including the
questions of the structured interview, weere sent to type 1 and 2 CB members. These documents
were delivered on April 21st, 2012. Each CB member was offered a month to submit his/her
contributions. Responses submitted by these CB members are available for download at the
European Schoolnet’s Liferay platform using the links below. Please contact the project
coordinator, Patricia Muñoz King (patricia.munoz.king@eun.org) if you need access to these
documents.
Answers corresponding to the Events section:
EUN
http://itec.eun.org/c/document_library/get_file?p_l_id=11702&folderId=102760&name=DLFE-4925.doc
KUL
UNI-C - http://itec.eun.org/c/document_library/get_file?p_l_id=11702&folderId=102760&name=DLFE-4936.doc
Answers corresponding to the LARG section:
EUN
AALTO - http://itec.eun.org/c/document_library/get_file?p_l_id=11702&folderId=102760&name=DLFE-4940.rtf
Answers corresponding to the Organisations & Groups section:
EUN
KUL - http://itec.eun.org/c/document_library/get_file?p_l_id=11702&folderId=102760&name=DLFE-4931.doc
Answers corresponding to the People section:
EUN
KUL
FUNDP
UNI-C
MONE
UL - http://itec.eun.org/c/document_library/get_file?p_l_id=11702&folderId=102760&name=DLFE-4939.doc
Answers corresponding to the Tools section:
EUN
FUNDP
UB - http://itec.eun.org/c/document_library/get_file?p_l_id=11702&folderId=102760&name=DLFE-4935.doc
Additionally, CB members made comments, questions and suggestions, which were included in
the original document:
https://docs.google.com/document/d/1tBZmscmksu7itgSLUT1AziX83G5ncqOUNf6JJGlMqg/edit?pli=1#heading=h.hc5asqafab7
Every single contribution made by CB members was individually analysed and answered. On-line
contacts were also established to clarify and resolve any doubts.
2.3.2. Conclusions from the fourth iteration
Experts already knew the CB’s work dynamics, so no organizational problems arouse. All experts
submitted their contributions within the established period, and they did not require technical
assistance to respond to the questions. In any case, we have to recognize that some of the
problems identified by experts were due to the lack of detail and the nature of the descriptions
Page 16/214
iTEC Project
17092012.Docx
included in the main document provided to experts. Some of these questions were collected in the
ontology, but they were not described with enough detail in the working document. Somehow,
comments confirm both the quality of the reviews and the quality of the ontology.
Experts confirmed that most of the ontology collects concepts and relations from the real word, so
experts provided a positive evaluation. However, some elements were identified that will not be
needed neither by iTEC nor during SDE development. Anyway, these are very specific issues that
may be better assessed once first tests with final users and real working scenarios take place.
Some of these elements are described below.
2.3.2.1.
Events
Comments suggest that some minor changes should be introduced in event descriptions. Both
starting and ending dates should be considered, and the specification of virtual events should be
clarified. Dates should also include information about the corresponding the time zone. These
aspects were already collected in the ontology, but they were omitted in the working document.
2.3.2.2.
LARGs
The LARGs section was the most controversial, and most questions and comments were related to
the LARG generation process. Relevant issues are related to the actual concept of LARG and its
practical generation process when compared with concepts like Educational Scenario, Learning
Story and Learning Activity. Educational Scenarios were discarded because, as several experts
indicated, it was not relevant insofar the SDE is concerned, and its relation to Learning Stories may
be confusing. Besides, denomination User Selection was replaced by Resource Selection because
the new term corresponds better to the actual meaning of this concept. Requirement specification
was also among the matters tackled. Several experts raised issues about it and about the actual
differences among the different types of requirements. Some concepts like DirectRequirements or
Requirements Specificacions have to be further described for the sake of clarity.
2.3.2.3.
Organisations and Groups
With respect to this section, experts requested the clarification of some concepts and relations.
Specifically, it was questioned if the proposed model can support scenarios having specific groups,
like students participating from other schools. Similarly, experts do not see as relevant the
specification of collaboration among organizations, because its relevance to the project is not clear.
Other group of concepts requiring additional precision are Class, Classroom and StudentGroup.
Besides, several extensions to the proposed model were identified according to the updated
information collected by WP9. Nevertheless, as agreed within the project consortium, given that
there will be no maintenance on the information about organisations, this section of the ontology
was suggested to be removed.
2.3.2.4.
People
Several elements (Trust, Expertise, and the related measurement factors WeightedTrust and
WeightedExpertise) were identified as candidates for removal because they were not considered
as relevant for the use cases to be developed by the SDE. Besides, the data needed for these
elements is hard to obtain. Finally, some experts posed some questions on the use of this data in
relation to the SDE functionalities, or on the actual source of some of these pieces of information.
Page 17/214
iTEC Project
2.3.2.5.
17092012.Docx
Tools
Comments on Tools were targeted to the differences among the several types of tools and the
vocabularies used to describe their properties. For example, questions arouse on the specification
of hardware (i.e., devices) and software (i.e. applications) tools. Experts also stressed the need of
a precise characterization of concepts like widget, iTEC cloud and other relevant iTEC concepts.
Page 18/214
iTEC Project
17092012.Docx
3. Appendix III: FULL SPECIFICATION OF THE SDE API
3.1. Introduction
The iTEC Scenario Development Environment (SDE) is a software application whose main
objectives are (1) to provide support to technical coordinators when addressing the Technical
Localisation in a particular region, and (2) to provide teachers with recommendations on resources
suitable to the learning activities that they wish to implement. The SDE provides its functionality
through the Composer. Communication between SDE and Composer is supported by REST web
services.
This document is intended to serve as a reference guide to the iTEC SDE API. It describes access
models, usage, and results provided by the methods included in the API.
3.1.1. Availability
Services provided are available at:
http://itec.det.uvigo.es/itec-sde/wservices/ws
Besides the information provided in this document, the digital version of this guide includes testing
tools and JSON Schemes3 for requests and responses of each method in the API. The digital
version of this guide is available at:
http://itec.det.uvigo.es/itec-sde/apidoc/index.html
3.1.2. Accessing the API
The SDE complies with the JSON-RPC protocol, and all methods included are stateless. Insofar
invocation is concerned, each method has a unique identifier. This identifier is created from the
method name according to the rules below:
Ͳ
Ͳ
Words start with a capital letter.
Spaces between words are replaced by the symbol ‘.’
For example, according to these criteria, method ‘Get Feasible Learning Stories’ will have
‘Get.Feasible.Learning.Stories’ as its identifier.
Example of API invocation
An example request to 'Get.Feasible.Learning.Stories' is as follows:
3
http://json-schema.org/
Page 19/214
iTEC Project
17092012.Docx
{
"method": "Get.Feasible.Learning.Stories",
"params": [
{
"technical_setting_id": "tsVigo1",
"learning_stories": [
"ls1",
"ls5"
]
}
],
"jsonrpc": "2.0",
"id": "request-001"
}
Figure 1. Example. 'Get Feasible Learning Stories' Request
The response will be:
΂
ΗŝĚΗ͗ΗƌĞƋƵĞƐƚͲϬϬϭΗ͕
ΗũƐŽŶƌƉĐΗ͗ΗϮ͘ϬΗ͕
ΗƌĞƐƵůƚΗ͗΂
ΗůĞĂƌŶŝŶŐͺƐƚŽƌŝĞƐΗ͗΀
΂
ΗůĞĂƌŶŝŶŐͺƐƚŽƌǇͺŝĚΗ͗ΗůƐϭΗ͕
ΗůĞĂƌŶŝŶŐͺƐƚŽƌǇͺĨĞĂƐŝďůĞΗ͗ΗEŽΗ͕
ΗůƐͺĨĞĂƐŝďůĞͺůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϭϬ͕
ΗůƐͺĂĐĐŽŵƉůŝƐŚĞĚͺƌĞƋƵŝƌĞŵĞŶƚƐͺƉĞƌĐĞŶƚĂŐĞΗ͗Ϭ
΃͕
΂
ΗůĞĂƌŶŝŶŐͺƐƚŽƌǇͺŝĚΗ͗ΗůƐϱΗ͕
ΗůƐͺĨĞĂƐŝďůĞͺůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐͺƉĞƌĐĞŶƚĂŐĞΗ͗Ϭ͕
ΗůƐͺĂĐĐŽŵƉůŝƐŚĞĚͺƌĞƋƵŝƌĞŵĞŶƚƐͺƉĞƌĐĞŶƚĂŐĞΗ͗Ϭ
΃
΁
΃
΃
Figure 2. Example. 'Get Feasible Learning Stories' Response
Page 20/214
iTEC Project
17092012.Docx
If anything goes wrong, there will be no "result" object, but an error object in the response
message such as:
΂
ΗĞƌƌŽƌΗ͗΂
ΗĐŽĚĞΗ͗Ϯ͕
ΗŵĞƐƐĂŐĞΗ͗ΗdĞĐŚŶŝĐĂů^ĞƚƚŝŶŐĚŽĞƐŶŽƚĞǆŝƐƚ͘ΖƚƐsŝŐŽϬΖĚŽĞƐŶŽƚĞǆŝƐƚƐŝŶ<ΖΗ
΃
΃
Figure 3. Example. 'Get Feasible Learning Stories' Response Error
3.1.3. References
This section of the deliverable is intended to be self-contained. However, to gain a comprehensive
insight into the iTEC SDE API a thorough knowledge of iTEC data schemas is needed. The
deliverables below are proposed as complementary reading:
•
•
D9.1 – Analysis and Design documents for the directory (Van Assche, 2011)
D10.1 – Support implementing iTEC Engaging Scenarios v1 (Anido, Santos, Caeiro,
Míguez, Cañas, & Fernández, 2011)
3.2. General remarks
This section discusses some general aspects related to the iTEC SDE API and the methods
provided, and more specifically, some relevant elements related to method invocation. Parameters
involved are presented in tabular form according to the criteria below:
Ͳ
Ͳ
A numbered scheme is used to indicate inclusion relations.
Lowercase letter indexes are used to represent disjunctions (i.e., two parameters being
exclusive options).
3.2.1. LARG
A LARG is a collection of Learning Activities and their requirements, together with their realization
context (LARG Context). Due to its relevance, most methods in this API refer to a LARG. As a
consequence, a reference to a LARG is among the invocation parameters of most methods.
According to the underlying semantic model, a LARG specification has the structure in
Table 3.
Page 21/214
iTEC Project
17092012.Docx
Table 3. LARG specification
LARG specification
#
Name
Description
1
Larg
LARG (encapsulation) object
T
JSONObject
1.1
larg_id
LARG identifier
F
ObjectID
1.2
Title
LARG name
T
String
1.3
Description
LARG description
T
String
1.4
Creator
LARG creator
T
JSONArray
[ObjectID]
1.5
learning_story
LARG’s Learning Story. It may be
specified by an identifier (if available)
or by a collection of Learning Activities
T
JSONObject
1.5.1a
learning_story_id
Learning Story identification
F
ObjectID
1.5.1b
learning_activities
Learning Activities included in the
LARG
F
JSONArray
[JSONObject]
1.5.2b.1
learning_activity_id
Learning Activity identifier
T
ObjectID
1.5.1b.2
Requirements
List of requirements for a Learning
Activity
T
JSONArray
[JSONObject]
1.5.1b.2.1
requirement_id
Requirement identifier
T
ObjectID
1.5.1b.2.2
requirement_type
Requirement type (tool, event, person,
learning content)
T
VocabularyTerm
1.5.1b.2.3
a
direct_requirement
Direct specification of a requirement
F
ObjectID
1.5.1b.2.3
b
requirement_specificat
ion
This
element
encapsulates
a
requirement specification of a specific
type
(tool_requirement_spec,
F
JSONObject
Page 22/214
Req.
Data type
(D10.2 Sect.
iTEC Project
17092012.Docx
1.1.1.1)
event_requirement_spec,
learning_content_requirement_spec, or
person_requirement_spec).
1.6
larg_context
Context where the LARG is deployed
T
JSONObject
1.6.1
Audience
Age range of LARG participants.
F
JSONArray
[VocabularyTerm
]
(D9.1, Sect.
4.11)
1.6.2
educationLevel
Educational level of LARG participants
F
JSONArray
[VocabularyTerm
)]
4
(ISCED1997 )
1.6.3
date_range
Date range when the LARG will take
place
T
JSONObject
1.6.3.1
start_date
Starting date
T
Date
1.6.3.2
end_date
Ending date
T
Date
1.6.4
Language
Languages used to deploy the LARG
F
JSONArray
[VocabularyTerm
] (ISO 639-1)
1.6.5
Participants
LARG participants
F
JSONObject
1.6.5.1
participant_id
Participant’s identifier
T
ObjectID
1.6.5.2
participant_role
Participant’s role
T
VocabularyTerm
(D9.1, Sect.
4.13)
1.6.6
technical_setting_id
Technical Setting identifier
T
ObjectID
1.7
Resources
Resources explicitly selected for a
F
JSONArray
4
International
Standard
Classification
of
Education,
http://www.unesco.org/education/information/nfsunesco/doc/isced_1997.htm
Page 23/214
ISCED
1997,
iTEC Project
LARG
17092012.Docx
[JSONObject]
1.7.1
resource_id
(Explicit) resource identifier
T
ObjectID
1.7.2
resource_type
Resource type
T
VocabularyTerm
(D9.1, Sect. 4.8)
1.7.3
resource_satisfied_req
uirement
Requirements to be satisfied by the
selected resource
T
JSONArray
[JSONObject]
1.7.3.1
requirement_id
T
ObjectID
1.7.3.2
requirement_learning_
activities
Learning Activities for which
5
requirement has been defined
F
JSONArray
[ObjectID]
the
3.2.2. Requirement
A requirement collects the properties or features a resource must have. Each resource will have
specific properties or features. As a consequence when specifying a requirement the user must
bear in mind the specific type of resource addressed (i.e., Tool, Person, LearningContent or
Event).
3.2.2.1.
Direct Requirement vs. Requirement Specification
Determining the actual features required for a Learning Activity may be a complex task. As a
consequence the iTEC SDE supports the use of a specific resource as a requirement. Thus, we
can identify two types of requirements, namely Direct requirements and Requirement
Specifications.
-
A Direct Requirement signals explicitly the need of a specific resource referenced using the
corresponding unique identifier.
A Requirement Specification collects the most relevant features of the desired resource,
according to its type (Tool, People, Event, Learning Content).
We discuss below the characteristics of each type of requirement. Similarly to the LARG
specification above, please refer to JSONSchema6 to obtain information about the actual structure
of each of these parameters.
5
This approach supports both requirements having a unique identifier and requirements with an identifier
related to the Learning Activity where the requirement appears.
6
This schema is included in the Web guide: http://itec.det.uvigo.es/itec-sde/apidoc/index.html
Page 24/214
iTEC Project
3.2.2.2.
17092012.Docx
Tool requirement
Table 4. ToolRequirement specification
ToolRequirement specification
#
Name
Description
Req.
1
tool_requirement
Requirement of a Resource of type Tool
1.1a
direct_tool_requirement
Direct selection of a Resource
Requirement
(this
enables
recommendation of similar tools)
1.1b
tool_requirement_spec
1.1b.1
Data type
T
JSONObject
F
ObjectID
Specification of a Requirement of type Tool
F
JSONObject
Functionality
Functionality required for the Resource.
F
JSONArray
[JSONObject]
1.1b.1.1
functionality_id
Functionality identifier
T
VocabularyTerm
(D9.1, Sect. 4.2)
1.1b.1.2
functionality_level
Lower functionality level required
F
Number
I1.1b.2
has_cost
Indication about Tool’s usage costs
F
Boolean
I1.1b.3
conforms_to
Standars to which the Tool must comply
F
JSONArray
[ObjectID]
I1.1b.4
Audience
Tool users’ age range
F
JSONArray
[VocabularyTerm]
(D9.1, Sect. 4.11)
I1.1b.5
education_level
Educational level for which the Tool has been
designed
F
JSONArray
[VocabularyTerm]
(ISCED1997)
I1.1b.6
Language
Language to be supported by the user
interface
F
JSONArray
[VocabularyTerm]
(ISO 639-1)
I1.1b.7
License
Applicable usage license
F
URI
Page 25/214
as
a
the
iTEC Project
17092012.Docx
I1.1b.8
Rating
Lowest rating required for the Tool
F
Number
I1.1b.9
supported_formats
Supported formats (MIME types)
F
JSONArray
[String]
(MIME types)
I1.1b.10
Type
Tool type
F
VocabularyTerm
(D9.1, Sect. 4.8 –
device, shell,
productivity tool)
I1.1b.11
Keyword
Keyword to facilitate the identification of the
requirement
F
String
3.2.2.3.
Person requirement
Table 5. PersonRequirement specification
PersonRequirement specification
#
Name
Description
1
person_requirement
Requirement of a Resource of type
Person
T
JSONObject
1.1a
direct_person_requireme
nt
Direct selection of a Resource as a
Requirement
F
ObjectID
1.1b
person_requirement_spe
c
Specification of a Requirement of type
Person
F
JSONObject
1.1b.1
Expertise
Knowledge Domain or scientific field a
Person must know/master
F
JSONArray
[JSONObject]
1.1b.1.1
expertise_id
Knowledge domain identifier
T
VocabularyTer
m (D9.1, Sect.
4.9)
1. 1b.1.2
expertise_level
Lowest level of expertise
F
Number
1. 1b.2
based_near
Location of Person
F
JSONObject
Page 26/214
Req.
Data type
iTEC Project
17092012.Docx
1. 1b.2.1
address
Actual Person’s address
F
String
1. 1b.2.2
latitude
Geographical latitude
F
Number
1. 1b.2.3
longitude
Geographical longitude
F
Number
1. 1b.3
comm_channels
Communication channels available to
contact this Person
F
JSONArray
[ObjectID]
1. 1b.4
lang_competence
Language in which this Person must
be fluent
F
JSONArray
[VocabularyTer
m] (ISO 639-1)
1. 1b.5
rating
Lowest rating for this Person
(according to community ratings)
F
Number
1. 1b.6
type
Type of Person
F
JSONArray
[VocabularyTer
m] (D9.1, Sect.
4.13)
1. 1b.7
keyword
Keyword to facilitate the identification
of the requirement
F
String
3.2.2.4.
Event requirement
Table 6. EventRequirement specification
EventRequirement specification
#
Name
Description
Req.
1
event_requirement
Requirement of a Resource of type Event
T
JSONObject
1.1a
direct_event_requirement
Direct selection of a Resource as a
Requirement
F
ObjectID
1.1b
event_requirement_spec
Specification of a Requirement of type
Event
F
JSONObject
1.1b.1
subject
Event’s topic
F
JSONArray
[ObjectID]
1.1b.2
based_near
Event’s venue
F
JSONObject
Page 27/214
Data type
iTEC Project
17092012.Docx
1.1b.2.1
address
Actual event’s address
F
String
1.1b.2.2
latitude
Geographical latitude
F
Number
1.1b.2.3
longitude
Geographical longitude
F
Number
1.1b.3
has_cost
Whether the Event has a fee
F
Boolean
I1.1b.4
audience
Target age range of the event
F
JSONArray
[VocabularyTerm]
(D9.1, Sect. 4.11)
I1.1b.5
education_level
Educational level of the Event
F
JSONArray
[VocabularyTerm]
(ISCED1997)
1.1b.5
language
Language of the Event
F
JSONArray
[VocabularyTerm]
(ISO 639-1)
1.1b.6
rating
Lowest rating for this Event (according to
community ratings)
F
Number
1.1b.7
type
Type of Event
F
JSONArray
[VocabularyTerm]
(D9.1, Sect. 4.7)
1.1b.8
keyword
Keyword to facilitate the identification of
the requirement
F
String
1.1b.9
date_range
Dates when the Event should take place
F
JSONObject
1.1b.9.1
start_date
Starting date of the valid date range
F
Date
1.1b.9.2
end_date
Final date of the valid date range
F
Date
3.2.2.5.
Learning Content requirement
Table 7. LearningContentRequirement specification
LearningContentRequirement specification
#
1
Name
Description
learning_content_
Requirement of a Resource of
Page 28/214
Req.
T
Data type
JSONObject
iTEC Project
requirement
17092012.Docx
type Learning Content
1.1a
direct_learning_content_requirement
Direct selection of a Resource
as a Requirement
F
ObjectID
1.1b
learning_content_requirement_spec
Specification of a Requirement
of type Learning Content
F
JSONObject
1.1b.1
audience
Learning Content’s age range
F
JSONArray
[VocabularyTerm]
(D9.1, Sect. 4.11)
1.1b.2
education_level
Learning Content’s educational
level
F
JSONArray
[VocabularyTerm]
(ISCED1997)
1.1b.3
content_format
Desired Content format
F
JSONArray
[String]
(MIME types)
1.1b.4
language
Desired Content language
F
JSONArray
[VocabularyTerm]
(ISO 639-1)
1.1b.5
license
Applicable license
F
URI
1.1b.6
rating
Lowest rating
F
Number
1.1b.7
subject
Knowledge field of the Learning
Content
F
JSONArray
[VocabularyTerm]
(D9.1, Sect. 4.9)
1.1b.8
keyword
Keyword
to
facilitate
the
identification of the requirement
F
String
3.2.3. Learning Activities and Learning Stories - Feasibility
Ͳ
Ͳ
Ͳ
A Learning Story may have one or several Learning Activities.
A Learning Activity may have different Technical Requirements.
A Technical Requirement establishes the functionalities to be supported by a Tool at a
given level or extent. Only Requirements declaring such required functionalities can be
considered Technical Requirements. In other words, Requirements not including functional
characteristics of a Tool cannot be considered Technical Requirements.
Example
Ͳ
Learning Story “Reacting to student feedback” is composed of:
Page 29/214
iTEC Project
o
o
17092012.Docx
Learning Activity “Video documentation of work progress” having as Technical
Requirements:
Technical Requirement “Capture” with:
• Functionality “Video Capture” - Level “9.5”
• Functionality “Video Editing”
Technical Requirement “Share” with:
• Functionality “Video Share” – Level “6”
Learning Activity “Mental notes about students” with no Technical Requirements
To overcome the limitations of a binary evaluation of feasibility when implementing scenarios
(Feasible / Not feasible), a “partial” result for the feasibility evaluation is also taken into account.
This indicates the feasibility of part of the Learning Activities included in a Learning Story (Learning
Story feasibility) or the fulfillment of some of the requirements of a Learning Activity (Learning
Activity feasibility). This partial result is to be interpreted as follows:
7
-
A Learning Story is:
o Completely Feasible in a given Technical Setting if all its Learning Activities are
completely feasible (100%)
o Partially feasible if a given percentage of the Learning Activities are completely or
partially feasible (range u1%-u2%7)
o Not feasible if a given percentage of the Learning Activities are not feasible (range
0-u1%)
-
A Learning Activity is:
o Completely Feasible in a given Technical Setting if all its Technical Requirements
can be satisfied.
o Partially feasible if a given percentage of the Technical Requirements can be
satisfied (range u1%-u2%)
o Not feasible if the number of Technical Requirements that can be satisfied is low
(range 0-u1%)
-
A Technical Requirement is:
o Satisfied in a Technical Setting if the requirement includes one or more tools
satisfying all Technical Requirements with a mark greater or equal to the one
specified. If this mark is not included in the requirement definition, the SDE will use
a predefined threshold8
o Not satisfied if there are no tools available satisfying the requirement
These are configurable thresholds. Initially predefined values are 60% resp. 99%
8
Configurable parameter. This parameter can be further tuned by the user through input parameter
minimum_level in method Assess Technical Feasibility.
Page 30/214
iTEC Project
17092012.Docx
Figure 4. Learning Stories, Activities, Requirements and Functionalities
Example
-
Technical Setting composed of:
o Tool “YouTube”
Functionality “Video Share” - Level “10”
o Tool “SmartPhone”
Functionality “Video Capture” – Level “7”
Functionality “Video Editing” – Level “6”
Functionality “Video Share” – Level “7”
o Tool “Webcam”
Functionality “Video Capture” – Level “10”
Figure 5. Example of the functionalities offered by tools in a given Technical Setting
Taking as a reference this example and the Technical Setting above:
Page 31/214
iTEC Project
-
-
17092012.Docx
Technical Requirement “Capture” – Not satisfied – There is a Tool (“SmartPhone”)
providing two of the required features, but one of them does not reach the specified
threshold. Tool “Webcam” marks above the defined threshold for “Video Capture”, but it
does not have the two required functionalities.
Technical Requirement “Share” – Satisfied – There are two tools providing “Video Share”
functionality above the required level.
The feasibility analysis of this Learning Story has the result below:
-
Learning Activity “Video documentation of work progress” – 1/2 satisfied requirements
(50%) -> Not feasible
Learning Activity “Mental notes about students” – No Technical Requirements
(100%) -> feasible
Learning Story “Reacting to student feedback” – 1/2 feasible Learning Activities
(50%) -> Not feasible
We can also obtain the percentage of satisfied Technical Requirements for a Learning Story. This
could be useful to assess the results obtained, specifically when many Learning Activities include
not satisfied requirements, or when Learning Activities have few Technical Requirements. In this
latter case, the impact of each requirement would be higher.
Figure 6. Requirement satisfaction analysis for a Webcam
Figure 7. Requirement satisfaction analysis for a Smartphone
Page 32/214
iTEC Project
17092012.Docx
3.3. Methods
Methods provided by the iTEC SDE API can be classified into three groups according to their
functionality. The first group includes methods to be used exclusively by SDE administrators, while
the two latter groups, namely Technical Localisation (TL) and Resource Planning (RP), provide
methods for the iTEC Composer to support the interaction of coordinators and teachers. Due to
their relevance for final users, this document will focus on the two latter groups. We discuss below
the methods in each group according to the structure below:
Ͳ
Ͳ
Ͳ
Ͳ
Ͳ
Method description
Input parameters
Result
Errors
Output examples
Besides this, the Web guide9 also includes:
Ͳ
Ͳ
Ͳ
Ͳ
Additional information about each method, its input parameters and errors.
Usage examples
JSON Schema for requests and responses
Test console
Figure 8. Requirement satisfaction analysis for YouTube
3.3.1. Technical Localisation
This section includes methods related to Technical Localisation. These methods capture the
functionality to assess the technical feasibility of Learning Stories in Technical Settings. This group
is of special interest for a person who wants to check which Learning Stories from those defined by
iTEC or other sources could be eventually implemented in a particular set of schools under her
responsibility. Thus, the process of selecting Learning Stories to be further developed into eventual
LARGs is facilitated through (semi)automatic selection mechanism.
9
Available at http://itec.det.uvigo.es/itec-sde/apidoc/index.html
Page 33/214
iTEC Project
3.3.1.1.
17092012.Docx
Assess Technical Feasibility
The system checks if a Learning Story can be implemented in a given Technical Setting. For this, it
checks the Technical Requirements’ specification of the Learning Activities in the Learning Story,
together with the functionalities provided by the Tools in the Technical Setting.
Input parameters
Table 8. 'Assess Technical Feasibility' parameters
assessTechnicalFeasibility – Input
#
Name
Description
Req.
Data type
Learning Story identifier
T
ObjectID
ůĞĂƌŶŝŶŐͺƐƚŽƌǇͺŝĚ
I1
I2
T
ObjectID
I3
minimum_level
Lowest support level for the functionalities in
each Technical Requirement (range: 0 - 10). If
this value is present, it will override the one
defined for the requirement. This way, support is
provided to relax/strength feasibility assessment.
F
Number
Result
The method returns a complete feasibility analysis for the Learning Store and each of its Learning
Activities. More specifically:
-
-
The feasibility of the Learning Story (yes, partially, no), the percentage of totally or partially
feasible Learning Activities, the percentage of satisfied requirements10 and a list of their
Learning Activities.
The feasibility of each Learning Activity (yes, partially, no), the percentage of satisfied
requirements and a list of their Technical Requirements.
For each Technical Requirement, whether it is satisfied or not, and a list of Tools in the
Technical Setting that satisfy it.
For each Tool, the degree of support11 of the functionalities included in the Technical
Requirement.
10
The requirements of a Learning Story are the ones of its Learning Activities. If a requirement is replicated
in several Learning Activities, it will be considered only once to compute the percentage of satisfied
requirements.
11
If a Technical Requirement has more than one functionality, the level of the tools satisfying it is computed
as the average of the values of the corresponding tool w.r.t. each of the functionalities. This average value is
Page 34/214
iTEC Project
17092012.Docx
Table 9. 'Assess Technical Feasibility' output
assessTechnicalFeasibility – Output
#
Name
Description
Req.
Data type
O1
learning_story_feasible
Indicates if the Learning Story is
feasible, partially feasible, or not
feasible
T
String
[Yes,No,Partiall
y]
O2
ls_feasible_learning_activiti
es_percentage
Percentage of feasible Learning
Activities, either totally or partially
T
Number
O3
ls_satisfied_requirements_
percentage
Percentage
of
satisfied
Requirements in the Learning Story
T
Number
O4
learning_activities
List of Learning Activities including
their feasibility analysis
T
JSONArray
[JSONObject]
O4.1
T
String
O4.2
learning_activity_feasible
Indicates if the Learning Activity is
feasible, partially feasible, or not
feasible
T
String
[Yes,No,Partiall
y]
O4.3
la_
satisfied_requirements_per
centage
Percentage
Requirements
Activity
satisfied
Learning
T
Number
requirements
List of the Requirements of the
Learning Activity
F
JSONArray
O4.4
of
in
the
[JSONObject]
O4.4.1
requirement_id
T
String
O4.4.2
requirement_satisfied
“Yes” if the requirement can be
satisfied with the resources in the
Technical Setting. “No” otherwise.
T
Boolean
O4.4.3
tools
List of tools included in the Technical
Setting that may be used in the
T
JSONArray
used only to provide this output value (i.e., it will not be used to decide if a Tool satisfies a Technical
Requirement).
Page 35/214
iTEC Project
Learning Activity
17092012.Docx
[JSONObject]
O4.4.3.1
tool_id
Tool identifier
T
String
O4.4.3.2
level
Requirement’s level of fulfilment
T
Number
Errors
Table 10. 'Assess Technical Feasibility' errors
assessTechnicalFeasibility – Errors
#
ϭ
Ϯ
ϯϯ
Message
Description
>ĞĂƌŶŝŶŐ^ƚŽƌǇĚŽĞƐŶŽƚĞǆŝƐƚ
dŚĞƌĞŝƐŶŽ>ĞĂƌŶŝŶŐ^ƚŽƌǇŝŶƚŚĞ<ǁŝƚŚƚŚĞŝĚĞŶƚŝĨŝĞƌƐƉĞĐŝĨŝĞĚ
dĞĐŚŶŝĐĂů^ĞƚƚŝŶŐĚŽĞƐŶŽƚ
ĞǆŝƐƚ
/ŶǀĂůŝĚŶƵŵďĞƌ
dŚĞƌĞŝƐŶŽdĞĐŚŶŝĐĂů^ĞƚƚŝŶŐŝŶƚŚĞ<ǁŝƚŚƚŚĞŝĚĞŶƚŝĨŝĞƌƐƉĞĐŝĨŝĞĚ
EƵŵďĞƌŽƵƚŽĨƌĂŶŐĞŽƌǁŝƚŚĂŶŝŶĐŽƌƌĞĐƚĨŽƌŵĂƚ
Output example
Table 11. 'Assess Technical Feasibility' example response
΂
ΗůĞĂƌŶŝŶŐͺƐƚŽƌǇͺĨĞĂƐŝďůĞΗ͗ΗWĂƌƚŝĂůůǇΗ͕
ΗůƐͺĨĞĂƐŝďůĞͺůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϲϲ͘ϲϳ͕
ΗůƐͺƐĂƚŝƐĨŝĞĚͺƌĞƋƵŝƌĞŵĞŶƚƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϴϬ͕
ΗůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐΗ͗΀
΂
ΗůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚǇͺŝĚΗ͗ΗůĂϵΗ͕
ΗůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚǇͺĨĞĂƐŝďůĞΗ͗ΗWĂƌƚŝĂůůǇΗ͕
ΗůĂͺƐĂƚŝƐĨŝĞĚͺƌĞƋƵŝƌĞŵĞŶƚƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϲϲ͘ϲϳ͕
ΗƌĞƋƵŝƌĞŵĞŶƚƐΗ͗΀
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺŝĚΗ͗ΗƌĞƋϮϰΗ͕
ΗƌĞƋƵŝƌĞŵĞŶƚͺƐĂƚŝƐĨŝĞĚΗ͗ΗzĞƐΗ͕
ΗƚŽŽůƐΗ͗΀
΂
ΗƚŽŽůͺŝĚΗ͗Η^ŵĂƌƚWŚŽŶĞΗ͕
ΗůĞǀĞůΗ͗ϭϬ
΃
΁
΃͕
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺŝĚΗ͗ΗƌĞƋϮĂΗ͕
Page 36/214
iTEC Project
ΗƌĞƋƵŝƌĞŵĞŶƚͺƐĂƚŝƐĨŝĞĚΗ͗ΗEŽΗ͕
ΗƚŽŽůƐΗ͗΀΁
΃͕
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺŝĚΗ͗ΗƌĞƋϭϳΗ͕
ΗƚŽŽůƐΗ͗΀
΂
ΗƚŽŽůͺŝĚΗ͗ΗDŽďŝůĞWŚŽŶĞΗ͕
΃
΁
΃
΁
΃͕
΂
ΗůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚǇͺŝĚΗ͗ΗůĂϴΗ͕
ΗůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚǇͺĨĞĂƐŝďůĞΗ͗ΗzĞƐΗ͕
ΗůĂͺƐĂƚŝƐĨŝĞĚͺƌĞƋƵŝƌĞŵĞŶƚƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϭϬϬ͕
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺŝĚΗ͗ΗƌĞƋϮϮΗ͕
ΗƚŽŽůƐΗ͗΀
΂
ΗƚŽŽůͺŝĚΗ͗ΗdĞĂŵhƉΗ͕
΃
΁
΃
΁
΃͕
΂
ΗůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚǇͺŝĚΗ͗ΗůĂϳΗ͕
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺŝĚΗ͗ΗƌĞƋϮϭΗ͕
ΗƚŽŽůƐΗ͗΀
΂
ΗƚŽŽůͺŝĚΗ͗ΗzŽƵdƵďĞΗ͕
΃
΁
΃
΁
΃
΁
΃
΃
Page 37/214
17092012.Docx
iTEC Project
3.3.1.2.
17092012.Docx
Get Feasible Learning Stories
The system checks which Learning Stories can be implemented with a specific Technical Setting.
Input parameters
Table 12. 'Get Feasible Learning Stories' parameters
getFeasibleLearningStories – Input
#
Name
Description
Req.
Data type
I1
T
ObjectID
I2
learning_stories
List including the identifiers of all Learning Stories
to be checked. If this parameter is missing, all
Learning Stories in the system will be checked.
F
JSONArray
[ObjectID]
Result
The system returns a simplified feasibility analysis for each of the Stories. More specifically:
-
The feasibility of each Learning Story (yes, partially, no), the percentage of partially or
totally feasible Learning Activities, and the percentage of requirements satisfied12.
Table 13. 'Get Feasible Learning Stories' output
getFeasibleLearningStories – Output
#
O1
Name
Description
Req.
learning_stories
Set of Learning Stories passed to the
method
T
Data type
JSONArray
[JSONObject]
O1.1
learning_story_id
T
ObjectID
O1.2
learning_story_feasible
Learning Story feasibility result
T
String
[Yes, No,
Partially]
12
The requirements of a Learning Story are the ones of its Learning Activities. If a requirement is replicated
in several Learning Activities, it will be considered only once to compute the percentage of satisfied
requirements.
Page 38/214
iTEC Project
17092012.Docx
O1.3
ls_feasible_learning_acti
vities_percentage
Percentage of partially or totally feasible
Learning Activities
T
Number
O1.4
ls_satisifed_requirements
_percentage
Percentage of Requirements fulfilled
T
Number
Errors
Table 14. 'Get Feasible Learning Stories' errors
getFeasibleLearningStories – Errors
#
ϭ
Ϯ
Message
Description
ĞǆŝƐƚ
Output example
Table 15. 'Get Feasible Learning Stories' example response
΂
ΗůĞĂƌŶŝŶŐͺƐƚŽƌŝĞƐΗ͗΀
΂
ΗůĞĂƌŶŝŶŐͺƐƚŽƌǇͺŝĚΗ͗ΗůƐϱΗ͕
ΗůĞĂƌŶŝŶŐͺƐƚŽƌǇͺĨĞĂƐŝďůĞΗ͗ΗWĂƌƚŝĂůůǇΗ͕
ΗůƐͺĨĞĂƐŝďůĞͺůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϲϲ͘ϲϳ͕
ΗůƐͺƐĂƚŝƐĨŝĞĚͺƌĞƋƵŝƌĞŵĞŶƚƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϴϬ
΃͕
΂
ΗůƐͺĨĞĂƐŝďůĞͺůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϰϬ͕
ΗůƐͺƐĂƚŝƐĨŝĞĚͺƌĞƋƵŝƌĞŵĞŶƚƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϲϰ͘ϳϭ
΃
΁
΃
΃
3.3.1.3.
Get Suitable Technical Settings
The system checks the feasibility of a Learning Story according to a list of Technical Settings.
Page 39/214
iTEC Project
17092012.Docx
Input parameters
Table 16. 'Get Suitable Technical Settings' parameters
getSuitableTechnicalSettings – Input
#
Name
Description
Req.
Data type
I1
learning_story_id
T
ObjectID
I2
technical_settings
List including the identifiers of the Technical
Settings to be checked
T
JSONArray
[ObjectID]
Result
The system returns a simplified feasibility analysis for the Learning Story according to the
Technical Settings provided. More specifically:
-
The feasibility analysis of the Learning Story for each of the Technical Settings provided
(yes, partially, no), percentage of totally or partially feasible Learning Activities, and
percentage of satisfied Requirements.
Table 17. 'Get Suitable Technical Settings' output
getSuitableTechnicalSettings – Output
#
O1
Name
Description
technical_settings
Set of Technical Settings where the
Learning Story can be deployed
Req.
T
Data type
JSONArray
[JSONObject]
O1.1
T
ObjectID
O1.2
ts_ls_feasible_learning_activ
ities_percentage
Percentage of totally or partially
feasible Learning Activities using this
Technical Setting
T
Number
O1.3
ts_ls_satisfied_requirements
_percentage
Percentage of satisfied Requirements
T
Number
Page 40/214
iTEC Project
17092012.Docx
Errors
Table 18. 'Get Suitable Technical Settings' errors
getSuitableTechnicalSettings – Errors
#
ϭ
Ϯ
Message
Description
ĞǆŝƐƚ
Output example
Table 19. 'Get Suitable Technical Settings' example response
΂
ΗƚĞĐŚŶŝĐĂůͺƐĞƚƚŝŶŐƐΗ͗΀
΂
ΗƚĞĐŚŶŝĐĂůͺƐĞƚƚŝŶŐͺŝĚΗ͗ΗƚƐsŝŐŽϭΗ͕
ΗƚƐͺůƐͺĨĞĂƐŝďůĞͺůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϰϬ͕
ΗƚƐͺůƐͺƐĂƚŝƐĨŝĞĚͺƌĞƋƵŝƌĞŵĞŶƚƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϲϰ͘ϳϭ
΃
΁
΃
΃
3.3.2. Resource Planning
This block collects methods providing recommendations on the best resources satisfying the set of
Requirements in Learning Activities configuring a Learning Story in the LARG Context where
activities will be developed. The final objective is to facilitate resource selection to teachers using
the Composer (Tools, People, Events and Learning Content).
This block is further organized into method groups, according to their functionality:
-
-
-
Recommendation
Methods offering recommendations on resources according to the requirements included in
a set of Learning Activities to be developed in a specific LARG Context.
Search
Methods to support the location of resources satisfying a given requirement, even those
that they are not satisfied in a given Technical Setting. They enable the retrieval of any
resource available in the iTEC Semantic Database.
Analyse
To check if a LARG is valid according to the specified requirements. These methods
analyse a LARG to detect problems.
Page 41/214
iTEC Project
3.3.2.1.
17092012.Docx
Create LARG
Automatically selects the best Resources to implement a LARG.
Input parameters
Table 20. 'Create LARG' parameters
createLARG – Input
#
I1
Name
Description
larg
LARG
specification
implemented
Req.
to
be
T
Data type
JSONObject
(Sect. 3.2.1)
Result
The method returns the LARG implementation including the selection of Resources needed to
satisfy all the Requirements in each Learning Activity. If the LARG is not implementable, a list
including the Resources not satisfied is returned. More specifically, this method returns (if the
LARG is not implementable):
-
The list of Learning Activities
For each Learning Activity, the method returns its feasibility status (yes, partially, no), the
percentage of satisfied requirements, and the associated list of requirements
For each Requirement, whether it is satisfied or not, and when do not, the reasons why the
requirement is not satisfied
Table 21. 'Create LARG' output
createLARG – Output
#
O1a
Name
Description
larg
LARG
specification
implemented
Req.
to
be
T
Data type
JSONObject
(Sect. 3.2.1)
O1b
learning_activities
List
of
Learning
Activities
(including their feasibility analysis)
T
JSONArray
[JSONObject]
O1b.1
T
ObjectID
O1b.2
Indication of the feasibility of the
Learning
Activity
(yes,
no,
T
String
[Yes,No,Partially]
Page 42/214
iTEC Project
17092012.Docx
partially)
O1b.3
la_
satisfied
_requirements_percentage
Percentage
Requirements
Activity
O1b.4
requirements
List of Requirements
Learning Activity
of
in the
satisfied
Learning
of
the
T
Number
T
JSONArray
[JSONObject]
O1b.4.1
requirement_id
T
String
O1b.4.2
Satisfied
“Yes” if the Requirement can be
satisfied
with
the
selected
Resources. “No” otherwise.
T
Boolean
Reasons
Reasons why the requirement is
not satisfied
F
JSONArray
[JSONObject]
O1b.4.3.1
reason_code
Reason code
T
Number
O1b.4.3.2
reason_message
Descriptive message
F
String
O1b.4.3
Errors
Table 22. 'Create LARG' errors
createLARG – Errors
#
ϭ
Ϯ
ϯ
ϰ
ϱ
ϲ
ϳ
ϯϭ
Message
Description
ĞǆŝƐƚ
>ĞĂƌŶŝŶŐĐƚŝǀŝƚǇĚŽĞƐŶŽƚ
ĞǆŝƐƚ
dŚĞƌĞŝƐŶŽ>ĞĂƌŶŝŶŐĐƚŝǀŝƚǇŝŶƚŚĞ<ǁŝƚŚƚŚĞŝĚĞŶƚŝĨŝĞƌƐƉĞĐŝĨŝĞĚ
WĞƌƐŽŶĚŽĞƐŶŽƚĞǆŝƐƚ
dŚĞƌĞŝƐŶŽWĞƌƐŽŶŝŶƚŚĞ<ǁŝƚŚƚŚĞŝĚĞŶƚŝĨŝĞƌƐƉĞĐŝĨŝĞĚ
>Z'ĚŽĞƐŶŽƚĞǆŝƐƚ
ZĞƐŽƵƌĐĞĚŽĞƐŶŽƚĞǆŝƐƚ
ZĞƋƵŝƌĞŵĞŶƚĚŽĞƐŶŽƚĞǆŝƐƚ
/ŶǀĂůŝĚůĂŶŐƵĂŐĞ
dŚĞƌĞŝƐŶŽ>Z'ŝŶƚŚĞ<ǁŝƚŚƚŚĞŝĚĞŶƚŝĨŝĞƌƐƉĞĐŝĨŝĞĚ
dŚĞƌĞŝƐŶŽZĞƐŽƵƌĐĞŝŶƚŚĞ<ǁŝƚŚƚŚĞŝĚĞŶƚŝĨŝĞƌƐƉĞĐŝĨŝĞĚ
dŚĞƌĞŝƐŶŽZĞƋƵŝƌĞŵĞŶƚŝŶƚŚĞ<ǁŝƚŚƚŚĞŝĚĞŶƚŝĨŝĞƌƐƉĞĐŝĨŝĞĚ
dŚĞůĂŶŐƵĂŐĞĚŽĞƐŶŽƚŚĂǀĞĂĐŽƌƌĞĐƚĨŽƌŵĂƚ;/^KϲϯϵͲϭͿŽƌŶŽƚ
ƌĞŐŝƐƚĞƌĞĚ
ϯϮ
/ŶǀĂůŝĚĚĂƚĞ
ϰϭ
/ŶǀĂůŝĚǀŽĐĂďƵůĂƌǇƚĞƌŵ
dŚĞƚĞƌŵĚŽĞƐŶŽƚďĞůŽŶŐƚŽĂŶǇǀŽĐĂďƵůĂƌǇ
/ŶǀĂůŝĚĞǀĞŶƚƚǇƉĞ
dŚĞĞǀĞŶƚƚǇƉĞĚŽĞƐŶŽƚĞǆŝƐƚ
ϯϯ
ϰϮ
ϰϯ
/ŶǀĂůŝĚƌĞƐŽƵƌĐĞƚǇƉĞ
dŚĞĚĂƚĞĚŽĞƐŶŽƚŚĂǀĞĂƐƵƉƉŽƌƚĞĚĨŽƌŵĂƚ;ǇǇǇǇͲDDͲĚĚͿ
dŚĞƌĞƐŽƵƌĐĞĚŽĞƐŶŽƚŚĂǀĞƚŚĞƚǇƉĞŝŶĚŝĐĂƚĞĚ
Page 43/214
iTEC Project
17092012.Docx
ϰϰ
/ŶǀĂůŝĚƚŽŽůƚǇƉĞ
dŚĞƚŽŽůƚǇƉĞĚŽĞƐŶŽƚĞǆŝƐƚ
ϰϲ
/ŶǀĂůŝĚĐŽŵŵƵŶŝĐĂƚŝŽŶ
ĐŚĂŶŶĞů
dŚĞƌĞƐŽƵƌĐĞŝƐŶŽƚĂǀĂůŝĚĐŽŵŵƵŶŝĐĂƚŝŽŶĐŚĂŶŶĞů
ϰϱ
/ŶǀĂůŝĚƉĞƌƐŽŶƚǇƉĞ
dŚĞƉĞƌƐŽŶƚǇƉĞĚŽĞƐŶŽƚĞǆŝƐƚ
Output example
Table 23. 'Create LARG' example response
΂
ΗƚŝƚůĞΗ͗ΗdĞƐƚ>Z'Η͕
ΗĚĞƐĐƌŝƉƚŝŽŶΗ͗Η>Z'ĨŽƌŵĞƚŚŽĚĞǆĂŵƉůĞΗ͕
ΗĐƌĞĂƚŽƌΗ͗΀΁͕
ΗůĞĂƌŶŝŶŐͺƐƚŽƌǇΗ͗΂
΂
ΗůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚǇͺŝĚΗ͗ΗůĂϭΗ͕
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺŝĚΗ͗ΗƌĞƋƵŝƌĞWϭΗ͕
ΗƌĞƋƵŝƌĞŵĞŶƚͺƚǇƉĞΗ͗ΗWĞƌƐŽŶΗ͕
ΗƌĞƋƵŝƌĞŵĞŶƚͺƐƉĞĐŝĨŝĐĂƚŝŽŶΗ͗΂
ΗƉĞƌƐŽŶͺƌĞƋƵŝƌĞŵĞŶƚͺƐƉĞĐΗ͗΂
ΗĞǆƉĞƌƚŝƐĞΗ͗΀
΂
ΗĞǆƉĞƌƚŝƐĞͺŝĚΗ͗ΗdŚĞƌƚƐΗ͕
ΗĞǆƉĞƌƚŝƐĞͺůĞǀĞůΗ͗ϳ
΃
΁
΃
΃
΃͕
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺŝĚΗ͗ΗƌĞƋƵŝƌĞϭΗ͕
ΗƌĞƋƵŝƌĞŵĞŶƚͺƚǇƉĞΗ͗ΗǀĞŶƚΗ͕
ΗĞǀĞŶƚͺƌĞƋƵŝƌĞŵĞŶƚͺƐƉĞĐΗ͗΂
ΗƐƵďũĞĐƚΗ͗΀
ΗdŚĞƌƚƐΗ
΁
΃
΃
΃
΁
΃͕
΂
ΗůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚǇͺŝĚΗ͗ΗůĂϯΗ͕
΂
Page 44/214
iTEC Project
17092012.Docx
ΗƌĞƋƵŝƌĞŵĞŶƚͺŝĚΗ͗ΗƌĞƋƵŝƌĞdϭΗ͕
ΗƌĞƋƵŝƌĞŵĞŶƚͺƚǇƉĞΗ͗ΗdŽŽůΗ͕
ΗƚŽŽůͺƌĞƋƵŝƌĞŵĞŶƚͺƐƉĞĐΗ͗΂
ΗĨƵŶĐƚŝŽŶĂůŝƚǇΗ͗΀
΂
ΗĨƵŶĐƚŝŽŶĂůŝƚǇͺŝĚΗ͗ΗĂĨĨĨŝůĞƐŚĂƌĞΗ͕
ΗĨƵŶĐƚŝŽŶĂůŝƚǇͺůĞǀĞůΗ͗ϲ
΃
΁
΃
΃
΃
΁
΃
΁
΃͕
ΗůĂƌŐͺĐŽŶƚĞǆƚΗ͗΂
ΗĚĂƚĞͺƌĂŶŐĞΗ͗΂
ΗƐƚĂƌƚͺĚĂƚĞΗ͗ΗϮϬϭϮͲϬϭͲϬϭΗ͕
ΗĞŶĚͺĚĂƚĞΗ͗ΗϮϬϭϰͲϬϭͲϬϭΗ
΃͕
ΗƚĞĐŚŶŝĐĂůͺƐĞƚƚŝŶŐͺŝĚΗ͗ΗƚƐsŝŐŽϭΗ
΃͕
ΗƌĞƐŽƵƌĐĞƐΗ͗΀
΂
ΗƌĞƐŽƵƌĐĞͺŝĚΗ͗ΗsĞƌďĂƉůĂŶĞƚΗ͕
ΗƌĞƐŽƵƌĐĞͺƚǇƉĞΗ͗ΗdŽŽůΗ͕
ΗƌĞƐŽƵƌĐĞͺƐĂƚŝƐĨŝĞĚͺƌĞƋƵŝƌĞŵĞŶƚΗ͗΀
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐΗ͗΀
ΗůĂϯΗ
΁
΃
΁
΃
΁
΃
΃
3.3.2.2.
Recommend Resources
The system provides recommendations on valid resources to be used for the implementation of
some Learning Activities included in a LARG.
Page 45/214
iTEC Project
17092012.Docx
Input parameters
Table 24. 'Recommmend Resources' parameters
recommendResources – Input
#
I1
Name
Description
Larg
LARG specification
Req.
T
Data type
JSONObject
(Sect. 3.2.1)
I2
learning_activities
I3
/ĚĞŶƚŝĨŝĞƌƐŽĨƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐ
ĨŽƌǁŚŝĐŚƌĞĐŽŵŵĞŶĚĂƚŝŽŶƐĂƌĞ
ƌĞƋƵĞƐƚĞĚ͘dŚĞǇŵƵƐƚďĞĂƐƵďƐĞƚŽĨ
ƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐŝŶĐůƵĚĞĚŝŶƚŚĞ
>Z'
DĂǆŝŵƵŵŶƵŵďĞƌŽĨƌĞƐƵůƚƐ
ĞǆƉĞĐƚĞĚĨŽƌĞĂĐŚZĞƋƵŝƌĞŵĞŶƚ
max_results
F
JSONArray
[ObjectID]
F
Number
Result
The method returns a list of recommendations on Resources for each Learning Activity. More
specifically:
-
For each Requirement, the method returns its type, whether it is satisfied or not, and a list
of recommended Resources.
Table 25. 'Recommend Resources' output
recommendResources – Output
#
O1
Name
Description
learning_activities
List of Learning Activities
Req.
T
Data type
JSONArray
[JSONObject]
O1.1
T
ObjectID
O1.2
Learning
Activity
(yes,
no,
partially)
T
String
[Yes,No,Parti
ally]
O1.3
la_
satisfied
Percentage
of
satisfied
Requirements in the Learning
T
Number
Page 46/214
iTEC Project
17092012.Docx
Activity
O1.4
Requirements
Requirements of the Learning
Activity
F
JSONArray
[JSONObject]
O1.4.1
requirement_id
T
ObjectID
O1.4.2
requirement_type
Requirement type
T
VocabularyTe
rm (D9.1,
Sect. 4.8)
O1.4.3
recommended_resources
List of recommended Resources,
sorted according to their level of
fulfilment
T
JSONArray
[ObjectID]
Errors
Table 26. 'Recommend Resources' errors
recommendResources – Errors
#
ϭ
Ϯ
ϯ
ϰ
ϱ
ϲ
ϳ
Ϯϭ
ϯϭ
Message
Description
ĞǆŝƐƚ
ĞǆŝƐƚ
>ĞĂƌŶŝŶŐĐƚŝǀŝƚǇŝƐŶŽƚ
ŝŶĐůƵĚĞĚŝŶ>Z'
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
ϰϱ
ϰϲ
dŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚǇŝƐŶŽƚŝŶĐůƵĚĞĚŝŶ>Z'
ĐŚĂŶŶĞů
Page 47/214
iTEC Project
Output example
Table 27. 'Recommend Resources' example response
΂
΂
΂
ΗtĞďŝŶĂƌ͗KǀĞƌǀŝĞǁŽĨƚŚĞ>ZΗ͕
ΗDϮϬϭϭΗ͕
Η>^>tŽƌŬƐŚŽƉ:ƵůǇϮϬϬϰΗ͕
Η>tĞďŝŶĂƌͲ^ĞƋƵĞŶĐŝŶŐ^KZΗ͕
ΗDϮϬϭϬΗ
΁
΃͕
΂
ΗzŽůĂŝŶĞŽƵƌĚĂΗ͕
Η:ĞĂŶͲEŽĞůŽůŝŶΗ͕
ΗdƐƵŶĞŽzĂŵĂĚĂΗ͕
ΗWǇƚŚĂŐŽƌĂƐ<ĂƌĂŵƉŝƉĞƌŝƐΗ͕
Η>ƵŝƐŶŝĚŽͲZŝĨſŶΗ
΁
΃
΁
΃͕
΂
΂
ΗsĞƌďĂƉůĂŶĞƚΗ͕
Η&ĂǀĞƐΗ͕
ΗŐĂŝŶďƵƚƐůŽǁĞƌΗ͕
ΗWŚŽƌƵŵΗ͕
Η&ƌĞĞŵŝŶĚΗ
Page 48/214
17092012.Docx
iTEC Project
17092012.Docx
΁
΃
΁
΃
΁
΃
΃
3.3.2.3.
Recommend Events
The system provides recommendations on valid Event resources to be used for the implementation
of some Learning Activities included in a LARG.
Input parameters
Table 28. 'Recommmend Events' parameters
recommendEvents – Input
#
I1
Name
Description
Req.
Larg
LARG specification
T
Data type
JSONObject
(Sect. 3.2.1)
I2
I3
learning_activities
max_results
/ĚĞŶƚŝĨŝĞƌƐŽĨƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐĨŽƌǁŚŝĐŚ
ƌĞĐŽŵŵĞŶĚĂƚŝŽŶƐĂƌĞƌĞƋƵĞƐƚĞĚ͘dŚĞǇŵƵƐƚďĞĂ
ƐƵďƐĞƚŽĨƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐŝŶĐůƵĚĞĚŝŶƚŚĞ
>Z'
DĂǆŝŵƵŵŶƵŵďĞƌŽĨƌĞƐƵůƚƐĞǆƉĞĐƚĞĚĨŽƌĞĂĐŚ
ZĞƋƵŝƌĞŵĞŶƚ
F
JSONArray
[ObjectID]
F
Number
Result
The method returns a list of recommendations on Event resources for each Learning Activity. More
specifically:
-
Page 49/214
iTEC Project
-
17092012.Docx
For each Requirement, the method returns its type (Event)13, whether it is satisfied or not,
and a list of recommended Resources
Table 29. 'Recommend Events' output
recommendEvents – Output
#
O1
Name
Description
learning_activities
Req.
T
Data type
JSONArray
[JSONObject]
O1.1
T
ObjectID
O1.2
Learning
Activity
(yes,
no,
partially)
T
String
[Yes,No,Partiall
y]
O1.3
la_
satisfied
Percentage
of
satisfied
Requirements in the Learning
Activity
T
Number
O1.4
Requirements
Requirements of the Learning
Activity
F
JSONArray
[JSONObject]
O1.4.1
requirement_id
T
ObjectID
O1.4.2
requirement_type
Requirement type
T
VocabularyTer
m (D9.1, Sect.
4.8)
O1.4.3
fulfilment
T
JSONArray
13
[ObjectID]
This method only considers Event resources. However, the type of resource is included in the result to
provide a common result structure for all methods in this group.
Page 50/214
iTEC Project
17092012.Docx
Errors
Table 30. 'Recommend Events' errors
recommendEvents – Errors
#
Message
Description
ϭ
ϯ
Ϯ
ĞǆŝƐƚ
ϰ
ĞǆŝƐƚ
ϱ
ϲ
ϳ
Ϯϭ
ϯϭ
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
ϰϱ
ϰϲ
ĐŚĂŶŶĞů
Output example
Table 31. 'Recommend Events' example response
΂
΂
΂
ΗDϮϬϭϭΗ͕
Page 51/214
iTEC Project
17092012.Docx
ΗDϮϬϭϬΗ
΁
΃
΁
΃͕
΂
ΗƌĞƋƵŝƌĞŵĞŶƚƐΗ͗΀΁
΃
΁΃΃
3.3.2.4.
Recommend Learning Content
The system provides recommendations on valid Learning Content resources to be used for the
implementation of some Learning Activities included in a LARG.
Input parameters
Table 32. 'Recommend Learning Content' parameters
recommendLearningContent – Input
#
I1
Name
Description
Req.
larg
LARG specification
T
Data type
JSONObject
(Sect. 3.2.1)
I2
I3
learning_activities
max_results
/ĚĞŶƚŝĨŝĞƌƐŽĨƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐĨŽƌ
ǁŚŝĐŚƌĞĐŽŵŵĞŶĚĂƚŝŽŶƐĂƌĞƌĞƋƵĞƐƚĞĚ͘
dŚĞǇŵƵƐƚďĞĂƐƵďƐĞƚŽĨƚŚĞ>ĞĂƌŶŝŶŐ
ĐƚŝǀŝƚŝĞƐŝŶĐůƵĚĞĚŝŶƚŚĞ>Z'
DĂǆŝŵƵŵŶƵŵďĞƌŽĨƌĞƐƵůƚƐĞǆƉĞĐƚĞĚĨŽƌ
ĞĂĐŚZĞƋƵŝƌĞŵĞŶƚ
F
JSONArray
[ObjectID]
F
Number
Result
The method returns a list of recommendations on Learning Content resources for each Learning
Activity. More specifically:
-
Page 52/214
iTEC Project
-
17092012.Docx
For each Requirement, the method returns its type (Learning Content)14, whether it is
satisfied or not, and a list of recommended Resources
Table 33. 'Recommend Learning Content' output
recommendLearningContent – Output
#
O1
Name
Description
learning_activities
Req.
T
Data type
JSONArray
[JSONObject]
O1.1
T
ObjectID
O1.2
Learning Activity (yes, no, partially)
T
String
[Yes,No,Partiall
y]
O1.3
la_
satisfied
in the Learning Activity
T
Number
O1.4
requirements
Requirements of the Learning Activity
F
JSONArray
[JSONObject]
O1.4.1
requirement_id
T
ObjectID
O1.4.2
requirement_type
Requirement type
T
VocabularyTer
m (D9.1, Sect.
4.8)
O1.4.3
fulfilment
T
JSONArray
14
[ObjectID]
This method only considers Learning Content resources. However, the type of resource is included in the
result to provide a common result structure for all methods in this group.
Page 53/214
iTEC Project
17092012.Docx
Errors
Table 34. 'Recommend Learning Content' errors
recommendLearningContent – Errors
#
Message
Description
ϭ
ϯ
Ϯ
ϰ
ϱ
ϲ
ϳ
Ϯϭ
ϯϭ
ĞǆŝƐƚ
ĞǆŝƐƚ
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
ϰϱ
ϰϲ
ĐŚĂŶŶĞů
Page 54/214
iTEC Project
17092012.Docx
Output example
Table 35. 'Recommend Learning Content' example response
΂
΂
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺŝĚΗ͗ΗƌĞƋƵŝƌĞ>ϭΗ͕
ΗůĐϭΗ
΁
΃
΁
΃͕
΂
΃
΁
΃
΃
3.3.2.5.
Recommend People
The system provides recommendations on valid People resources to be used for the
implementation of some Learning Activities included in a LARG.
Input parameters
Table 36. 'Recommend People' parameters
recommendPeople – Input
#
I1
Name
Description
Req.
larg
LARG specification
T
Data type
JSONObject
(Sect. 3.2.1)
Page 55/214
iTEC Project
I2
/ĚĞŶƚŝĨŝĞƌƐŽĨƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐĨŽƌǁŚŝĐŚ
ƌĞĐŽŵŵĞŶĚĂƚŝŽŶƐĂƌĞƌĞƋƵĞƐƚĞĚ͘dŚĞǇŵƵƐƚďĞĂ
ƐƵďƐĞƚŽĨƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐŝŶĐůƵĚĞĚŝŶƚŚĞ
>Z'
learning_activities
I3
DĂǆŝŵƵŵŶƵŵďĞƌŽĨƌĞƐƵůƚƐĞǆƉĞĐƚĞĚĨŽƌĞĂĐŚ
ZĞƋƵŝƌĞŵĞŶƚ
max_results
F
17092012.Docx
JSONArray
[ObjectID]
F
Number
Result
The method returns a list of recommendations on People resources for each Learning Activity.
More specifically:
-
For each Requirement, the method returns its type (Person)15, whether it is satisfied or not,
Table 37. 'Recommend People' output
recommendPeople – Output
#
O1
Name
Description
Req.
learning_activities
T
Data type
JSONArray
[JSONObject]
O1.1
T
ObjectID
O1.2
learning_activity_feasi
ble
Indication of the feasibility of the Learning
Activity (yes, no, partially)
T
String
[Yes,No,Partially]
O1.3
la_
satisfied
_requirements_percen
tage
Percentage of satisfied Requirements in
the Learning Activity
T
Number
O1.4
requirements
Requirements of the Learning Activity
F
JSONArray
[JSONObject]
O1.4.1
requirement_id
15
T
ObjectID
This method only considers Person resources. However, the type of resource is included in the result to
Page 56/214
iTEC Project
17092012.Docx
O1.4.2
requirement_type
Requirement type
T
VocabularyTerm
(D9.1, Sect. 4.8)
O1.4.3
recommended_resour
ces
List of recommended Resources, sorted
according to their level of fulfilment
T
JSONArray
[ObjectID]
Errors
Table 38. 'Recommend People' errors
recommendPeople – Errors
#
Message
Description
ϭ
ϯ
Ϯ
ϰ
ϱ
ϲ
ϳ
Ϯϭ
ϯϭ
ĞǆŝƐƚ
ĞǆŝƐƚ
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
ϰϱ
ϰϲ
ĐŚĂŶŶĞů
Page 57/214
iTEC Project
17092012.Docx
Output example
Table 39. 'Recommend People' example response
΂
΂
΂
ΗzŽůĂŝŶĞŽƵƌĚĂΗ͕
ΗdƐƵŶĞŽzĂŵĂĚĂΗ͕
ΗWǇƚŚĂŐŽƌĂƐ<ĂƌĂŵƉŝƉĞƌŝƐΗ͕
Η>ƵŝƐŶŝĚŽͲZŝĨſŶΗ
΁
΃
΁
΃͕
΂
΃
΁
΃
΃
3.3.2.6.
Recommend Tools
The system provides recommendations on valid Tool resources to be used for the implementation
of some Learning Activities included in a LARG.
Input parameters
Table 40. 'Recommend Tools' parameters
recommendTools – Input
#
I1
Name
Description
larg
LARG specification
Page 58/214
Req.
T
Data type
JSONObject
iTEC Project
17092012.Docx
(Sect. 3.2.1)
I2
ĨŽƌǁŚŝĐŚƌĞĐŽŵŵĞŶĚĂƚŝŽŶƐĂƌĞ
ƌĞƋƵĞƐƚĞĚ͘dŚĞǇŵƵƐƚďĞĂƐƵďƐĞƚŽĨ
ƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐŝŶĐůƵĚĞĚŝŶƚŚĞ
>Z'
learning_activities
I3
ĞǆƉĞĐƚĞĚĨŽƌĞĂĐŚZĞƋƵŝƌĞŵĞŶƚ
max_results
F
JSONArray
[ObjectID]
F
Number
Result
The method returns a list of recommendations on Event resources for each Learning Activity. More
specifically:
-
For each Requirement, the method returns its type (Tool)16, whether it is satisfied or not,
Table 41. 'Recommend Tools' output
recommendTools – Output
#
O1
Name
Description
Req.
learning_activities
Learning Activities para las que se
hace la solicitud
T
Data type
JSONArray
[JSONObject]
O1.1
Identificador
Activity
Learning
T
ObjectID
O1.2
Indica si la Learning Activity es
realizable, parcialmente realizable
o no realizable
T
String
[Yes,No,Partiall
y]
O1.3
la_
satisfied
Porcentaje
de
Requirements
satisfechos en la Learning Activity
T
Number
O1.4
requirements
Requisitos de la Learning Activity
F
JSONArray
de
una
[JSONObject]
16
This method only considers Tool resources. However, the type of resource is included in the result to
Page 59/214
iTEC Project
17092012.Docx
O1.4.1
requirement_id
Identificador del requisito
T
ObjectID
O1.4.2
requirement_type
Tipo de requirement
T
VocabularyTer
m (D9.1, Sect.
4.8)
O1.4.3
fulfilment
T
JSONArray
[ObjectID]
Errors
Table 42. 'Recommend Tools' errors
recommendTools – Errors
#
Message
Description
ϭ
ϯ
Ϯ
ĞǆŝƐƚ
ϰ
ĞǆŝƐƚ
ϱ
ϲ
ϳ
Ϯϭ
ϯϭ
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
ϰϱ
ϰϲ
ĐŚĂŶŶĞů
Output example
Table 43. 'Recommend Tools' example response
΂
Page 60/214
iTEC Project
17092012.Docx
΂
΃͕
΂
΂
Η&ĂǀĞƐΗ͕
ΗŐĂŝŶďƵƚƐůŽǁĞƌΗ͕
ΗWŚŽƌƵŵΗ͕
Η&ƌĞĞŵŝŶĚΗ
΁
΃
΁
΃
΁
΃
΃
3.3.2.7.
Search Event
The system provides a sorted list of Events that satisfy the Event Requirement defined by the
actor. The returned list is created in accordance with the semantic knowledge and rules of the
iTEC SDE.
This method offers an enhanced functionality over that provided by the basic search in the iTEC
Back-End Registry as it uses all the knowledge available through the iTEC SDE Semantic
Database.
Input parameters
Table 44. 'Search Event' parameters
searchEvent – Input
#
I1
Name
Description
event_requirement
Event requirement
Req.
T
Data type
JSONObject
(Sect. 3.2.1)
Page 61/214
iTEC Project
I2
ĞǆƉĞĐƚĞĚ
max_results
F
17092012.Docx
Number
Result
The method returns a list of Events sorted in accordance with the level of satisfaction of the
Requirement.
If a direct requirement is specified (i.e., through the selection of a specific Event), similar Events
will be returned if available.
Table 45. 'Search Event' output
searchEvent – Output
#
O1
Name
Description
resources
List of Resources found satisfying the
Requirement, sorted according to their
level of fulfilment
Req.
T
Data type
JSONArray
[ObjectID]
Errors
Table 46. 'Search Event' errors
searchEvent – Errors
#
Message
Description
ϱ
ϯϮ
ϰϭ
ϯϭ
ϯϯ
ϰϮ
ϰϯ
Output example
Table 47. 'Search Event' example response
΂
ΗDϮϬϭϭΗ͕
Page 62/214
iTEC Project
17092012.Docx
ΗDϮϬϭϬΗ͕
ΗϲƚŚ/ŶƚĞƌŶĂƚŝŽŶĂů^ǇŵƉŽƐŝƵŵΗ͕
ΗtŽƌŬƐŚŽƉŽŶ^KZD^ĞƋƵĞŶĐŝŶŐΗ͕
Η^Wd^ƚĂŶĚĂƌĚƐĨŽƌĚŝŐŝƚĂůΗ͕
ΗĐĐĞƐƐŝďŝůŝƚǇŝŶWƌĂĐƚŝĐĞŽΗ͕
ΗĞWŽƌƚĨŽůŝŽϮϬϬϲ͗Ğ^ƚƌĂƚĞŐŝĞΗ
΁
΃
΃
3.3.2.8.
Search Learning Content
The system provides a sorted list of Learning Content that satisfies the Learning Content
Requirement defined by the actor. The returned list is created in accordance with the semantic
knowledge and rules of the iTEC SDE.
Back-End Registry as it uses all the knowledge available through the iTEC SDE semantic
database.
Input parameters
Table 48. 'Search Learning Content' parameters
searchLearningContent – Input
#
I1
Name
Description
learning_content_requirement
Learning Content requirement
Req.
T
Data type
JSONObject
(Sect. 3.2.2.5
I2
max_results
ĞǆƉĞĐƚĞĚ
F
Number
Result
The method returns a list of Learning Content sorted in accordance with the level of satisfaction of
the Requirement.
If a direct requirement is specified (i.e., through the selection of a specific Learning Content),
similar Learning Contents will be returned if available.
Page 63/214
iTEC Project
17092012.Docx
Table 49. 'Search Learning Content' output
searchLearningContent – Output
#
O1
Name
Description
Req.
resources
List of Resources found satisfying the Requirement,
sorted according to their level of fulfilment
Data type
T
JSONArray
[ObjectID]
Errors
Table 50. 'Search Learning Content' errors
searchLearningContent – Errors
#
Message
Description
ϱ
ϯϯ
ϯϭ
ϰϭ
ϰϮ
dŚĞůĂŶŐƵĂŐĞĚŽĞƐŶŽƚŚĂǀĞĂĐŽƌƌĞĐƚĨŽƌŵĂƚ;/^KϲϯϵͲϭͿŽƌŶŽƚƌĞŐŝƐƚĞƌĞĚ
Output example
Table 51. 'Search Learning Content' example response
΂
ΗůĐϭ͕͟
͞ůĐϮ͟
΁
΃
΃
3.3.2.9.
Search Person
The system provides a sorted list of People that satisfy the Person Requirement defined by the
actor. The returned list is created in accordance with the semantic knowledge and rules of the
iTEC SDE.
Page 64/214
iTEC Project
17092012.Docx
database.
Input parameters
Table 52. 'Search Person' parameters
searchPerson – Input
#
I1
Name
Description
person_requirement
Person requirement
Req.
T
Data type
JSONObject
(Sect. 0)
I2
ĞǆƉĞĐƚĞĚ
max_results
F
Number
Result
The method returns a list of People sorted in accordance with the level of satisfaction of the
Requirement.
If a direct requirement is specified (i.e., through the selection of a specific Person), similar Persons
will be returned if available.
Table 53. 'Search Person' output
searchPerson – Output
#
O1
Name
Description
Req.
resources
T
Data type
JSONArray
[ObjectID]
Errors
Table 54. 'Search Person' errors
searchPerson – Errors
#
Message
Description
ϱ
ϯϯ
ϯϭ
Page 65/214
iTEC Project
ϰϭ
ϰϮ
ϰϱ
ϰϲ
ĐŚĂŶŶĞů
17092012.Docx
Output example
Table 55. 'Search Person' example response
΂
ΗzŽůĂŝŶĞŽƵƌĚĂΗ
΁
΃
΃
3.3.2.10. Search Tool
The system provides a sorted list of Tools (from all the Tools registered in the iTEC SDE database)
that satisfy the Tool Requirement defined by the actor. The returned list is created in accordance
with the semantic knowledge and rules of the iTEC SDE.
database.
Input parameters
Table 56. 'Search Tool' parameters
searchTool – Input
#
I1
Name
Description
Req.
tool_requirement
Tool requirement
T
Data type
JSONObject
(Sect. 3.2.2.2)
I2
technical_settings
I3
max_results
>ŝƐƚŝŶĐůƵĚŝŶŐƚŚĞŝĚĞŶƚŝĨŝĞƌƐŽĨƚŚĞdĞĐŚŶŝĐĂů
^ĞƚƚŝŶŐƐƚŽďĞĐŚĞĐŬĞĚ
F
JSONArray
[ObjectID]
F
Number
DĂǆŝŵƵŵŶƵŵďĞƌŽĨƌĞƐƵůƚƐĞǆƉĞĐƚĞĚ
Page 66/214
iTEC Project
17092012.Docx
Result
The method returns a list of Tools sorted in accordance with the level of satisfaction of the
Requirement.
If a direct requirement is specified (i.e., through the selection of a specific Tool), similar Tools will
be returned if available.
Table 57. 'Search Tool' output
searchTool – Output
#
O1
Name
Description
Req.
resources
T
Data type
JSONArray
[ObjectID]
Errors
Table 58. 'Search Tool' errors
searchTool – Errors
#
Message
Description
ϱ
ĞǆŝƐƚ
ϯϯ
Ϯ
ϯϭ
ϰϭ
ϰϮ
ϰϰ
Output example
Table 59. 'Search Tool' example response
΂
ΗŶƐǁĞƌ'ĂƌĚĞŶΗ͕
ΗϮϰŝŵΗ͕
ΗKŵŶŝƵŵůĂƐƐƌŽŽŵ^ŽĨƚǁĂƌĞΗ͕
Η;ǆǇͿǁƌŝƚĞ͘ŝƚΗ͕
ΗƵůĞŶƚΘηϴϮϭϳ͖Ɛ^ĐƌĞĞŶZĞĐŽƌĚĞƌΗ͕
Η&ŽůůŽǁĨŽƌŵĂƚŝŽŶΗ͕
Page 67/214
iTEC Project
17092012.Docx
ΗzĂǁŶƵƐƚĞƌΗ͕
Η&ƌĞĞŵŝŶĚΗ͕
Η&ĂǀĞƐΗ
΁
΃
΃
3.3.2.11. Validate LARG
The system analyses if the current selection of Resources (Tool, Person, Event, Learning Content)
satisfies the Requirements of a set of Learning Activities included in a LARG under a specific
LARG Context.
A LARG may be created incrementally. This method offers the functionality to check whether or not
the current LARG already fulfils all the Requirements of all or a set of Learning Activities.
Input parameters
Table 60. 'Validate LARG' parameters
validateLARG – Input
#
I1
Name
Description
larg
LARG specification to be validated
Req.
T
Data type
JSONObject
(Sect. 3.2.1)
I2
learning_activities
/ĚĞŶƚŝĨŝĞƌƐŽĨƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐƚŽďĞ
ǀĂůŝĚĂƚĞĚ͘dŚĞǇŵƵƐƚďĞĂƐƵďƐĞƚŽĨƚŚĞ
>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐŝŶƚŚĞ>Z'
F
JSONArray
[ObjectID]
Result
The system returns the feasibility analysis of the Learning Activities involved. More specifically:
-
Percentage of totally or partially feasible Learning Activities
For each Learning Activity, the method returns its feasibility condition (yes, partially, no),
the percentage of satisfied requirements and the list of associated requirements
For each Requirement, the system returns whether it is satisfied or not, and if do not, the
reasons why it is not satisfied
Page 68/214
iTEC Project
17092012.Docx
Table 61. 'Validate LARG' output
validateLARG – Output
#
Name
Description
Req.
Data type
O1
feasible_learning_ac
tivities_percentage
Percentage of feasible Learning Activities
T
Number
O2
learning_activities
List of Learning Activities including their
feasibility analysis
T
JSONArray
[JSONObject]
O2.1
T
ObjectID
O2.2
learning_activity_fea
sible
Feasibility indication of the Learning Activity
(yes, no, partially)
T
String
[Yes,No,Partiall
y]
O2.3
la_
satisfied
_requirements_perc
entage
Percentage of satisfied Requirements in the
Learning Activity
T
Number
O2.4
Requirements
List of requirements of the Learning Activity
T
JSONArray
[JSONObject]
O2.4.1
requirement_id
T
String
O2.4.2
Satisfied
“Yes” if the Requirement can be satisfied
with the selected Resources. “No”
otherwise.
T
Boolean
O2.4.3
Reasons
Reasons
satisfied
F
JSONArray
[JSONObject]
O2.4.3.1
reason_code
Reason code
T
Number
O2.4.3.2
reason_message
Descriptive message
F
String
why
the
requirement
Page 69/214
is
not
iTEC Project
17092012.Docx
Errors
Table 62. 'Validate LARG' errors
validateLARG – Errors
#
ϭ
Ϯ
ϯ
Message
Description
ĞǆŝƐƚ
ĞǆŝƐƚ
ϰ
ϱ
ϲ
ϳ
Ϯϭ
ϯϭ
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
ϰϱ
ϰϲ
ĐŚĂŶŶĞů
Output example
Table 63. 'Validate LARG' example response
΂
ΗĨĞĂƐŝďůĞͺůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϱϬ͕
΂
΂
Page 70/214
iTEC Project
17092012.Docx
ΗƌĞƋƵŝƌĞŵĞŶƚͺƐĂƚŝƐĨŝĞĚΗ͗ƚƌƵĞ
΃͕
΂
΃
΁
΃͕
΂
ΗůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚǇͺĨĞĂƐŝďůĞΗ͗ΗEŽΗ͕
ΗůĂͺƐĂƚŝƐĨŝĞĚͺƌĞƋƵŝƌĞŵĞŶƚƐͺƉĞƌĐĞŶƚĂŐĞΗ͗Ϭ͕
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺƐĂƚŝƐĨŝĞĚΗ͗ĨĂůƐĞ͕
ΗƌĞĂƐŽŶƐΗ͗΀
΂
ΗƌĞĂƐŽŶͺĐŽĚĞΗ͗Ϯ͕
ΗƌĞĂƐŽŶͺŵĞƐƐĂŐĞΗ͗ΗdŚĞƐĞůĞĐƚĞĚƚŽŽůƐŝŶ>ĞĂƌŶŝŶŐĐƚŝǀŝƚǇĚŽĞƐŶŽƚ
ƐĂƚŝƐĨŝĞĚƚŚŝƐƌĞƋƵŝƌĞŵĞŶƚΗ
΃
΁
΃
΁
΃
΁
΃
΃
3.3.2.12. Analyse Learning Content Requirements
The system analyses if a selection of Learning Content satisfies the Learning Content
requirements of an identified set of Learning Activities within those included in a LARG under a
specific LARG Context.
Input parameters
Table 64. 'Analyse Learning Content Requirements' parameters
analyseLearningContentRequirements – Input
#
I1
Name
Description
larg
Page 71/214
Req.
T
Data type
JSONObject
iTEC Project
17092012.Docx
(Sect. 3.2.1)
I2
learning_activities
ƚŽďĞǀĂůŝĚĂƚĞĚ͘dŚĞǇŵƵƐƚďĞĂ
ƐƵďƐĞƚŽĨƚŚĞ>ĞĂƌŶŝŶŐĐƚŝǀŝƚŝĞƐŝŶ
ƚŚĞ>Z'
F
JSONArray
[ObjectID]
Result
The system returns the feasibility analysis of the Learning Activities involved in terms of their
Learning Content Requirements. More specifically:
-
For each Requirement, the system returns whether it is satisfied or not, and if don’t, the
Table 65. 'Analyse Learning Content Requirements' output
analyseLearningContentRequirements – Output
#
Name
Description
Req.
O1
feasible_learning_activities
_percentage
Percentage
Activities
Learning
T
Number
O2
learning_activities
T
JSONArray
of
feasible
Data type
[JSONObject]
O2.1
T
ObjectID
O2.2
Feasibility indication of the Learning
T
String
[Yes,No,Partial
ly]
O2.3
la_
satisfied
T
Number
O2.4
requirements
List of requirements of the Learning
Activity
T
JSONArray
[JSONObject]
Page 72/214
iTEC Project
17092012.Docx
O2.4.1
requirement_id
T
String
O2.4.2
satisfied
satisfied with the selected Resources.
“No” otherwise.
T
Boolean
O2.4.3
reasons
Reasons why the requirement is not
satisfied
F
JSONArray
[JSONObject]
O2.4.3.1
reason_code
Reason code
T
Number
O2.4.3.2
reason_message
Descriptive message
F
String
Errors
Table 66. 'Analyse Learning Content Requirements' errors
analyseLearningContentRequirements – Errors
#
Message
Description
ϭ
ϯ
Ϯ
ϰ
ϱ
ϲ
ϳ
Ϯϭ
ϯϭ
ĞǆŝƐƚ
ĞǆŝƐƚ
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
ϰϱ
ϰϲ
ĐŚĂŶŶĞů
Page 73/214
iTEC Project
17092012.Docx
Output example
Table 67. 'Analyse Learning Content Requirements' example response
΂
΂
΂
ΗƌĞƋƵŝƌĞŵĞŶƚͺƚǇƉĞΗ͗Η>ĞĂƌŶŝŶŐŽŶƚĞŶƚΗ͕
΃
΁
΃͕
΂
΃
΁
΃
΃
3.3.2.13. Analyse Event Requirements
The system analyses if a LARG satisfies the Event Requirements of a set of Learning Activities
included in a LARG under a specific LARG Context.
Input parameters
Table 68. 'Analyse Event Requirements' parameters
analyseEventRequirements – Input
#
I1
Name
Description
larg
Req.
T
Data type
JSONObject
(Sect. 3.2.1)
Page 74/214
iTEC Project
I2
learning_activities
ƚŚĞ>Z'
17092012.Docx
F
JSONArray
[ObjectID]
Result
The system returns the feasibility analysis of the Learning Activities involved in terms of their Event
Requirements. More specifically:
-
Table 69. 'Analyse Event Requirements' output
analyseEventRequirements – Output
#
Name
Description
Req.
O1
_percentage
Percentage
Activities
Learning
T
Number
O2
learning_activities
T
JSONArray
of
feasible
Data type
[JSONObject]
O2.1
T
ObjectID
O2.2
T
String
[Yes,No,Partiall
y]
O2.3
la_
satisfied
T
Number
O2.4
requirements
Activity
T
JSONArray
[JSONObject]
Page 75/214
iTEC Project
17092012.Docx
O2.4.1
requirement_id
T
String
O2.4.2
Satisfied
“No” otherwise.
T
Boolean
O2.4.3
Reasons
satisfied
F
JSONArray
[JSONObject]
O2.4.3.1
reason_code
Reason code
T
Number
O2.4.3.2
reason_message
Descriptive message
F
String
Errors
Table 70. 'Analyse Event Requirements' errors
analyseEventRequirements – Errors
#
Message
Description
ϭ
ϯ
Ϯ
ϰ
ϱ
ϲ
ϳ
Ϯϭ
ϯϭ
ĞǆŝƐƚ
ĞǆŝƐƚ
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
ϰϱ
Page 76/214
iTEC Project
ϰϲ
ĐŚĂŶŶĞů
17092012.Docx
Output example
Table 71. 'Analyse Event Requirements' example response
΂
΂
΂
΃
΁
΃͕
΂
΃
΁
΃
΃
3.3.2.14. Analyse Person Requirements
The system analyses if a LARG satisfies the Person Requirements of a set of Learning Activities
included in a LARG under a specific LARG Context.
Input parameters
Table 72. 'Analyse Person Requirements' parameters
analysePersonRequirements – Input
#
I1
Name
Description
larg
Req.
T
Data type
JSONObject
(Sect. 3.2.1)
Page 77/214
iTEC Project
I2
ƚŚĞ>Z'
learning_activities
17092012.Docx
F
JSONArray
[ObjectID]
Result
The system returns the feasibility analysis of the Learning Activities involved in terms of their
Person Requirements. More specifically:
-
Table 73. 'Analyse Person Requirements' output
analysePersonRequirements – Output
#
Name
Description
Req.
Data type
O1
feasible_learning_ac
tivities_percentage
Percentage of feasible Learning Activities
T
Number
O2
learning_activities
List of Learning Activities including their
feasibility analysis
T
JSONArray
[JSONObject]
O2.1
T
ObjectID
O2.2
learning_activity_fea
sible
Feasibility indication of the Learning Activity
(yes, no, partially)
T
String
[Yes,No,Parti
ally]
O2.3
la_
satisfied
_requirements_perc
entage
Percentage of satisfied Requirements in the
Learning Activity
T
Number
Page 78/214
iTEC Project
O2.4
requirements
List of requirements of the Learning Activity
17092012.Docx
T
JSONArray
[JSONObject]
O2.4.1
requirement_id
T
String
O2.4.2
Satisfied
“Yes” if the Requirement can be satisfied
with the selected Resources. “No”
otherwise.
T
Boolean
O2.4.3
Reasons
Reasons
satisfied
F
JSONArray
[JSONObject]
O2.4.3.1
reason_code
Reason code
T
Number
O2.4.3.2
reason_message
Descriptive message
F
String
why
the
requirement
is
not
Errors
Table 74. 'Analyse Person Requirements' errors
analysePersonRequirements – Errors
#
Message
Description
ϭ
ϯ
Ϯ
ϰ
ϱ
ϲ
ϳ
Ϯϭ
ϯϭ
ĞǆŝƐƚ
ĞǆŝƐƚ
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
Page 79/214
iTEC Project
ϰϱ
ϰϲ
ĐŚĂŶŶĞů
17092012.Docx
Output example
Table 75. 'Analyse Person Requirements' example response
΂
΂
΂
΃
΁
΃͕
΂
΃
΁
΃
΃
3.3.2.15. Analyse Tool Requirements
The system analyses if a LARG satisfies the Tool Requirements of a set of Learning Activities
included in a LARG under a specified LARG Context.
Page 80/214
iTEC Project
17092012.Docx
Input parameters
Table 76. 'Analyse Technology Requirements' parameters
analyseToolRequirements – Input
#
I1
Name
Description
Req.
larg
T
Data type
JSONObject
(Sect. 3.2.1)
I2
learning_activities
ƚŚĞ>Z'
F
JSONArray
[ObjectID]
Result
The system returns the feasibility analysis of the Learning Activities involved in terms of their Tool
Requirements. More specifically:
-
Table 77. 'Analyse Tool Requirements' output
analyseToolRequirements – Output
#
Name
Description
Req.
O1
_percentage
Percentage
Activities
Learning
T
Number
O2
learning_activities
T
JSONArray
of
feasible
Data type
[JSONObject]
Page 81/214
iTEC Project
17092012.Docx
O2.1
T
ObjectID
O2.2
T
String
[Yes,No,Parti
ally]
O2.3
la_
satisfied
T
Number
O2.4
requirements
Activity
T
JSONArray
[JSONObject]
O2.4.1
requirement_id
T
String
O2.4.2
Satisfied
“No” otherwise.
T
Boolean
O2.4.3
Reasons
satisfied
F
JSONArray
[JSONObject]
O2.4.3.1
reason_code
Reason code
T
Number
O2.4.3.2
reason_message
Descriptive message
F
String
Errors
Table 78. 'Analyse Tool Requirements' errors
analyseToolRequirements – Errors
#
Message
Description
ϭ
ϯ
Ϯ
ϰ
ϱ
ϲ
ϳ
Ϯϭ
ĞǆŝƐƚ
ĞǆŝƐƚ
Page 82/214
iTEC Project
ϯϭ
ϯϮ
ϰϭ
ϯϯ
ϰϮ
ϰϯ
ϰϰ
ϰϱ
ϰϲ
ĐŚĂŶŶĞů
17092012.Docx
Output example
Table 79.'Analyse Tool Requirements' example response
΂
ΗĨĞĂƐŝďůĞͺůĞĂƌŶŝŶŐͺĂĐƚŝǀŝƚŝĞƐͺƉĞƌĐĞŶƚĂŐĞΗ͗ϭϬϬ͕
΂
΃
΁
΃
΃
3.4. Method List
Table 80. SDE-API method list
Section
Name
ID (method invocation)
Page
Assess.Technical.Feasibility
34
Get.Feasible.Learning.Stories
38
Get Suitable Technical Setting
Get.Suitable.Technical.Setting
39
Technical
Localisation
Page 83/214
iTEC Project
Resource
Planning
Analyse
Learning
Requirements
17092012.Docx
Content Analyse.Learning.Content.Requirements 71
Analyse Event Requirements
Analyse.Event.Requirements
74
Analyse Person Requirements
Analyse.Person.Requirements
77
Analyse Tool Requirements
Analyse.Tool.Requirements
80
Create LARG
Create.LARG
42
Recommend Events
Recommend.Events
49
Recommend Learning Content
Recommend.Learning.Content
52
Recommend People
Recommend.People
55
Recommend Tools
Recommend.Tools
58
Recommend Resources
Recommend.Resources
45
Search Event
Search.Event
61
Search Learning Content
Search.Learning.Content
63
Search Person
Search.Person
64
Search Tool
Search.Tool
66
Validate LARG
Validate.LARG
68
3.5. Errors
Table 81. JSON-RPC error list
Code
Message
Description
-32700
Parse error
Invalid JSON. An error occurred on the server
while parsing the JSON text
-32603
Internal error
Internal JSON-RPC error
Page 84/214
iTEC Project
17092012.Docx
-32602
Invalid params
Invalid method parameters
-32601
Method not found
The requested remote procedure does not
exist or is not available
-32600
Invalid Request
The received request is not a valid JSON-RPC
request
Table 82. SDE-API specific error list
Code
Message
Description
1
Learning Story does not There is no Learning Story in the KB with the
exist
identifier specified
2
Technical Setting does not There is no Technical Setting in the KB with the
exist
3
LARG does not exist
4
Learning Activity does not There is no Learning Activity in the KB with the
exist
5
Resource does not exist
There is no Resource in the KB with the
6
Person does not exist
There is no Person in the KB with the identifier
specified
7
Requirement
exist
21
Learning Activity is not The Learning Activity is not included in LARG
included in LARG
31
Invalid language
The language does not have a correct format
(ISO 639-1) or not registered
32
Invalid date
The date does not have a supported format
(yyyy-MM-dd)
33
Invalid number
Number out of range or with an incorrect format
does
There is no LARG in the KB with the identifier
specified
not There is no Requirement in the KB with the
Page 85/214
iTEC Project
17092012.Docx
34
Invalid key:value list
The string does not have a correct format
(key1:value1nullkey2:value2)
35
Invalid url
The URL does not have a correct format
36
Invalid rule syntax
The rule syntax is not correct
37
Invalid rule language
The rule language is not supported
41
Invalid vocabulary term
The term does not belong to any vocabulary
42
Invalid resource type
The resource does not have the type indicated
43
Invalid event type
The event type does not exist
44
Invalid tool type
The tool type does not exist
45
Invalid person type
The person type does not exist
46
Invalid
channel
101
Method not yet available
communication The resource is not a valid communication
channel
The specified method is not yet available
Page 86/214
iTEC Project
17092012.Docx
4. Apprendix IV: ENRICHMENT OF DATA
A Knowledge-Based System like the SDE is able to infer conclusions from information available in
its Knowledge Base. To successfully achieve this objective, two basic elements are needed,
namely a correctly defined underlying semantic model (i.e., the ontology and inference rules
inherent to the domain conforming the Knowledge Base’s TBox (Li & Horrocks, 2004)), and a
collection of facts providing information about the present situation of the domain of interest (i.e.,
ABox) as accurate and complete as possible. Like human beings, smart systems will take the
better decisions about an issue the greater is their knowledge about it. The lesser the information
available, the more error-prone and inaccurate reasoning processes. In turn, the more complete is
the information available about the domain, the more accurate and coherent will be the
conclusions. Therefore, a rich, well-defined Knowledge Base is the basic foundation of a
successful smart system.
During the first project year, members of WP10 defined a specific semantic model for the SDE with
the collaboration and under the supervision of other project partners. This model identifies the
concepts, their relations, and the heuristics needed to characterize resources (i.e., tools, people,
events and educational content) that may be utilized to deploy Learning Activities. Once the
semantic model was available, information on the mentioned resources would be stored in the
SDE’s Knowledge Base according to the terminology defined there. This information constitutes
the ABox, that is, the facts representing a part of the universe (i.e., the domain of interest) at a
specific time. Data about resources that may be utilized in a Learning Activity is available in several
repositories within the iTEC technological architecture (cf. D10.2 Figure 2). The SDE will collect
and adapt these pieces of information to populate its Knowledge Base. This information may be
more or less complete depending on how it was introduced, as the individuals in charge of this task
may not have all relevant data about the resource being catalogued, or may not have the required
skills and competences to do it correctly.
Presently, the Web hosts billons of pieces of information of all kinds and origins. A relevant part of
this information can be freely accessed and reused. Under these assumptions, it would be possible
to collect these freely shared pieces of information to enrich any Knowledge Base, that is, to
complete the information stored locally using the huge amount of data available on the Web. This
will enable software agents to increase their knowledge from a wide range of sources providing
different points of view and levels of detail. This way, potentially complete information may be
obtained. The process of completing the information about objects already present in a Knowledge
Base is known in the literature as Semantic Enrichment. This process may be implemented using
automated tools that provide useful results in limited time and without much effort.
WP10 explored the possibility to access information available in several online sources to
supplement and enrich the data available in iTEC repositories. In particular, Sect 4.3 briefly
discusses some experiments performed to assess the feasibility, the potential and other issues
related to this task. Before that, we discuss in Sect. 4.1 the general problem of information retrieval
from heterogeneous sources over the Internet. Some tools related to this process are collected in
Appendix V. Besides, Section 4.2 introduces techniques targeted to the identification of (different)
information records referencing the same element or individual. Some relevant tools implementing
these techniques are collected in Appendix VI.
Page 87/214
iTEC Project
17092012.Docx
4.1. Issues on accessing to information sources
With the popularization of the Web, many different sources of shared heterogeneous information
become freely accessible. Sources available may be classified according to the language used to
expose this information (e.g., HTML, XML, SQL, RDF, JSON) Each of these types of sources has
been designed to satisfy a different need (e.g., to be accessible to humans, to facilitate the
communication between applications, to facilitate data storage) Semantically enriching a system’s
Knowledge Base means taking the most of the available information sources online to complete
information stored locally.
Insofar automated enrichment is concerned, the most interesting repositories are those specifically
designed to be easily readable and interpretable by machines, that is, those offering their
information according to a Knowledge Representation language like the ones proposed by the
Linked Open Data (LOD) initiative (Bizer, Heath, & Berners-Lee, 2009). The reason for that is
because the enrichment process’ complexity is dramatically reduced, and therefore its automation
is greatly simplified. On the other side, other types of sources would need a previous translation or
transformation process to represent them according to a normalized language, RDF in our case.
This latter process will require the active participation of experts.
We will discuss below some of the most relevant issues related to the access to external data
according to the different methods used to represent information, including both semantically
represented sources and other sources requiring a previous translation phase to be utilized to
enrich the Knowledge Base.
4.1.1. Access to information described in RDF
The first steps towards the design and deployment of the so-called Web 3.0, the Semantic Web or
the Web of Data were performed along the first years of the present century. This process is based
on completing the information available on the Web, mostly intended for human consumption, with
information easily accessible and readable by machines. This is achieved primarily by representing
data using languages specifically designed to describe resources, like RDF (Lassila & Swick,
1999).
Indeed, to facilitate the natural evolution of the Web from the classical model to the new Web 3.0
scenario, the W3C promotes the use of RDFa. RDFa defines an extension of XHTML where RDF
triples are embedded in web pages using meta and link attributes. This way, users can keep
visualizing web pages according to a friendly format, and at the same time software agents can
extract semantic information from attributes present in the XHTML code, which are totally
transparent to human users.
As a drawback, this approach requires a greater involvement from web authors, as semantic
information has to be included manually. Presently, some tools are available to generate web
pages that simplify this task, but their use is not yet widespread. Nevertheless, thanks to the
behaviour of search engines like Google, which use this information to define their crawling
strategies, developers have started to regularly apply RDFa annotations to improve their relevance
in the results offered by these search engines.
A more effective approach, which was proposed by Tim Berners Lee himself and the W3C, is the
Linked Data initiative (Bizer, Heath, & Berners-Lee, 2009) (Heath & Bizer, 2011) .This proposal
defines some methodological principles (Bizer, Cyganiak, & Heath, 2007) on how information shall
Page 88/214
iTEC Project
17092012.Docx
be published to create a web of connections among semantic documents, which in turn will provide
a network of nodes containing data interpretable by software agents. The final objective is to reuse
information available in repositories to make it publicly available as RDF triples, and to link it to
data available in other repositories using the expressive power of RDF. This way, a system may
feed from disperse but related sources of information to attain objectives wider than the initial ones.
Unlike the ordinary Web, Linked Data links data and not only documents, which facilitates the
creation of a huge database of interconnected nodes over the Web.
In line with this approach, Linked Open Data (LOD) was developed (Hausenblas & Karnstedt,
2010) under the assumption that data published using Linked Data must be open and free in a way
that any user, human or machine, may consult and reuse. This initiative is continuously growing
thanks to the relevant support received from many institutions and companies (e.g., several
governments, including UK’s, are starting to publish their data according to an open format). The
LOD’s Web page offers an updated diagram of the cloud of semantic repositories and the many
links established among them (cf. Figure 9). By September 2011 this initiative had already
registered 295 linked datasets including more than 31 billion RDF triples (Bizer, Jentzsch, &
Cyganiak, 2011). These repositories include information from many different fields (e.g., scientific,
medical, geographical, political, multimedia) and they may be classified according to a specific
field, or as multidisciplinary. The latter ones serve as interconnectors or information hubs, as they
may be used to establish relations with several different and heterogeneous repositories. The most
relevant dataset supporting most of interconnections in LOD is DBPedia (Bizer, et al., 2009).
DBpedia maintains semantic information extracted from Wikipedia, a universal and collaborative
knowledge portal. Because of that, this repository freely publishes a huge amount of information of
a very diverse nature, which is constantly updated by thousands of producers.
From the SDE standpoint, accessing information available in a LOD node is fairly simple because it
is possible to obtain data about a given resource from its URI, using the HTTP protocol. Besides, in
most cases, LOD nodes provide SPARQL Endpoints (Prud'hommeaux & Seaborne, 2008) to
retrieve information according to some search criteria specified in advance. On the other side,
information retrieved from a LOD node is available in RDF, that is, in the same format as the SDE’s
Knowledge Base. However, retrieved RDF sentences may use a terminology (i.e., an ontology)
that differs from the one defined at the SDE’s semantic model. In any case, during the design of
the SDE’s semantic model we tried to reuse as much as possible existing Semantic Web
terminologies, like Dublin Core (DCMI, 1995) or FOAF (Brickley, 2000), among others.
4.1.2. Access to information not described in RDF
The community’s efforts in the generation of semantic content allowed the Semantic Web to evolve
and expand its influence along the last years. Nevertheless, it is still today a fairly novel and little
explored area, where information is still scarce in many fields. Besides, it is considered a
specialized publication mechanism, where content creators must be familiarized with the
technology and the language. This is something beyond the average Internet user. Presently, most
information is still published in a human-friendly format, hard to process by computers. Because of
that, information has to be translated to data conditioned to be manipulated by the final user, or to
be understood by machines.
Along this translation stage, experts may gather information on their own to be manually stored in
the Knowledge Base, but this process is tedious and slow. As a consequence, tools are needed to
automatically perform this task. However, information in these data sources is represented in many
different ways (e.g., HTML, XML, as relational database content), and therefore there is no single
Page 89/214
iTEC Project
17092012.Docx
tool available to translate into a semantic format such a wide range of formats. In turn, we can find
different tools and translation strategies depending on the type of data to be transformed.
Figure 9. LOD Cloud’s node diagram, Sept. 2011
In any case, experts’ contribution to the transformation to non-semantic sources is more active and
relevant than in the case of semantic sources. Experts must locate the data source to identify the
most relevant information fields. Then, they must correctly select the appropriate translation tool
and configure it to extract the pieces of information, and enrich the Knowledge Base using as
precise as possible pieces of information. This process is rather complex, and therefore error
prone. Besides, the less structured the information is, the greater the chance of errors appearing.
This process is known as data scrapping, data wrapping, data extraction, or data harvesting,
among others. It has been thoroughly studied and developed along the last years by the
information extraction (IE) community (Cowie & Lehnert, 1996) (Laender, Ribeiro-Neto, Da Silva, &
Teixeira, 2002) (Chang, Kayed, Girgis, & Shaalan, 2006) (Sarawagi, 2008) (Baumgartner, Gottlob,
& Herzog, 2009) (Ferrara, Fiumara, & Baumgartner, 2011) (Fiumara, 2007).
IE tries to develop tools to extract relevant information from source data to be converted into
structured data ready to be post-processed. This field is particularly focused on the retrieval of data
available over the Web, and more specifically HTML pages, to dump the information extracted into
databases and XML files. Nevertheless, tools and techniques may be applicable to any type of
source data (e.g., cvs, pdf) and output format (e.g. RDF). The application of IE techniques to
translate information into RDF is a promising mechanism to broaden the range of information
sources available to perform semantic enrichment.
We can find in the IE literature many studies introducing the wrapper as the term identifying tools
able to perform data scrapping (Chang, Kayed, Girgis, & Shaalan, 2006) (Sarawagi, 2008)
(Baumgartner, Gottlob, & Herzog, 2009) (Ferrara, Fiumara, & Baumgartner, 2011) (Fiumara,
Page 90/214
iTEC Project
17092012.Docx
2007)). The term wrapper was first proposed in the field of information integration systems (Levy,
1998), and it was defined as a program that wraps or encapsulates one or several information
sources with an abstraction layer, enabling programs accessing these sources to fetch information
without modifying their query systems. According to (Chang, Kayed, Girgis, & Shaalan, 2006), the
IE wrapper can be more appropriately defined as “the process of applying matching patterns from
a collection of extraction rules”. An alternate definition (Irmak & Suel, 2006), describes a wrapper
as “the process of extracting non-structured information from a data source to be transformed into
structured data”. To achieve this, wrappers are capable of retrieving source data to analyse it to
extract the most relevant information, provide a suitable structure to the data fetched, and integrate
it with the rest of information retrieved. Because of this, IE is also known as wrapper induction (WI)
(Kushmerick, 2000).
There are several types of wrappers. They may be classified according to the way users interact
with them. According to this classification, we can identify four different types of IE systems
(Chang, Kayed, Girgis, & Shaalan, 2006):
•
•
•
•
Manually built wrappers: Users encode a particular wrapper for each document to be
processed. In this case, general-purpose languages like JavaScript are typically used. A
deep understanding of programming techniques is required.
Supervised wrappers: Users initially provide a collection of tagged examples. Using this
information, the system is able to extract a matching pattern to be applied to the
corresponding document.
Semi-supervised wrappers: In this case, users provide a collection of initial examples that
may not be exhaustive. Then, users interact with the system, typically through a graphical
user interface (GUI) to define the extraction objectives.
Non-supervised wrappers: They are generated automatically without the need of tagged
examples or user interaction. Extraction objectives are defined by the data used to
generate the source document.
To complete the IE process in our context, namely to semantically enrich a local Knowledge Base,
and according to the scheme proposed in (Ferrara, Fiumara, & Baumgartner, 2011), five stages
have to be completed.
•
•
•
Data source analysis: Experts must identify the data sources relevant to our aims. That is,
those data sources containing information suitable to enrich the data already available in
the Knowledge Base. Once information sources have been identified, the nature of the
exposed data has to be analysed to identify access strategies (e.g., HTML, XML, relational
databases) to eventually extract the required information.
Wrapper generation: We must identify the most adequate wrapper type according to the
nature of input data. The selected wrapper should be able to retrieve data to navigate it to
locate and extract only the relevant information, discarding the rest. According to this
analysis, we may use an existing wrapper (cf., Appendix IV) or produce a custom one
suitable to our specific needs.
Automation and planning: An important characteristic of an IE system is its ability to
automatically launch a data scrapping process on several documents, that is, to support the
generation of extraction macros to be applied without direct user interaction. For example, a
web portal providing a paginated information catalogue where all pages share the same
structure, should be automatically traversed without requiring the user to provide to the
wrapper each individual page in the catalogue. Another relevant characteristic is scheduling
support. Scheduling enables wrapper configuration to be periodically applied to a given
Page 91/214
iTEC Project
•
•
17092012.Docx
data source. This is most suitable when data to be processed is likely to be regularly
updated (e.g., information repositories populated by very active communities).
Data transformation: Each IE wrapper extracts and handles information from a specific
type. As a consequence, data conversion into a standard format is a required process to
consolidate heterogeneous information into a single structure. Information obtained from
different wrappers should be converted into a common format. In our case, the selected
model is based on RDF. Besides, we need to identify or create vocabularies (i.e.,
ontologies) to define the terminology most suitable to the information gathered (e.g., to
define the name of a person we may use the property foaf:name from the FOAF
vocabulary). This way, information can be directly used to enrich our platform.
Usage of extracted data: In our case, the data obtained will be directly used to enrich the
Knowledge Base. However, we may need to apply filters on extracted data to detect
duplicate information (cf., Record Linkage, Sect. 4.2) or to discard potentially relevant
information not suitable to our needs (e.g., after extracting information on all software tools
available in a web catalogue, we may decide to keep only information completing the
technical features of the tools already present in our Knowledge Base).
Using wrappers to process data repositories is instrumental for Semantic Web automated
knowledge acquisition (Antoniou & Van Harmelen, 2004). These techniques facilitate the retrieval
of large amounts of relevant data in little time. Nevertheless, they have two important drawbacks
(Fensel, 2001)
•
•
Effort: Generating a wrapper is not a simple task. In many cases, each individual source of
information has to be carefully analysed to generate the best possible extraction patterns.
Besides, updates in the data sources’ structure or syntax imply redoing the wrapper. To
sum up, wrapper generation is a time consuming process requiring a relevant developing
effort.
Quality: Information retrieved by a wrapper depends on the extraction patterns defined. In
many cases, relevant information may be lost because it is not considered in the mapping
information. Besides, changes in the structure or minor inconsistences in the information
source that may be easily detected and handled by a human expert become important
sources of errors. Regretfully, these situations are fairly common. Thus, information
extracted by a wrapper may not be as complete as desired, extraction is error-prone, and in
most cases even slight incongruences will not be automatically detected.
To overcome these limitations, some strategies are possible:
•
•
To select the best information sources available. As relevant amounts of time and effort will
be needed to generate the wrapper, we should try to select data sources having a good
balance between the quantity of information available and its quality, that is, its relevance
and degree of detail.
To select or generate the appropriate wrapper. To optimize resources, it is convenient to
use a wrapper operating as automatically as possible. However, automated wrappers crawl
and extract fairly simple or evident information, that is, the one adapted to the pre-defined
extraction pattern. This may leave behind relevant information. In turn, a custom wrapper
maximizes the amount of retrieved information. Thus, a balance is needed between
simplicity of wrapper configuration and its adaptability to the structure of each data source.
Note that IE may also raise some legal or even moral concerns. Many web sites explicitly declare
usage restrictions applicable to the information hosted, as information extraction may compromise
authorship acknowledgement, may reduce visits and therefore revenues, and may increment data
Page 92/214
iTEC Project
17092012.Docx
traffic. These situations have been thoroughly discussed, mainly in relation to the extraction of
information from online HTML documents (Fibbe, 2004). As a consequence, tools and techniques
were developed to prevent or slow down wrappers’ crawling operations (e.g., IP blocking, captch)
Webmasters may also use the robot exclusion protocol (Koster, 2007) by identifying files and
documents that may not be crawled by automated agents, wrappers among them. In this latter
case, it is required wrappers being well behaved, as it is up to them to comply with the declared
exclusion rules. In any case, IE legal limitations are not clear, and they are not consistently applied
across the world. Motives to consider that a given IE system is operating beyond legality are based
on the type of access performed, the amounts of information extracted and, above all, the damage
caused to the information owners.
As can be inferred from the discussion above, the extraction of information and its conversion into
RDF is not a novel research field. W3C hosts a wide range of tools and frameworks to perform this
activity (W3C, 2012). These wrappers are classified according to the format of the information
source (e.g., databases, emails, weather information, spreadsheets, geolocation, Javadoc).
Besides, there are additional initiatives, like project SIMILE (Lee, 2004) (Mazzocchi, Garland, &
Lee, 2006) from MIT, which produced RDFizer (MIT, 2008) among other solutions. RDFizer is
intended to provide several RDF-generating wrappers from different source formats. From this
initiative, the term RDFizer was coined to name all wrappers generating RDF as output.
In (Chang, Kayed, Girgis, & Shaalan, 2006), information to be processed by a wrapper is classified
into structured, semi-structured and unstructured. In an enrichment system, the quality and
quantity of information retrieved is most relevant. As a consequence, documents in the first and
second group will have our primary focus. Figure 10 depicts these information types according to
their ease of processing.
Figure 10. Simplicity of information procesing w.r.t. its degree of structure
Page 93/214
iTEC Project
17092012.Docx
Appendix IV collects some of the most relevant projects related to the conversion of information
(particularly, relational databases, XML and HTML) into RDF, taking into account the specific
aspects of the SDE’s information enrichment process.
4.2. Record Linkage
The semantic enrichment process of a Knowledge Base is initiated with the retrieval of the relevant
information available in a given source and its translation into RDF. After that, we have to filter out
all information not needed to complete the records of already registered individuals. The strategy
for that is based on the automated detection of records referencing the same individual in all
sources involved (e.g., Knowledge Base, local repositories, Linked Open Data nodes).
The detection of duplicate information and the combination of data from different records
referencing the same object in the real world is not a new problem. Indeed, from the early days of
automated data processing, experts had to deal with the apparition of hard to detect duplicate
records. While small collections of data could be manually scanned to search for coincidences,
huge collections of data would require automated analysis tools. According to (Winkler W. E.,
1999), these situations began to be tackled in 1959 by Newcombe et al. for medical records
(Newcombe, Kennedy, Axford, & James, 1959). Together with census data, this was the first
context where duplicate record detection was applied.
In health care environments, the complete patient history is needed to motivate most physicists’
decisions, like providing a diagnosis or selecting prescription drugs. As a consequence, when
information is collected from different medical sources it is instrumental to collect in a single record
all data scattered from the same patient. Analogously, when handling census data, individual
citizens should be counted only once, avoiding a given user to be declared as living in two different
places at the same time, or being simultaneously dead and alive.
These techniques to combine information from several data sources to identify entities referencing
the same object in the real world are known as Record Linkage techniques (Winkler W. , 2006),
although expressions like identity resolution, duplicate detection, data cleaning, object identication,
object coreference, entity matching or entity consolidation may also be found in the literature. We
can find many references dealing with this situation (McCallum, Nigam, & Ungar, 2000) (Sarawagi
& Bhamidipaty, 2002) (Ananthakrishna, Chaudhuri, & Ganti, 2002) (Chaudhuri, Ganjam, Ganti, &
Motwani, 2003) (Li, Morie, & Roth, 2004) (Singla & Domingos, 2005). A formal definition of Record
Linkage is provided below (Köpcke & Rahm, 2009):
Definition: Given two sets of entities A є SA and B є SB of a particular semantic entity type
from data sources SA and SB, the entity matching (EM) problem is to identify all
correspondences between entities in A x B representing the same real-world object. The
definition includes the special case of finding pairs of equivalent entities within a single source
(A = B; SA = SB). The match result is typically represented either by a set of
correspondences, sometimes called a mapping, or by a set of clusters. A correspondence c =
(ei; ej; s) interrelates two entities ei and ej from sources SA and SB. An optional similarity
value s є [0; 1] indicates the similarity or strength of the correspondence between the two
objects. In the alternate result representation, a cluster contains entities that are deemed to
represent the same real-world object. Ideally all entities in a cluster refer to the same object,
and no two entities from two different clusters refer to the same object.
As a general rule, to identify two records referencing to the same object we analyse the similarities
between the properties of each entity. Analysed properties are typically text values (e.g., name,
ISBN, address, country), so in most cases syntactic analysis techniques are used to detect them.
Page 94/214
iTEC Project
17092012.Docx
These techniques try to infer if two entities are equal by studying the lexical similarity of their
properties’ values. The main problem of this approach occurs when there are different versions of
the otherwise same value. For example, a personal name may have several representations, all of
them referencing the same person (e.g., John Smith vs. J. Smith vs. Smith, John). Transcription
errors may also have been committed (e.g., Jonh Smith), or different versions of the same name
may exist (e.g., Johnny Smith). We may also find fields in different languages (e.g. Germany vs.
Alemania). As a consequence, syntactic analysis has become more and more complex, and more
and more specialized according to the type of property.
We need a suitable procedure (i.e., an algorithm) to compute de degree of similarity between two
entities. These algorithms are known as matchers, and they determine which (mainly syntactic)
techniques may be used, and how results have to be interpreted to decide if two entities are equal.
A widely used strategy is based on the combination of several matchers to compute the degree of
similarity as a weighted combination of the individual values obtained by each matcher.
These approaches require all the records to be traversed to be compared with each other. This
implies a huge computational cost for large data repositories, and therefore large response times.
To reduce response times several schemes have been proposed, the most relevant being blocking
(Bilenko, Kamath, & Mooney, 2003). With this technique, entities are grouped into blocks before
being compared, and only entities in the same block are actually analysed. Blocks will be
composed according to parameters identifying each group. For example, to compare people
records, the ones having name and address properties will be grouped together. This technique
drastically reduces response times, but some exhaustiveness is lost. For example, people whose
address is missing will not be included in the block defined above.
Record Linkage techniques are fairly relevant in the realm of the Semantic Web, as data producers
typically represent their information according to their own criteria and generating their own
references (e.g. URIs), without considering the possibility that other producers may have
generated declarations on the same objects. To somehow overcome these situations, it has been
proposed to use property owl:sameAs in Linked Data networks to indicate that two entities with
different URIs in fact represent the same object. This approach provides a link between different
data sources, facilitating information discovery and the enrichment of the knowledge exposed by a
given source.
Several Record Linkage-based frameworks, architectures and technologies have been proposed to
identify equivalent entities in different nodes (cf. Appendix V). There are two broad approaches to
this task, namely manual and automated. Manual techniques may be applied for small data sets
where experts are able to analyse each element to establish the appropriate relations. In turn, for
large data sets this technique is not applicable because it would require too much time. As a
consequence, automated solutions may be used. These approaches are based on predefined
rules to auto-generate RDF links. Record Linkage is related to these automated solutions. There
are two types:
•
Key-based solutions. To be applied to situations where records are uniquely characterized
by an identifier no matter the data set (e.g. a publication’s ISBN, a person’s social security
number). This identifier may be reflected directly at the URI or as one of its properties.
When the identifier corresponds to a property value, the property is known as an inverse
functional property, and its value uniquely identifies the object. This class of properties
provide a reliable method to detect equivalent entities. This Record Linkage mechanism
detects the key value in each record and compares it to the one in other records. If values
match, the equivalence relation is established.
Page 95/214
iTEC Project
•
17092012.Docx
Similarity-based solutions. To be applied to records not having unique identifiers. It
compares value properties in each entity to detect its degree of similarity. The similarity
value obtained is checked again a predefined threshold value; if the threshold is exceeded,
the algorithm indicates that both records reference the same object in the real world. Two
threshold values are proposed in the literature (Bilenko & Mooney, 2003) namely Tmanual
and Tauto to assess the degree of similarity Sim :
< Tmanual
, Entities are different
Sim
Tmanual < Sim < Tauto , An expert has to be consulted
Tauto < Sim
, Entities are equal
There are several tools that support the definition of relations to be established, matchings to be
applied, and their respective weights, typically using a declarative language. These are semiautomated tools, as they require the active participation of an expert to generate the so-called
linkage rules (Isele & Bizer, 2011). Among these tools we find SILK (Volz, Bizer, Gaedke, &
Kobilarov, 2009) and LIMES (Zhou & Li, 2010).
Other tools are based on using data already available to infer matching heuristics. These tools
extract from existing relations between data elements the needed degree of similarity for two
entities to be considered equivalent, together with the most representative properties to assess
equivalence, the matchings, and the corresponding weights. These tools are fully automated, but
the results obtained use to be worse when compared to the ones obtained with semi-automated
tools. Among these tools we find ObjectCoref (Hu, Chen, Cheng, & Qu, 2010) and idMesh (CudréMauroux, Haghani, & Jost, 2009).
(Ngomo A.-C. N., 2011) discusses these tools as Link Discovery Frameworks (LD Frameworks),
classifying them as universal or domain-specific. Universal LD Frameworks are applicable to any
semantic record independently of the domain (e.g., SILK, LIMES). On the other side, domainspecific LD Frameworks are targeted to specific domain (e.g., GNAT (Raimond, Sutton, & Sandler,
2008), LMD (Ngomo, Lehmann, Auer, & Höffner, 2011).). The latter, according to our specific
objectives, will be considered as enrichment experiences more than as actual tools.
To gain further insight into the operation and characteristics of these tools please refer to Appendix
V, which collects the most relevant frameworks in this field.
4.3. Experiments performed
This section discusses some of the experiments performed to assess the feasibility of obtaining
information from external sources to enrich the information available internally about the resources
that can be used to implement a Learning Story. Specifically, we will describe some experiments
performed to obtain information about tools, one of the four types of resources considered in iTEC.
To perform the enrichment of the information stored in the Knowledge Base, we need to locate
data sources relevant to complement the information already there. These sources may provide
their information either semantically (i.e., as RDF data or according to any other language in the
field of Knowledge Representation) or non-semantically (e.g., XML, HTML, RSS). As pointed out
above, for the sake of access and processing simplicity, it is desirable to use sources providing
information semantically. Nevertheless, there are many sources with useful information available
over the Web that is not published semantically. As a consequence, we will also consider access
Page 96/214
iTEC Project
17092012.Docx
to these sources. When addressing non-semantic sources, we will select those providing
information as structured as possible.
Section 4.3.2 briefly discusses experiences performed to fetch information on tools from Web
sources. Previously, in Sect. 4.3.1, we will enumerate some generic semantic information sources
that are recurrently used in these kind of experiments, and that may be relevant not only to
complete information on tools, but also for people, events, and educational content, that is, the
other three types of resources considered by iTEC.
4.3.1. Some generic enrichment sources
In this section we introduce some of the most relevant generic and multidisciplinary data sources in
the LOD network. These sources host information from diverse fields, and as a consequence they
serve as LOD hubs. In other words, many LOD repositories establish links with these
multidisciplinary sources to interconnect all the information they host. Because of that,
multidisciplinary sources are most relevant to automatically enrich any type of resource in any field.
We also include here data sources related to two types of applications that, while not strictly data
repositories, are very interesting for our enrichment objectives. These are semantic search engines
and sameAs.org. These sources directly and easily provide access to interesting semantic
information on any type of resource.
Multidisciplinary LOD nodes
•
•
•
DBPedia (Bizer, et al., 2009) is an initiative targeted to extract structured information from
Wikipedia to be published at the LOD network. Wikipedia is a free web encyclopedia,
collaboratively generated by thousands of producers. It has become one of the most
updated, largest and multidomain repositories that may be consulted today. Having
Wikipedia as its source makes DBPedia a multidisciplinary, regularly updated repository
containing millions of RDF information triples. Because of that, DBPedia will be a common
source for all our information insertion processes involving our Knowledge Base. We can
find in DBPedia large amounts of interesting information to complement our Knowledge
Base. For example, there are detailed records on many tools, features, people, locations,
etc. DBPedia follows all Linked Open Data provisions, which means that, besides offering a
URI to access the record, it provides a SPARQL Endpoint to perform SPARQL queries.
This access method greatly facilitates exploration and retrieval tasks.
Factforge (Bishop, Kiryakov, Ognyano, Peikov, Tashev, & Velkov, 2009) is a public and
free service offering consumers a simple entry point to Linked Data. Factforge represents
the aggregation of several datasets that have been partially refined according to several
criteria (e.g., reasonability). Independent datasets available in Factforge are DBPedia,
Freebase, Geonames, UMBEL, Wordnet, CIA World Factbook, Lingvoj and MusicBrainz.
This combination of independent datasets is known as Reason-Able View (RAV), and may
be used as a single body of knowledge, as an aggregated dataset for reasoning and query
evaluation. Thus, Factforge is an excellent solution to perform experiments encompassing
several sources that do not completely replace experiments performed on specific
repositories.
Freebase (Bollacker, Evans, Paritosh, Sturge, & Taylor, 2008) is a huge knowledge base
that has been collaboratively created, maintained and structured. The user community may
register structured information from any field, in a way similar to a wiki. Thus, it is a
multidisciplinary repository similar to DBPedia. Although Freebase gets information from
the harvesting of several sources, the community contributions to the wiki are its main
Page 97/214
iTEC Project
17092012.Docx
source of information. This information may be retrieved in RDF but, unfortunately, it does
not offer a SPARQL Endpoint to perform semantic queries. In turn, and besides its
graphical user interface, it offers proprietary APIs to consult concepts using keywords, and
even to perform complex queries using MQL (Metaweb Query Language), specific to
Freebase. The results obtained through these APIs are delivered in JSON format. This
rather closed solution offered by Freebase requires the development of specific wrapping
solutions. On the other side, these APIs limit access to 100 thousand queries per day per
user. To overcome these access limitations, Frebase allows downloading its data dumps
(i.e., copies of its database records) for individual users to install them locally to be
managed at will. However, due to the huge amounts of information available, this solution
requires powerful machines. Besides, data dumps should be periodically downloaded to
guarantee that information is always updated.
Semantic search engines
As it happened with the traditional Web, the decentralized nature of Web 3.0 is one of its main
advantages, but also it is one of the main drawbacks that developers of Semantic Web agents
have to deal with. Decentralization hinders the location of information relevant to the agent.
To overcome this situation, search engines on Semantic Web resources have been developed.
These tools support queries in a way similar to that of typical search engines like Google.
However, in this case results will be composed of semantic documents retrieved from the Web of
Data. As a consequence, this type of search engines is typically targeted to domain experts and
software agents, and not to the general public.
These search engines support general queries on different types of objects to retrieve information
from diverse semantic sources. This approach provides a unique searching facility for the
Semantic Web, and facilitates the retrieval of information from repositories initially not considered.
The main issue is to take apart from retrieved results those that are indeed relevant to our
objectives (e.g., when searching for term Apple we have to separate results referring to the fruit
from those referring to the technological company).
In our case, the availability of a semantic search engine enables direct queries about the
information we want to enrich. For example, if we want to obtain information about an expert
named Víctor M. Alonso Rorís we may perform a Record Linkage process on some preestablished semantic repositories. Obviously, this process will not guarantee a match, even when
LOD contains relevant information. In turn, if we search this name using one of those search
engines, they will probably return some results automatically. On the other side, the documents
retrieved may also include non-relevant documents. Most popular semantic search engines are:
•
•
Sindice (Tummarello, Delbru, & Oren, 2007) crawls the Web to fetch and analyse semantic
information to construct and index including the resources retrieved from each source,
according to a methodology similar to the one used by Google. Sindice retrieves
documents from the Semantic Web and indexes them according to their URIs, their inverse
functional properties (IFP), and keywords. The system supports queries according to these
three parameters. When Sindice receives a query, it returns a list of results sorted
according to their general relevance. These results are composed of the derreferentiable
URI of each resource. Sindice supports queries through a Web graphical user interface and
through an API. API queries are performed as HTTP queries with parameters encoded in
the URL. Results can be obtained in several formats like RDF, JSON or ATOM.
Watson (d’Aquin, et al., 2007; d’Aquin & Motta, 2011) is a search engine that traverses the
Web of Data using a collection of crawlers to analyse the information obtained to construct
Page 98/214
iTEC Project
•
•
•
•
17092012.Docx
an index. Watson supports queries on diverse fields, like URIs, retrieved ontologies,
keywords or extracted metadata. For that, Watson supports several access mechanisms,
including a SPARQL Endpoint, a Web user interface, and API access points with REST and
SOAP versions.
SWSE (Harth, Hogan, Delbru, Umbrich, O’Riain, & Decker, 2007) also indexes RDF
information from Linked Data using crawlers, although the information in its knowledge
base also comes from XML sources, from large static datasets, and even from live sources.
This is achieved through a hybrid data integration solution to obtain a huge RDF graph
including all entity descriptions and their relations. This search engine is specifically
targeted to the human user, as its interface supports navigation across links in entities and
to refine queries adding new search parameters or selecting the type of entity seeked.
Indeed, its creators decided not to implement any other access method besides the web
interface. In our case, as we intend to perform semantic searches using automated
software agents, this feature is a major handicap that makes this browser not so interesting
to us as others described here.
Swoogle (Ding, et al., 2004) is a semantic search engine that crawls the web for RDF or
OWL documents to extract metadata and relations in them. These documents are indexed
according to the information extracted. This way, queries are supported based on keywords
or URIs. The system also computes a ranking from the retrieved documents according to
the documents’ Semantic Web relevance. It provides a web interface and also an HTTP
API returning results in RDF. API query parameters are encoded in the URL, and it
supports 19 types of queries including RDF terms, documents and ontologies.
Falcons (Cheng & Qu, 2009) is a key-based search engine for linked objects in the Web of
Data. Falcons constructs a virtual document containing literals and textual descriptions from
links and objects linked to each retrieved document. This way, it supports several types of
key-based queries for each object. These virtual documents are classified according to a
ranking that takes into account both relevance and popularity. For each retrieved object, the
user is provided with the object’s URI and a query structure containing associated literals
and related objects. Objects may be RDF documents, concepts or ontologies. Falcons
provides a RESTFUL API to allow software agents to access its query services. Using this
API, agents may perform specific searches on classes, properties, documents and general
objects. Results are encoded in RDF.
Knowledge Graph (Singhal, 2012) is a proprietary knowledge base used by Google to
enrich and improve the results of its search engine. This graph is constructed by crawling
semantic sources like DBPedia, Freebase or CIA World Factbook. Presently it hosts more
than 500 million objects and 3,500 million triples. This addon to the standard Google search
engine supports 1) to perform more exact searches by enabling users to graphically
differenciate the type of resource sought (e.g., when searching for Apple, the interface asks
if the query refers to the fruit or the technological company); 2) to provide a precise
summary of the results obtained including relevant information about facts and other data
about the searched concept, making it unnecessary to gather this information from the
pages themselves (e.g., when searching for Tim Berners-Lee, the system will return,
besides the relevant pages, a summary with information on the biography and curriculum
vitae of that person); 3) to enrich results with additional information directly extracted from
Knowledge Graph. Knowledge Graph has been announced in May 2012, and at the time of
this writing it was in testing phase for queries performed from US, so it is not publicly
accessible yet. Nevertheless, taking into account the present Google infrastructure, this
knowledge base may be freely available through a semantic search engine soon, and it
may become a reference in this field in the near future.
Page 99/214
iTEC Project
17092012.Docx
sameAs.org
SameAs.org (Glaser, Jaffri, & Millard, 2009) is a service to support users, either human or software
agents, to find URIs co-referenced to an additional URI passed as a parameter, that is, URIs
identifying semantic descriptions of the same real-world object as the one referenced by the first
URI. SameAs also supports keyword-based serchs of URIs in RDF records through Sindice. Once
the URIs are retrieved, SameAs.org provides a list including all co-referenced URIs.
This service is offered in two flavors: 1) through a simple web form targeted to human users and 2)
through HTTP requests with URL-encoded parameters. The responses to HTTP queries may be
retrieved in several formats, namely HTML, RDF (RDF+XML), N3 (text/n3), JSON
(application/json) and plain text (text/plain).
Presently, sameAs.org uses several reliable sources like DBPedia or Semantic Web Dog Food. In
many cases, RDF dumps or SPARQL Endpoints in these repositories were used to fetch
information. Note that the reliability of the data sources was introduced as a design premise, that
is, information is not fetched by crawling the complete Semantic Web (i.e., like standard semantic
search engines) to avoid wrongly co-referenced URIs due to erroneous or inexact information.
Presently, sameAS hosts co-reference information for 115 million URIs.
In our case, we can use sameAs.org to find additional co-referenced records without applying
Record Linkage tools. This way, we are provided with a simple method to find new external records
to enrich the records in our Knowledge Base. The major drawback of this service is the reduced
number of URIs hosted by sameAs due to the limited number of trusted sources. However, this
limitation is also a guarantee of the reliability of the retrieved URIs.
4.3.2. Tool Enrichment Experiments
This section presents the main results of some preliminary experiments with the enrichments
techniques described above. For these experiments we focused on Tools, as these are the
recommendations that will be first integrated in the Composer in the third year of the project.
Class Tool collects one of the main resource types stored in the SDE’s Knowledge Base. Entities
in this class are software or hardware tools that may be used in a learning environment. Please
refer to the corresponding section for a description of the this object data model (cf. Figure 11).
This data model defines the basic properties describing a Tool insofar the SDE is concerned.
Therefore, this will be the context that we will try to enrich for each Tool instance in the Knowledge
Base. Among all properties in the data model, some of them are instrumental for the appropriate
working of the SDE’s inference and reasoning processes. We will focus our enrichment efforts on
some of these properties, particularly, on the properties collected in Table 83.
Table 83. Tools’ key concepts for enrichment
Concept
Comments
Functionality
Title
Operating
System
Basic parameters to support tool’s location and recommendations.
Names of tools are instrumental to identify them.
For software tools, information on supported operating systems will
facilitate the filtering of results.
Page 100/214
iTEC Project
Tags
Related Tools
Community
Assessment
17092012.Docx
Keywords related to tools will be used to refine the inference and
reasoning processes on them.
If we can extract knowledge about related tools, we can use this
information to foster and provide new dimensions to the reasoning and
inference proceses.
The web hosts reusable information on tool assessment freely provided by
community members. This information may enrich and provide additional
dimensions to the inference and reasoning processes.
Figure 11. Tool data model
We will discuss in this section some basic experiments to assess the benefits of enrichment in
terms of information retrieved. To perform these experiments we populated our Knowledge Base
with a small collection of 10 tools (cf. Table 84):
Table 84. Tool collection in our knowledge base for enriching experiments.
Tool
Skype
Adobe Photoshop
Geogebra
Internet Explorer
Microsoft PowerPoint
Google Talk
WordPress
Wikipedia
Open Office
Picasa
Description
Popular videoconferencing application
Tool to edit, modify and manage large collections of digital images
E-learning applications for Math
Web browser
Presentation creation, visualization and management tool
Chat service
Blogging service
Online collaborative encyclopedia
Free office package
Image management tool
Page 101/214
iTEC Project
17092012.Docx
We describe the experiments on several information sources, both semantic and non-semantic.
Experiments on semantic sources
• DBPedia
Among the huge amount of pieces of information collected, DBPedia keeps detailed records on
tools relevant to education. RDF triples defining tool properties include its name, description,
17
functionality, license, language, etc. As an example, Figure 12 collects an excerpt of Skype’s
RDF descriptive document in DBPedia. This information may be easily consulted and retrieved
thanks to the SPARQL Endpoint18 provided by this repository.
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:dbpedia-owl="http://dbpedia.org/ontology/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:dbpprop="http://dbpedia.org/property/" >
<rdf:Description rdf:about="http://dbpedia.org/resource/Skype">
<rdf:type rdf:resource="http://dbpedia.org/ontology/Work" />
<rdf:type rdf:resource="http://dbpedia.org/ontology/Software" />
<rdf:type rdf:resource="http://schema.org/CreativeWork" />
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Thing" />
<rdf:type rdf:resource="http://umbel.org/umbel/rc/SoftwareObject" />
<rdf:type rdf:resource="http://dbpedia.org/class/yago/VoIPCompanies" />
<rdf:type rdf:resource="http://dbpedia.org/class/yago/Software106566077" />
<owl:sameAs rdf:resource="http://dbpedia.org/resource/Skype" />
<owl:sameAs rdf:resource="http://rdf.freebase.com/ns/m/026wfg" />
...
<rdfs:comment xml:lang="en">Skype is a software application ...</rdfs:comment>
<rdfs:label xml:lang="en">Skype</rdfs:label>
<foaf:name xml:lang="en">Skype</foaf:name>
<dbpedia-owl:abstract xml:lang="en">Skype is...</dbpedia-owl:abstract>
<dbpedia-owl:language rdf:resource="http://dbpedia.org/resource/Multilingualism" />
<dbpedia-owl:genre rdf:resource="http://dbpedia.org/resource/Instant_messaging" />
<dbpedia-owl:genre
rdf:resource="http://dbpedia.org/resource/Voice_over_Internet_Protocol" />
<dbpedia-owl:genre rdf:resource="http://dbpedia.org/resource/Videoconferencing" />
<dbpedia-owl:frequentlyUpdated xml:lang="en">yes</dbpedia-owl:frequentlyUpdated>
...
<dbpprop:language rdf:resource="http://dbpedia.org/resource/Multilingualism" />
<dbpprop:name xml:lang="en">Skype</dbpprop:name>
<dbpprop:genre rdf:resource="http://dbpedia.org/resource/Videoconferencing" />
<dbpprop:genre
rdf:resource="http://dbpedia.org/resource/Voice_over_Internet_Protocol" />
<dbpprop:genre rdf:resource="http://dbpedia.org/resource/Instant_messaging" />
<dbpprop:developer rdf:resource="http://dbpedia.org/resource/Skype_Limited" />
...
<rdf:Description rdf:about="http://mpii.de/yago/resource/Skype">
<owl:sameAs rdf:resource="http://dbpedia.org/resource/Skype" />
</rdf:Description>
</rdf:RDF>
Figure 12. Excerpt of the RDF document retrieved from DBPedia about Skype. Extracted from
http://dbpedia.org
17
http://dbpedia.org/resource/Skype
18
http://dbpedia.org/sparql
Page 102/214
iTEC Project
17092012.Docx
Obviously, this information is potentially useful to enrich the SDE Knowledge Base. To obtain an
initial estimation on the amount of tool descriptions in DBPedia that might be relevant to the SDE,
several queries were launched to its SPARQL Endpoint. These queries were targeted to discover
the number of tools in DBPedia offering some of the functionalities collected in the iTEC
functionality vocabulary. For example, to retrieve the number of instant messaging tools available
in DBPedia, we launched the query in Figure 13. Table 85 collects the results obtained for several
functionalities.
PREFIX dbpedia-owl: <http://dbpedia.org/ontology/>
SELECT DISTINCT ?tool_uri
WHERE {
?tool_uri dbpedia-owl:genre <http://dbpedia.org/resource/Instant_messaging>
}
Figure 13. SPARQL query to retrieve tools with functionality instant messaging
Table 85. Number of tools retrieved from DBPedia for some of the functionalities relevant to the SDE
ITEC functionality
Related DBPedia URI
instant messaging client
Email
Wiki
web browser
image editor
word processor
http://dbpedia.org/page/Instant_messaging
http://dbpedia.org/page/Email
http://dbpedia.org/page/Wiki_software
http://dbpedia.org/page/Web_browser
http://dbpedia.org/page/Graphics_software
http://dbpedia.org/page/Word_processor
No. of instances in
DBPedia
80
14
16
95
22
46
Once the potential of the information on tools collected by DBPedia had been assessed, we tried to
automatically identify the DBPedia records corresponding to the tools included in the Knowledge
Base to perform our experiments (cf. Table 84). For that, we used the Record Linkage tool SILK
(cf. section 6.2.1) to access the DBPedia SPARQL Endpoint. The corresponding SILK
configuration file is depicted in Figure 14. This process was organised according to the parameters
below:
•
•
•
•
We would compare records from classes in DBPedia typically used to identify software
applications (e.g., dbpedia-owl:Software) with records itec:Tool in our KB. This restriction
affecting the DBPedia classes analysed is due to the huge size of the original repository,
which makes computationaly unfeasible to analyse the complete DBPedia using SILK.
Comparison would be performed between properties dct:title and rdfs:label in our records
and in DBPedia records, according to the Jaro metrics (Jaro, 1995).
Record pairs with a similarity value over 0.95 would be considered equivalent and would be
stored in a specific file.
Record pairs with a similarity value over 0.91 and below 0.95 would be considered as
potentially equivalent and would be stored in a specific file to be revised by an expert.
<?xml version="1.0" encoding="utf-8" ?>
<Silk>
<Prefixes>
<Prefix id="owl" namespace="http://www.w3.org/2002/07/owl#" />
<Prefix id="rdf" namespace="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<Prefix id="rdfs" namespace="http://www.w3.org/2000/01/rdf-schema#" />
<Prefix id="dct" namespace="http://purl.org/dc/terms/" />
<Prefix id="dbpedia-owl" namespace="http://dbpedia.org/ontology/" />
<Prefix id="schema" namespace="http://schema.org/" />
<Prefix id="yago" namespace="http://dbpedia.org/class/Yago/" />
<Prefix id="itec" namespace="http://itec/ontology/itec.rdf#" />
</Prefixes>
<DataSources>
Page 103/214
iTEC Project
17092012.Docx
<DataSource id="prop" type="sparqlEndpoint">
<Param name="endpointURI" value="http://itec-repo.com/sparql" />
<Param name="graph" value="itec/tool" />
</DataSource>
<DataSource id="exp" type="sparqlEndpoint">
<Param name="endpointURI" value="http://dbpedia.org/sparql" />
</DataSource>
</DataSources>
<Interlinks>
<Interlink id="eq">
<LinkType>owl:sameAs</LinkType>
<SourceDataset dataSource="prop" var="a">
<RestrictTo>
?a rdf:type itec:Tool
</RestrictTo>
</SourceDataset>
<TargetDataset dataSource="exp" var="b">
<RestrictTo>
{?b rdf:type dbpedia-owl:Software}
UNION {?b rdf:type dbpedia-owl:Website}
UNION {?b rdf:type schema:CreativeWork}
UNION {?b rdf:type yago:OpenContentProjects}
UNION {?b rdf:type dbpedia-owl:Work}
UNION {?b rdf:type yago:CollaborativeProjects}
</RestrictTo>
</TargetDataset>
<LinkageRule>
<Aggregate type="max">
<Compare metric="jaro">
<Input path="?a/dct:title" />
<Input path="?b/rdfs:label" />
</Compare>
</Aggregate>
</LinkageRule>
<Filter threshold="0.91" limit="1" />
<Outputs>
<Output minConfidence="0.95" type="file">
<Param name="file" value "out/tools-dbpedia.xml"/>
<Param name="format" value="ntriples"/>
</Output>
<Output maxConfidence="0.95" type="file">
<Param name="file" value="out/tools-dbpedia-rev.xml"/>
<Param name="format" value="alignment"/>
</Output>
</Outputs>
</Interlink>
</Interlinks>
</Silk>
Figure 14. SILK configuration file to compare software tools in DBPedia and iTEC
After running SILK using the configuration file above, we obtained direct co-references for 9 out of
the 10 tools in our KB, and we got no result to be further revised by an expert. Obtained results are
collected in Table 86. As can be observed from the fetched URIs, all matchings are correct, that is,
records located in DBPdia do correspond to tools in our KB. The only tool that SILK was unable to
link to a record in DBPdia was Open Office. The most likely reason for that is the name selected to
identify this tool in DBPedia, “OpenOffice.org”. SILK returns a similarity value of 0.58 when
compared to “Open Office”, well below the predefined threshold. This fact suggests that we may
revise SILK configuration to introduce a larger number of comparison parameters to avoid these
situations when trying to detect equivalent entities.
Each of the linked DBPedia records includes different types of information. Nevertheless, after
analysing the retrieved records we observed that it is possible to retrieve information for most of
the properties relevant to iTEC (cf.Table 87).
Page 104/214
iTEC Project
17092012.Docx
Table 86. Record Linkage on DBPedia experiment results
Tool in KB
Skype
Adobe
Photoshop
Geogebra
Internet
Explorer
Microsoft
PowerPoint
Google Talk
WordPress
Wikipedia
Open Office
Picasa
DBPedia URI
http://dbpedia.org/resource/Adobe_Photoshop
Correct linkage
YES
YES
http://dbpedia.org/resource/GeoGebra
http://dbpedia.org/resource/Internet_Explorer
YES
YES
http://dbpedia.org/resource/Microsoft_PowerPoint
YES
http://dbpedia.org/resource/Google_Talk
http://dbpedia.org/resource/WordPress
http://dbpedia.org/resource/Wikipedia
http://dbpedia.org/resource/Picasa
YES
YES
YES
YES
Table 87. DBPedia’s Record Linkage experiment results
Concept
Functionality
DBPedia results
All software tools include information about their functionality through
property dbpedia-owl:genre.
All software tools provide information on their name through property
rdfs:label.
Tools running on top of an Operating System provide information about
OS compatibility through property dbpprop:operatingSystem.
Tools don’t have a specific field for tags. However, values in some
properties may be used as keywords (e.g., property dcterms:subject).
There is no explicit field available to directly identify related tools.
There is no property with this purpose.
Title
Operating
System
Tags
Related Tools
Community
Assessment
• FactForge
We also performed the DBPedia Record Linkage experiment on the FactForge multidisciplinary
repository. For that, we used SILK configured as before (we just replaced the DBPedia dataset by
FactForge). In this case we obtained direct co-references for 5 out of the 10 tools in the KB, and
we retrieved no results to be revised by an expert. Results obtained are collected in Table 88.
Table 88. FactForge’s Record Linkage experiment results
Tool in KB
Factforge URI
Skype
Adobe Photoshop
Geogebra
Internet
Explorer
Microsoft
PowerPoint
Google Talk
WordPress
Wikipedia
Open Office
Picasa
http://dbpedia.org/resource/Adobe_Photoshop
http://dbpedia.org/resource/Internet_Explore
r
http://dbpedia.org/resource/WordPress
http://dbpedia.org/resource/Wikipedia
-
Correct
linkage
YES
YES
YES
YES
YES
-
As can be seen Table 88, the 5 linkage results fetched belong to the DBPedia dataset. Note that
results are more satisfactory (i.e., more tools fetched) when linkage was directly performed on
DBPedia. This confirms the statement in Sect. 4.3.1 where we pointed out that FactForge provides
Page 105/214
iTEC Project
17092012.Docx
a rapid and convenient solution to access several datasets at the same time, but it would be more
efficient to retrieve information directly from the original repositories.
• Sindice
For this experiment, we used the Sindice semantic search engine, which provides an API that can
be accessed through HTTP queries. This API is fairly complete and easy to use. One of the
Sindice’s main features is its support to keyword-based queries. For that, its API supports the
query URL to include some parameters to define and filter search results. We used this feature to
perform queries using the names of the tools in our KB as search keywords to fetch related or coreferenced resources. Besides, we configured our query to obtain only results expressed in RDF,
and JSON-encoded responses. For example, the URL query constructed for tool Skype was:
http://api.sindice.com/v3/search?q=Skype&fq=format:RDF&format=json
Sindice returns a document in the specified format including an enumeration of items (i.e., entries)
sorted according to their relevance. Figure 15 collects an excerpt of the document returned for
Skype. We can see there a collection of metadata about the query performed (e.g., totalResults,
autor, title) together with the entries found. Each of these items is composed of a collection of
information fields including an URI to the external record matching the search parameters.
{
"totalResults":7282,
"author":"Sindice.com",
"title":"Sindice search: Skype format:RDF",
"itemsPerPage":10,
"startIndex":0,
"updated":"2012/06/07/ 11:27:52 +0100",
"search":"http://www.sindice.com/opensearch.xml",
"base":"http://api.sindice.com/v3/search?q=Skype&fq=format%3ARDF&format=json",
...
"entries":[{
"link":"http://www.skype-record.com/skype-record.xml",
"cache":"http://api.sindice.com/v3/cache?field=explicit_content&
output=json&url=http%3A%2F%2Fwww.skype-record.com%2F
skype-record.xml",
"updated":"2011/04/28",
"formats":["RDF"],
"title":[{
"type":"uri",
"value":"http://www.skype-record.com/skype-record.xml"
}],
"rank":1,
"explicit_content_size":"387",
"explicit_content_length":"49976"
},{
"link":"http://dbpedia.org/resource/SKYPE",
"cache":"http://api.sindice.com/v3/cache?field=explicit_content&
output=json&url=http%3A%2F%2Fdbpedia.org%2Fresource%2FSKYPE",
"updated":"2010/06/29",
"formats":["RDF"],
"title":[{
"type":"literal",
"value":"SKYPE"
}],
"rank":2,
"explicit_content_size":"6",
"explicit_content_length":"688"
},{
...
}],
"query":{
"startIndex":0,
"role":"request",
"searchTerms":"Skype format:RDF",
Page 106/214
iTEC Project
17092012.Docx
"responseTime":98
}
}
Figure 15. Excerpt of Sindice’s JSON response to a query on "Skype". Extracted from
http://sindice.com
Results obtained for the 10 tools in our KB are collected in the table below. For each tool we
provide the number of items returned and an analysis of the first 10 items fetched (i.e., the most
relevant according to Sindice):
Table 89. Results about searches on Sindice experiment
Tool in KB
Nº of
results
Skype
7282
Adobe
Photoshop
7627
Geogebra
65
Internet
Explorer
4846
Microsoft
Power
Point
2182
Google
Talk
6034
WordPress
21151
Wikipedia
369609
Open
Office
1184
Nº of valid URIs for the first 10 results
• 1 Record on the tool (DBPedia description).
• 1 Record on the tool as information category in
DBPedia.
• 2 Records on related tools (Skype Recorder, IM+,
etc.).
• 5 Records on documents and papers about the tool.
• 1 Record on tool images.
• 6 Records on related tools (Adobe Photoshop Elements,
Adobe Photoshop Album, etc.).
• 2 Records on tool’s user manuals.
• 1 Record on tool images.
• 5 Records on documents and papers about the tool.
• 3 RSS Records(invalid).
• 6 Records on related tools (Internet Explorer for Mac,
Internet Explorer Mobile, etc.).
• 2 Records on documents about the tool.
• 1 invalid Record.
• 1 Record on related tools (Microsoft PowerPoint
Viewer).
• 6 Records on documents and usage examples about the
tool.
• 2 invalid Records.
• 2 Records on the tool.
• 5 Records on documents and usage examples about
tool.
• 3 Records on the tool.
tool.
• 2 Records on related tools (OpenOffice-Base
Resource Kit).
tool.
Page 107/214
the
the
and
the
iTEC Project
Picasa
869
• 4 invalid
• 4 Records
• 4 Records
tool.
• 2 invalid
17092012.Docx
Records.
on the tool.
on documents and usage examples about the
Records.
The results from this experiment allow us to infer that most retrieved records from a semantic
search engine like Sindice are not directly suitable for enrichment, even when they direcly
reference the desired element (e.g., tool documentation), as they do not provide any description
about the tool’s functionalities or properties. Nevertheless, some useful records are typically
provided that can be instantaneously obtained (e.g., DBPedia records about each tool).
• sameAs.org
As discussed in Sect. 4.3.1, the sameAs.org service may be used to directly fetch from an entity’s
URI other URIs directly referencing the same entity. Thus, this service can be used to discover
relevant information about a resource available in other semantic repositories that may be
unknown or initially not considered.
For this experiment, we used the URIs retrieved in the DBPedia experiment. As assessed there,
these URIs effectively reference DBPedia records of the tools stored in our local KB. Using
SameAs.org, we tried to obtain additional co-referenced URIs. To achieve this goal, we utilized the
service API through a Java script that would perform the corresponding queries and retrieve the
results.
We got as a result a large list of new URIs referencing each of the target tools. In many cases,
retrieved URIs reference the same repository. For example, we got 50 URIs for Skype (cf. Figure
16). Note that the first 21 URIs are variants of the same DBPedia record, the next 21 correspond to
the dbpedialite repository, next 2 to Yago, and last 6 to Freebase.
1.http://dbpedia.org/resource/SKYPE
2.http://dbpedia.org/resource/Skype
3.http://dbpedia.org/resource/SkypeIn
4.http://dbpedia.org/resource/SkypeMe
5.http://dbpedia.org/resource/Skypein
6.http://dbpedia.org/resource/SkypeOut
7.http://dbpedia.org/resource/Skype_In
8.http://dbpedia.org/resource/Skype_in
9.http://dbpedia.org/resource/Skypeout
10.http://dbpedia.org/resource/Spypeout
11.http://dbpedia.org/resource/Skype4com
12.http://dbpedia.org/resource/Skype_Out
13.http://dbpedia.org/resource/Skype_out
14.http://dbpedia.org/resource/Skype_pro
15.http://dbpedia.org/resource/0000123456
16.http://dbpedia.org/resource/Skype_Lite
17.http://dbpedia.org/resource/000-012-3456
18.http://dbpedia.org/resource/Skypecasting
19.http://dbpedia.org/resource/Skype4com.dll
20.http://dbpedia.org/resource/Josh_Silverman
21.http://dbpedia.org/resource/The_Skype_Guys
22.http://dbpedialite.org/things/424589#id
Page 108/214
iTEC Project
17092012.Docx
43.http://mpii.de/yago/resource/Skype
44.http://mpii.de/yago/resource/Skypecasting
45.http://rdf.freebase.com/ns/en.skype
46.http://rdf.freebase.com/ns/m.026wfg
47.http://rdf.freebase.com/ns/m.0fr8ps
48.http://rdf.freebase.com/ns/en.skypecasting
49.http://rdf.freebase.com/ns/guid.9202a8c04000641f8000000000236dae
50.http://rdf.freebase.com/ns/guid.9202a8c04000641f8000000000dba2b8
Figure 16. sameAs.org’s experiment results for tool Skype
Table 90. sameAs.org’s experiment results for all tools in the KB
Tool in KB
Skype
DBPedia URI
Adobe
Photoshop
http://dbpedia.org/resource/Adobe
_Photoshop
Geogebra
http://dbpedia.org/resource/GeoGe
bra
Internet
Explorer
http://dbpedia.org/resource/Inter
net_Explorer
Microsoft
PowerPoint
http://dbpedia.org/resource/Micro
soft_PowerPoint
Google
Talk
http://dbpedia.org/resource/Googl
e_Talk
WordPress
http://dbpedia.org/resource/WordP
ress
Page 109/214
50
89
11
84
66
63
24
-
No of co-referenced URIs
URIs from:
dbpedia
freebase
dbpedialite.org
yago
URIs from:
dbpedia
dbpedialite.org
opencyc.org
freebase
umbel.org
yago
URIs from:
dbpedia
dbpedialite.org
freebase
umbel.org
yago
URIs from:
dbpedia
dbpedialite.org
freebase
opencyc.org
umbel.org
yago
URIs from:
dbpedia
dbpedialite.org
freebase
opencyc.org
umbel.org
yago
URIs from:
dbpedia
dbpedialite.org
freebase
yago
URIs from:
dbpedia
iTEC Project
Wikipedia
http://dbpedia.org/resource/Wikip
edia
Picasa
http://dbpedia.org/resource/Picas
a
17092012.Docx
- dbpedialite.org
- freebase
- yago
8 URIs from:
- dbpedia
- dbpedialite.org
- data.nytimes.com
- freebase
- yago
36 URIs from:
- dbpedia
- dbpedialite.org
- freebase
- yago
Experiments on non-semantic sources
It is fairly easy to find over the Web specialized portals, wikis, blogs or pages defining the features
of diverse software tools. To adequately perform the enrichment of our Knowledge Base using
these non-semantic repositories we have to select the most complete and easily accessible
sources of information. It is more convenient to develop a specific wrapper for a web catalogue
hosting hundreds of tools than to devote the same effort to fetch information from a page including
information from a single tool.
• Softonic
Softonic (Intershare, 2012) is a private initiative offering a huge online catalogue of software
applications. Presently, this catalogue hosts more than 100,000 programs, all of them categorized
according to their functionality. Tool descriptions include functionalities, technical capabilities, and
the perception of both the community and the catalogue’s editor about each tool. This portal is
available in more than ten languages, and programs catalogued may be run on Windows, Mac OS,
Linux and mobile platforms.
Information available on each tool is extense and detailed. Among the fields available we have:
title, short_description, license, language, img, os_compatible, author, rating_softonic, rating_user,
related_program, etc. Most of these data elements are potentially relevant to enrich our Knowledge
Base.
Softonic provides access to its catalog through an HTTP API. Responses to HTTP requests are
XML-encoded according to a custom structure defined at the portal. This API can be accessed
upon user registration. This way, Softonic can control information retrieval to deny access to users
not conforming to its usage rules. The API provides access to all the information hosted in that
portal.
Using this API, a wrapper can be developed to extract the most relevant information to enrich our
software tools. For that we need to define an XML2RDF mapping for each of the responses
obtained along the retrieval process.
We defined an experiment to see whether it is possible to fetch information in a simple and efficient
way. For this experiment, we launched several chained requests to fetch the number of tools
available in each category, as outlined in Figure 17. The encoded algorithm uses the API methods
below:
Page 110/214
iTEC Project
•
•
•
17092012.Docx
getPlatforms: To fetch the platforms supporting tools hosted by Softonic. A platform
corresponds to the root node in a hierarchic category tree.
getChildrens: To fetch the sub-categories of a category (i.e., platform) from a category
identifier.
getPrograms: To fetch a list of tools in a category, including basic information about each
tool (e.g., title, description, rating, license) from a category identifier.
1:
2:
3:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
//Get all platforms and corresponding platform_id
list_ids = getPlatforms();
while( list_ids.hasnext() ){
id_actual = list_ids.next();
//Get all sub-categories in this category
category_subcat = getChildren( actual_id );
list_ids.add(category_subcat);
//Get the no. of programs in this category (and basic information)
category_programs = getPrograms( actual_id );
}
//Store data as RDF triples
RegistryXML2RDF (info);
Figure 17. Overview of the wrapper algorithm to perform experiments on Softonic’s API
As an example, Table 91 collects the number of tools extracted for some of the most relevant
categories according to the iTEC’s tool functionality vocabulary.
Table 91. Number of tools available in some relevant Softonic categories
ITEC functionality
instant messaging client
file sharing tool
video sharing client
audio capture tool
Softonic category
Instant Messaging
FTP
WebCam
Audio Recorders
No of tools per
category
153
83
80
70
If we analyse the fields available for each tool and the records that can be retrieved using the API,
we see that this is one of the most complete and detailed repositories available to enrich the
descriptions of iTEC tools. Note that most of the properties defined in Figure 11 are considered in
Softonic. We can mention those in Table 92.
Table 92. Softonic’s experiment results
Concept
Functionality
Title
Operating
System
Tags
Related Tools
Community
Assessment
Softonic results
All software tools collected include information about their functionality
through their category.
All software tools include information about its name.
All software tools include detailed information about OS compatibility.
Tool descriptions do not include a tag field.
For each tool, there are fields available with information on alternate tools,
that is, related tools having the same or similar functionality.
All software tools include information on tool assessment provided by the
Softonic editorial team and the user community.
Page 111/214
iTEC Project
17092012.Docx
• Centre for Learning & Performance Technologies
Centre for Learning & Performance Technologies (C4LPT) (Hart, 2012) is a web portal collecting
free resources on the learning applications of new technologies. It includes a tool directory
collecting around 2,000 tools classified according to their functionality. Information available on
each tool includes basic fields like name, description, whether the tool is open source, and home
URL. Figure 18 captures a snapshot of this tool directory, where it has been pointed out the
information that may be retrieved.
For this experiment, we wrote a simple script in Java to traverse all the tool categories available in
C4LPT to extract the information available in each page about each tool entry. For that, we
performed an initial analysis of the DOM structure of the pages to process only those tags (i.e.,
DOMElements) containing relevant information. Figure 19 shows an excerpt of the HTML code
with the relevant fields highlighted.
Figure 18. C4LPT snaphot reflecting relevant information
With this simple wrapper we extracted the information about 1,650 tools. The information retrieved
includes only three fields, namely name, description and home page. These fields do not provide
relevant information to be directly used for enrichment, although the category to which a tool is
assigned may be used to add new functionalities to the tools registered in the SDE, or to add new
tags to a tool.
Page 112/214
iTEC Project
17092012.Docx
...
<body>
...
<ol>
<!—CIRIP TOOL RECORD -->
<li>
<p align="left">
<a href="http://www.cirip.ro/" target="_blank">
Cirip
</a>
: Micro-blogging platform (in Romanian).
</p>
</li>

<li>
<p align="left">
<a href="http://www.facebook.com/" target="_blank">
Facebook
</a>
: A huge public social network with over 500 million members. Private
groups can be set up for different activities, and pages for businesses or other
activities.
</p>
</li>
...
</ol>
</body>
Figure 19. Excerpt of the HTML code in C4LPT pages containing the information that may be
extracted for each highlighted tool
• CoolToolsForSchools
CoolToolsForSchools (Shearing, 2012) is a wiki collecting tools relevant to education. This portal
has been created by educators for educators. It invites any individual to notify the existence of a
new tool to be added to the list. Presently, it has 1,220 tools registered. Each tool is catalogued
according to its functionality, and information provided includes the tool’s name, a description, a
thumbnail image, and the home page URL. Figure 20 captures a snapshot of this wiki. Again,
relevant information to be extracted has been pointed out.
As in the case of C4LPT, we developed a simple script written in Java to traverse all tool
categories available to extract the information collected about each tool. For that we analysed first
the DOM structure of the pages to process only those tags (i.e., DOMElements) containing
relevant information. Figure 21 shows an excerpt of the HTML code with the relevant fields in bold.
Page 113/214
iTEC Project
17092012.Docx
Figure 20. Excerpt of the HTML code in CoolToolForSchools pages containing the information that
may be extracted for each highlighted tool
...
<body>
...
<table class="wiki_table">

<tr>
<td>
<a class="wiki_link_ext" href="http://sites.google.com">
Google Sites
</a>
</td>
<td>
<img src="/file/view/sites.png/165547837/140x40/sites.png" />
</td>
<td>
Google Sites is a free and easy way to create and share webpages. Create
rich web pages easily. Collect all your info in one place. Control who
can view and edit
</td>
</tr>

<tr>
<td>
<a class="wiki_link_ext" href="http://prezentit.com" >
PreZentit
</a>
</td>
<td>
<img src="/file/view/Picture8.png/3518/138x81/Picture8.png"/>
</td>
Page 114/214
iTEC Project
17092012.Docx
<td>
Create presentations in a few clicks, wherever you are. Work with your
team in the same presentation at the same time.
Your presentations can be private or public. And each one has its own web
address.
Download your presentations and show them even without an Internet
connection.
The presentations are web pages (HTML) so you could even edit them
manually.
</td>
</tr>
...
</table>
...
</body>
Figure 21. Excerpt of the HTML code in CoolToolForSchools pages containing the information that
may be extracted for each highlighted tool
Figure 22 outlines the algorithm to implement information extraction. Using this wrapper, we
retrieved the information available about all 1,220 tools.
1:
2:
3:
4:
5:
5:
6:
7:
Fetch category URLs (CatUrls).
While ( CatUrls.exist ){
Get HTML from CatUrl.
Get all <tr> child elements from element <table> at body.
Get all <td> child elements from element <tr>.
Extract from <td> url, name, and tool description.
}
Store this information as RDF triples in our KB.
Figure 22. HTML2RDF wrapper algorithm to extract information CoolToolsForSchools
Like in the previous experiment, four information fields have been obtained for each tool: name,
description, home page and category (i.e., functionality). Using these fields, we can retrieve
information related to only two relevant enrichment properties (cf. Table 93).
Table 93. CoolToolsForSchools experiment results
Concepto
Functionality
Title
Operating
System
Tags
Related Tools
Community
Assessment
CoolToolsForSchools results
All software tools collected include information about their
functionality through their category
All software tools include information on its name
No information available
Page 115/214
iTEC Project
17092012.Docx
5. Appendix V: INFORMATION EXTRACTION
WRAPPERS
Information extraction is a process needed to enrich a knowledge base with sources that are not
semantically described. For that, tools are used that extract and convert information into RDF
expressions according to a given configuration. These tools are known as wrappers.
This appendix discusses three types of wrappers found in the literature, namely wrappers that
extract information described according to a relational scheme, wrappers that handle information in
XML, and wrappers that process HTML code. This selection is justified because relational
databases are a common storage solution, many web portals provide access to their content
through APIs returning XML code, and a huge amount of relevant content is only available as
HTML pages.
5.1. Wrappers generating RDF
relational databases (RDB2RDF)
expressions
from
A relevant part of the information available at the web is presently stored in a structured way, and
more specifically in relational databases. This structured information is transformed into publicly
available HTML pages blending content and presentation design. According to (He, Patel, Zhang,
& Chang, 2007), around 75% of web sites’ back-ends are based on SQL databases. Conversion of
relational database content into RDF is one of the processes in Information Extraction (IE)
generating more knowledge19 from existing information. Besides, RDF content generated is in most
cases practically error-free content describing quality knowledge. This is so because input
information is already structured, and therefore is already conditioned for automated processing.
For example, most present-day LOD repositories were generated from the conversion of content
stored in relational databases into Linked Data. The need to automatize this process fostered the
development of several wrappers along the last years, with promising results. Some of the most
relevant are described below. For additional information on RDB2RDF wrappers please consult
(Sahoo, et al., 2009). This document was elaborated among the activities of the W3C’s RDB2RDF
Incubator Group, and includes a broader list of presently available wrappers.
5.1.1. Triplify
The foundational premise of Triplify (Auer, Dietzold, Lehmann, Hellmann, & Aumueller, 2009) is
that many popular web applications (e.g., WordPress, Drupal, osCommerce, Gallery, phpBB)
expose as HTML pages information stored and retrieved from a local database. Triplify offers an
alternate way to present this content in a way that can be processed by software agents according
to the Semantic Web paradigm. For that, Triplify converts the results of a SQL query into RDF
statements according to a previously defined mapping pattern. The statements obtained may be
subsequently published in different serialization formats, and particularly as LinkedData information
(cf. Figure 23).
19
In this context, knowledge is information expressed using some mechanism from the field of Knowledge
Representation, like RDF.
Page 116/214
iTEC Project
17092012.Docx
Figure 23. An outline of the overall workings of Triplify, fromhttp://triplify.org/
Triplify does not provide a custom mapping language for the representation of mapping patterns,
but these patterns are described using an extension of the SQL language, a well-known language
among developers of information management applications. This approach fostered the adoption
of Triplify by the development community. Figure 24 collects a mapping pattern developed in PHP
for a WordPress-based blog system.
Figure 24. Triplify matching pattern for a database used in a WordPress blog. Extrated from (Auer,
Dietzold, Lehmann, Hellmann, & Aumueller, 2009)
To achieve a successful semantic transformation, some restrictions are imposed on pattern
structures:
•
•
The first column in each view (i.e., the result obtained after a database query) must include
an identifier facilitating the generation of a unique URI (e.g., SELECT id FROM users).
Column names in each view will be used to generate properties’ URIs. As a consequence,
it is a common practice to perform mappings to existing vocabularies (e.g., SELECT id,
name AS ‘foaf:name’ FROM users).
Page 117/214
iTEC Project
•
17092012.Docx
Individual cells in each view contain property values, either as literals or as other instances.
To indicate that a property references an object (i.e., the property is an ObjectProperty) a
reference to the class of the other instance separated from the name of the column by the
symbol “->” is used (e.g., SELECT id, category_parent AS ‘skos:narrower->category’
FROM categories). In the case of literals, Triplify supports the automatic retrieval of each
literal’s data type.
The semantic representations resulting from these mapping patterns may be obtained on demand
(i.e., each time an HTTP request is received, e.g., http://myblog.de/triplify/posts/13) or according to
the ETL (Extract-Transform-Load) scheme, which performs data transformation even before a
request is received.
Triplify has been developed to provide a light plugin that can be easily embedded in any web
application. Besides, to foster and to facilitate its use, its web site hosts a wiki20 including several
mapping patterns applicable to popular web applications, like osCommerce orWordPress. As a
drawback, we may point out that Triplify does not support SPARQL queries.
5.1.2. Ultrawrap
Ultrawrap (Sequeda, Depena, & Miranker, 2009) is another wrapping instrument for relational
databases providing Semantic Web-formatted expressions. Its most relevant feature is the
provision of a SPARQL query service on the wrapped database. Ultrawrap’s main features are:
1. Full automatic support to publish a relational database in the Semantic Web.
2. Real-time consistence assurance between data in the relational database and RDF
content.
3. Comprehensive use of existing SQL infrastructure.
To achieve these goals, the Ultrawrap architecture is composed of four main elements (cf. Figure
25):
1. OWL PutativeOntology (PO): This ontology is the result of mapping the relational
database’s SQL scheme syntax into an OWL file. It includes all necessary properties for an
axiomatic system. By definition, putative ontologies represent any type of syntactic
transformation of a source data scheme into an ontology.
2. TripleView: This element represents an SQL view of the data available in the relational
database, represented as triples. This view includes three columns corresponding to the
three components of a triple (i.e., subject, predicate, object): CREATE VIEW
TripleView(s,p,o). Generated triples are PO-consistent. Therefore, users should take this
vocabulary as a basis to create SPARQL queries.
3. SPARQL to SQL translator: This component translates SPARQL queries into SQL queries
based on the TripleView representation.
4. SQL Optimizer: The query optimizer rewrites the queries above into native SQL queries,
i.e., queries expressed according to the original relational database scheme. This way,
20
http://triplify.org/Configuration
Page 118/214
iTEC Project
17092012.Docx
queries are executed natively, reducing response time and taking the most of the existing
SQL infrastructure.
Figure 25. Ultrawrap architecture, from (Sequeda, Depena, & Miranker, 2009)
The development of a Liked Data layer enabling the exposure of the information in the database
according to the Linked Data premises is foreseen for the near future.
5.1.3. Virtuoso RDF view
Virtuoso (OpenLink-Software, 2012) is a well-known multi-protocol server providing access to both
local and remote relational data via ODBC/JDBC. Due to the increasing interest on the Semantic
Web, this server currently offers relevant RDF features. RDF data is stored natively in a relational
database. Virtuoso uses a four-column relation to store information, that is, each row stores a quad
combining a triple (S, P, O) and the name of the graph (G) to which the triple belongs. All columns
are of integer type (32 or 64 bits) except the column reserved for the object G, whose (SQL) type is
“any”. References pointing to other tables are internally handled as IRIs (in this context, and IRI is
equivalent to an URI).
The functionality Virtuoso RDF Views (Erling & Mikhailov, 2007) supports the manual mapping of
any collection of relational tables (i.e., relations), views, processes or Web services to RDF
records. For that, quad map patterns are used. With these artefacts, users define which
information in the database will be extracted and mapped into a quad (graph, subject, predicate,
object). Patterns are expressions involving columns or column sets and constants in the database
that relate to each of the components in the quad. Using this pattern, the URI generation
processes to be applied along the mapping process can also be defined. Quad map pattern are
expressed in a proprietary language, which also supports SPARQL-style annotations. Figure 26
shows an example mapping pattern.
Page 119/214
iTEC Project
17092012.Docx
graph <http://myhost/users>
subject :user-iri (user.U_ID)
predicate :homepage
object :blog-home (blog.HOMEPAGE)
where(not ˆ{user.}ˆ.U_ACCOUNT_DISABLED) .
Figure 26. Example of quad map pattern, from (Erling & Mikhailov, 2007)
Besides, Virtuoso RDF View also supports the automatic generation of mappings between the
database and RDF. For that, systems map each table to a node of class RDF, the unique identifier
of each record (primary key) to an entity (subject), the name of each column to a property, and the
value of the column to an object.
Thus, Virtuoso supports the representation of information as virtual RDF graphs avoiding the actual
generation of RDF datasets. Access and query services may be generated on top of these virtual
graphs (e.g., SPARQL endpoints).
5.1.4. D2RQ Platform
The D2RQ platform (Bizer, Cyganiak, Becker, Langegger, & Leimer, 2012) provides access to
relational databases as if they were virtual RDF graphs. These graphs support only reading access
to information, that is, database information cannot be modified through the virtual graphs. Using
this approach, there is no need to replicate the relational database in an RDF repository.
The D2QR platform is constructed around a collection of interacting components. Figure 28
illustrates this platform’s architecture. Its components are:
•
•
•
D2RQ Mapping Language: a declarative language supporting the definition of mappings
between relational database schemes and RDF-S/OWL ontologies. Thus, it supports the
specification of how resources are identified and how property values are generated from
the information in the database. Definitions are expressed as RDF documents written in
Turtle. This approach is similar to the SQL view concept, only that the generated virtual
information structure is an RDF graph instead of a virtual relational table. Figure 27 shows
an example of this mapping language.
D2RQ Engine: a plug-in for the Jena Semantic Web toolkit that support the translation of
Jena API calls into SQL queries according to the mappings defined in D2RQ Mapping
Language. These queries will be passed to the database engine, and the corresponding
results will be returned to the framework’s upper layers.
D2R Server: an HTTP server supporting the publication of the relational database content
in the Semantic Web. D2R Server provides access to software agents to retrieve RDF and
XHTML representations of the resources, and supports SPARQL queries to the database.
# D2RQ Namespace
@prefix d2rq: <http://www.wiwiss.fu-berlin.de/suhl/bizer/D2RQ/0.1#> .
# Namespace of the ontology
@prefix : <http://annotation.semanticweb.org/iswc/iswc.daml#> .
# Namespace of the mapping file; does not appear in mapped data
@prefix map: <file:///Users/d2r/example.ttl#> .
# Other namespaces
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
Page 120/214
iTEC Project
17092012.Docx
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
map:Database1 a d2rq:Database;
d2rq:jdbcDSN "jdbc:mysql://localhost/iswc";
d2rq:jdbcDriver "com.mysql.jdbc.Driver";
d2rq:username "user";
d2rq:password "password";
.
# ----------------------------------------------# CREATE TABLE Conferences (ConfIDint, Name text, Location text);
map:Conference a d2rq:ClassMap;
d2rq:dataStorage map:Database1.
d2rq:class :Conference;
d2rq:uriPattern
"http://conferences.org/comp/confno@@Conferences.ConfID@@";
.
map:eventTitle a d2rq:PropertyBridge;
d2rq:belongsToClassMapmap:Conference;
d2rq:property :eventTitle;
d2rq:column "Conferences.Name";
d2rq:datatypexsd:string;
.
map:location a d2rq:PropertyBridge;
d2rq:belongsToClassMapmap:Conference;
d2rq:property :location;
d2rq:column "Conferences.Location";
d2rq:datatypexsd:string;
.
Figure 27. Example of a R2DQ mapping from table Conferences in a relational database to class
Conference in an ontology, from http://d2rq.org/d2rq-language
Figure 28. D2RQarchitectura, from (Bizer, Cyganiak, Becker, Langegger, & Leimer, 2012)
D2QR offers a portfolio of higher-level functionalities by the orchestration of the processes above.
Among them:
•
It supports semantic queries to a relational database in SPARQL.
Page 121/214
iTEC Project
•
•
•
•
17092012.Docx
It provides access to the content in a relational database as if it were a web’s Linked Data
repository.
It supports the Jena API (Carroll, Dickinson, Dollin, Reynolds, Seaborne, & Wilkinson,
2004) to perform OWL and RDFS inferences on the content of a relational database.
It provides access to the content in a relational database using the Jena API.
It supports the generation of customized dumps from the content of a relational database in
RDF, to be loaded in an RDF repository.
5.1.5. ODEMapster
The ODEMapster framework (Rodríguez & Gomez-Perez, 2006) tries to bind the semantics in an
ontology to the content in a relational database, that is, to bind the terminology defined in an
ontology to a relational database scheme. This way, information can be exposed according to the
premises of the Semantic Web.
To achieve this goal, this framework defines two main components, namely the R2O language and
the ODEMapster processor (cf. Figure 29):
1. R2O language: An XML-based declarative language supporting the definition of arbitrarily
complex mapping expressions between the elements in an ontology (concepts, attributes,
relations) and the elements in a relational database (relations, attributes). It is a highly
expressive language independent of the database management system (DBMS) used.
2. ODEMapster inference engine: This processor takes the mapping descriptions in a R2O
document to generate RDF statements from database relations. ODEMapster supports two
execution modes: a) Query driven upgrade, to translate and execute queries as they are
received, and b) Massive upgrade batch process, supporting the generation of a semantic
repository with all the individuals generated from data in a relational database.
Figure 29. Outline of the workings of ODEMapster, from (Rodríguez & Gomez-Perez, 2006)
Page 122/214
iTEC Project
17092012.Docx
5.1.6. RDBToOnto
The RDBToOnto framework (Laclavik, 2006) is targeted to the conversion of data stored in
relational databases into ontology instances. This tool is based on SQL queries and RDF/OWL
templates to be filled with the results of the queries. To better understand this process we will
briefly discuss it below:
1. SQL Query: to extract the information to be mapped from the database. Query (1)
illustrates this. It codes a query to the relation document that stores information about
documents. The most relevant information is extracted.
SELECT id, url, title
FROM document
(1)
2. RDF/OWL pattern completion: the system fills in the fields delimited by curly braces in a
given pattern. An expert should identify which elements in the ontology can be mapped
using the values extracted from the database. RDF pattern (2) below reflects how each field
in the pattern is completed with the results from each row returned by the query to generate
an individual in the ontology.
<?xmlversion=”1.0”?>
<rdf : RDF
xmlns : rdf = ”http://www.w3.org/1999/02/22− rdf − syntax − ns#”
xmlns :xsd = ”http://www.w3.org/2001/XMLSchema#”>
<Documentrdf:ID = ”document {id}” >
<hasTitlerdf:datatype=xsd:string> {title} </hasTitle>
<hasURLrdf:datatype=xsd:anyURI> {url} </hasURL>
</Document>
</rdf:RDF>
(2)
3. RDF/OWL data registration: Once all patterns have been completed, the RFD data is
extracted. Finally, RFD data is stored in the ontological model.
Figure 30 outlines the RDBToOnto architecture and contextualizes the steps discussed above.
Figure 30. RDFToOnto architecture, from (Laclavik, 2006)
Page 123/214
iTEC Project
17092012.Docx
5.1.7. RDB2OWL
RDB2OWL (Bumans & Cerans, 2010 ) proposes a framework to generate RDF triples from an SQL
relational database. Its operation is similar to that of ODEMapster, that is, a SQL engine is used to
apply the mappings defined (cf. Figure 31). Mappings establish a binding between the elements in
one or several relational database schemes and an OWL ontology to migrate records in a
database into sets of RDF triples. The most relevant RDB2OWL features are the automatic
generation of SQL sentences from mappings, the support of configuration options enabling
advanced triple generation, and the support for the validation of mappings using SQL.
Figure 31. RDB2RDF architecture, from (Bumans & Cerans, 2010 )
The first conversion stage is devoted to define a mapping specification. This specification is
declared using tables class_map, object_property_map and datatype_property_map. These
relations are stored in the database and define which elements from the ontology map to which
elements in the database. Each row in these tables can be used to generate a SQL statement.
The next mapping phase is targeted to generate SQL statements to remove triples not satisfying
the advanced specifications (fields required properties and required_range in mapping relations).
Finally, once the mapping has been stored in the database, it can be validated using SQL. Two
types of validations can be performed. The first one, Omission checks, detects classes or
properties in the ontology or relations in the database that have not been mapped, and columns in
the database that are not referenced in any expression. The second one, Consistency checks,
detects inconsistencies in the mapping relations of properties and classes according to their range
and/or domain.
5.1.8. W3C RDB2RDF
W3C launched the RDB2RDF Incubator Group in 2008 and 2009 to study the state of the art in this
field. Among the outcomes of this group, the most relevant so far is the study and comparative
analysis of the existing approaches to relational database mapping into RDF data (Sahoo, et al.,
2009).
Page 124/214
iTEC Project
17092012.Docx
This initiative fostered the creation in 2010 of the W3C RDB2RDF WorkingGroup within the
Semantic Web Activity. Its mission is to propose standard languages supporting the mapping of
relational data and relational database schemes into RDF and OWL. In February 2012 two
candidate standards proposing two languages were published. These languages are Direct
Mapping (DM) and RDB2RDF Mapping Language (R2RML), which are briefly discussed below.
5.1.8.1. DM: A Direct Mapping of Relational Data to RDF
In (Arenas, Bertails, Prud'hommeaux, & Sequeda, 2011) a direct mapping from a relational
database into RDF is defined. This direct mapping specifies a simple transformation that may be
used as a basis to define and compare more advanced transformations. It may also be used to
create RDF graphs or virtual graphs. Once these graphs have been generated, it is possible to
define mechanisms to query them using SPARQL or RDF APIs.
A direct mapping generates an RDF graph (the direct graph) from data in a relational database
and a relational database scheme. This graph is bound to a base IRI. The base IRI enables the
resolution of relative IRIs that will be generated from the application of the algorithm described in
this standard.
The direct graph defines relations between entities according to the foreignkeys in the database
according to an algorithm known as DirectGraphalgorithm. The specification states that relative
IRIs are generated from SQL relation identifiers and column identifiers. These identifiers will be
separated by characters '#', ';', '/' and '='. These characters will be escaped according to a set of
rules defined in the R2RML standard (cf., 5.1.8.2). The rules defined for the DirectGraph algorithm
are:
•
•
•
•
For each row in a table, a row node is generated from an IRI, or a black node, according to the
rules below:
o If the table contains a primary key, a relative IRI is generated appending:
ϭͿ The name of the table, escaped as defined in R2RML,
ϮͿ Character '/',
ϯͿ For each primary key column:
a) The name of the column, escaped as defined in R2RML,
b) Character'=',
c) The canonical representation of the RDF literal corresponding to the value
in the column, according to R2RML;
d) If this column is not the last primary key column, character '; ' is appended
o If the table does not contain a primary key, a blank node is generated.
For each table, a table IRI is generated from the name of the table, escaped as defined in
R2RML.
For each column in the table, a literal property IRIis generated appending:
ϮͿ Character '#',
ϯͿ The name of the column, escaped as defined in R2RML.
Foreign keys in a table generate a reference property IRI appending:
ϮͿ String '#ref-',
ϯͿ For each foreign key column:
Page 125/214
iTEC Project
17092012.Docx
a) The name of the column, escaped as defined in R2RML
b) If this column is not the last foreign key column, character '; ' is appended
According to these rules, any relational database scheme has an associated direct graph defined
as:
•
•
•
•
•
•
A direct graph is the union of the table graphs generated for each table in the database.
A table graph is the union of the row graphs for each row in the table.
A row graph is an RDF graph composed by triples:
o Triples row type triple.
o A reference triple for each list of column names of foreign key columns, provided no
column has a NULL value.
o A literal triple for each non-NULL column in a table.
A row type triple is an RDF triple composed of:
o Subject: the row node.
o Predicate: the RDF IRI rdf:type.
o Object: the table IRI.
A literal triple is an RDF triple composed of:
o Subject: the rownode.
o Predicate: the literal property IRI.
o Object: the representation of the column value according to its R2RML natural RDF
literal.
A reference triple is an RDF triple composed of:
o Subject: the row node.
o Predicate: the reference property IRI.
o Object: the row node for the referenced row.
To illustrate the concepts defined in this recommendation we transcribe below one of the basic
examples included in the document. It is based on a database including the two relations in Figure
32.
People
ID (PK) fname
Addresses
Addr(FK)
7
Bob
18
8
Sue
NULL
ID (PK)
18
city
state
Cambridge MA
Figure 32. Example database tables, from (Arenas, Bertails, Prud'hommeaux, & Sequeda,
2011)
Assuming a base IRI of the form <http://foo.example/DB/>, we obtain the graph in Figure 33 after
applying a direct mapping.
@base<http://foo.example/DB/> .
@prefixxsd: <http://www.w3.org/2001/XMLSchema#> .
<People/ID=7>rdf:type<People> .
<People/ID=7><People#ID>7 .
Page 126/214
iTEC Project
17092012.Docx
<People/ID=7><People#fname> "Bob" .
<People/ID=7><People#addr>18 .
<People/ID=7><People#ref-addr><Addresses/ID=18> .
<People/ID=8>rdf:type<People> .
<People/ID=8><People#ID>8 .
<People/ID=8><People#fname> "Sue" .
<Addresses/ID=18>rdf:type<Addresses> .
<Addresses/ID=18><Addresses#ID>18 .
<Addresses/ID=18><Addresses#city> "Cambridge" .
<Addresses/ID=18><Addresses#state> "MA" .
Figure 33. Graph obtained after applying a direct mapping on the example database, from (Arenas,
Bertails, Prud'hommeaux, & Sequeda, 2011)
5.1.8.2. R2RML: RDB to RDF Mapping Language
(Das, Sundara, & Cyganiak, 2011) discusses the R2RML language, which is intended to describe
customized mappings from relational databases to RDF datasets. Unlike Direct Mapping (DM),
which automatically maps the complete database according to some basic rules, R2RML can be
used to completely drive the mapping process. In DM, the generated RDF graph corresponds to
the same structure as the relational model, and the RDF vocabulary includes the names of the
elements in the database scheme. Neither the structure nor the vocabulary can be modified. In
turn, R2RML supports the definition of a view of the information in the relational database
according to an RDF data model, including structures and vocabularies generated from a userdefined mapping.
R2RML mappings are themselves RDF graphs written in Turtle (Beckett & Berners-Lee, 2008).
This latter language supports the definition of several types of mappings. With this, developers
may construct a virtual SPAQRL Endpoint, generate RDF dumps, or provide a Linked Data
interface.
Figure 34 provides an overview of this mapping language. A R2RML map corresponds to a
structure known as logical table. This structure refers to a collection of information retrieved from
an input database. A logical table may be a base table, a view or a valid SQL query, also known as
R2RML view.
Each logical table is mapped to RDF according to a triples map. A triples map is a rule to map
each of the rows in a logical table into some RDF triples. These rules have two parts:
ϭͿ A subject map defining how to generate the subjects of all RDF triples that may be
generated from each row in a logical table.
ϮͿ Several predicate-object maps, which in turn are composed of predicate maps and
object maps (or referencing object maps). These maps are functions enabling the
generation of one or several predicate-object pairs for each row in a logical table.
Triples are produced by combining a subject map with a predicate map and an object map, while
these latter maps are generated from each row in the logical table.
By default, all RDF triples are inserted into the output dataset’s default graph. However, a triple
map may contain graph maps to restrict to some or all RDF triples their insertion in given named
graph.
Page 127/214
iTEC Project
17092012.Docx
Figure 34. General overview of the R2RML mapping language, from (Das, Sundara, & Cyganiak, 2011)
5.2. Wrappers generating RDF from XML documents
(XML2RDF)
XML (Bray, Paoli, & Sperberg-McQueen, 1998) is a metalanguage collecting a set of rules to
structure data. That is, XML supports the construction of documents organized according to a
formal structure that can be easily processed by a software application. XML is a W3C
specification that has become a reference to support communication among web applications.
While databases are a popular solution for the storage of massive amounts of data in web
applications, which makes them play a fundamental role in information enrichment, XML is a
popular solution to represent data structures in web services. Many APIs available in Internet have
been designed to return results from a given service or to receive parameters from invoking
applications as XML documents. Insofar information enrichment is concerned, there are many
interesting sources of information available that can be accessed using this kind of APIs.
The way an XML document is structured and the specific restrictions applicable to content in these
documents can be defined in a document named XML Schema. This document supports the
validation of XML documents, but also the interpretation of such documents.
Although the generation of a XML2RDF wrapper is a relatively simple task due to the inherent
structure of XML documents, mappings must be specific to each type of XML file. In other words,
mappings are not reusable for different types of XML documents. As a consequence, an expert
facing the task of processing a large amount of XML documents has to generate a mapping pattern
for each of them. If an XML Schema is available for each type of document, only this information
has to be analysed to define the correct wrapper.
We describe below the most relevant projects and technologies related to this type of conversion.
Page 128/214
iTEC Project
17092012.Docx
5.2.1. GRDDL
Gleaning Resource Descriptions from Dialects of Languages, GRDDL (Connolly, 2007), offers a
framework to define transformations from XML documents, especially XHTML documents, into
RDF triples. GRDDL is based on the inclusion of a link to a document defining the desired
transformation in the original XML document, that is, which information fields should be converted
into triples and which terminology has to be used. The transformation file is designed and
generated by an expert in advance. This file collects the rules for a software client to automatically
obtain the semantic version of some piece of information. In other words, this technology allows
the data producer to add a semantic view of the information. However, the information that is
semantically extrapolated is restricted to the one designated by the data producer, as clients do not
participate in the process. As a consequence conflicts may arise, as a client may require semantic
information from some data in the XML document while the producer only provides transformations
to other data.
GRDDL transformations are typically written in XSLT (Clark, 1999). XSLT was initially conceived to
transform an XML document into another XML document. However, XSLT can be used to generate
other types of structured documents, like HTML, RDF, PDF, etc. An XSLT transformation is also a
well-formed XML document, and is based on the association of patterns and templates. Patterns
identify elements in the input document, whereas templates are used to generate the content of the
output document.
The transformation process is performed by an XSLT processor. This application takes as input the
source XML file and the transformation declarations collected in the XSLT file. After performing the
defined transformation, it generates an output file with the results (cf. Figure 35).
Figure 35. Evolution of an XSLT processor, from our own sources
5.2.2. Redefer
Project Redefer (Garcia, Perdrix, Gil, & Oliva, 2008) has among its objectives to contribute a
collection of tools to support RDF conversions. These tools are classified according to the
respective conversion formats. Applications mapping XML documents into OWL/RDF are:
Page 129/214
iTEC Project
•
17092012.Docx
XSD2OWL: This tool transforms the semantic model in a XML Schema into OWL. It detects
constructors instantiated in the XML Schema, and maps them into OWL constructors
having the same or similar meaning. Table 94 illustrates the relations between both types of
constructors.
Table 94. Mapping of XML Schema constructors and OWL in Redefer, from
http://rhizomik.net/html/redefer/xsd2owl/
yD>^,D
ĞůĞŵĞŶƚͮĂƚƚƌŝďƵƚĞ
Kt>
ƌĚĨ͗WƌŽƉĞƌƚǇ
Žǁů͗ĂƚĂWƌŽƉĞƌƚǇ
Žǁů͗KďũĞĐƚWƌŽƉĞƌƚǇ
ĞůĞŵĞŶƚΛƐƵďƐƚŝƚƵƚŝŽŶ'ƌŽƵƉ ƌĚĨƐ͗ƐƵďWƌŽƉĞƌƚǇKĨ
ĞůĞŵĞŶƚΛƚǇƉĞ
ĐŽŵƉůĞǆdǇƉĞͮŐƌŽƵƉͮ
ĂƚƚƌŝďƵƚĞ'ƌŽƵƉ
ĐŽŵƉůĞǆdǇƉĞͬͬĞůĞŵĞŶƚ
ĞǆƚĞŶƐŝŽŶΛďĂƐĞͮ
ƌĞƐƚƌŝĐƚŝŽŶΛďĂƐĞ
ΛŵĂǆKĐĐƵƌƐ
ΛŵŝŶKĐĐƵƌƐ
ƐĞƋƵĞŶĐĞ
ĐŚŽŝĐĞ
•
ƌĚĨƐ͗ƌĂŶŐĞ
Žǁů͗ůĂƐƐ
Žǁů͗ZĞƐƚƌŝĐƚŝŽŶ
ƌĚĨƐ͗ƐƵďůĂƐƐKĨ
Žǁů͗ŵĂǆĂƌĚŝŶĂůŝƚǇ
Žǁů͗ŵŝŶĂƌĚŝŶĂůŝƚǇ
Žǁů͗ŝŶƚĞƌƐĞĐƚŝŽŶKĨ
Žǁů͗ƵŶŝŽŶKĨ
DKd/s/MEDWK
EĂŵĞĚ ƌĞůĂƚŝŽŶ ďĞƚǁĞĞŶ
ŶŽĚĞƐŽƌŶŽĚĞƐĂŶĚǀĂůƵĞƐ
ZĞůĂƚŝŽŶĐĂŶĂƉƉĞĂƌŝŶƉůĂĐĞŽĨ
ĂŵŽƌĞŐĞŶĞƌĂůŽŶĞ
dŚĞƌĞůĂƚŝŽŶƌĂŶŐĞŬŝŶĚ
ZĞůĂƚŝŽŶƐ ĂŶĚ ĐŽŶƚĞǆƚƵĂů
ƌĞƐƚƌŝĐƚŝŽŶƐƉĂĐŬĂŐĞ
ŽŶƚĞǆƚƵĂůŝƐĞĚƌĞƐƚƌŝĐƚŝŽŶŽĨĂ
ƌĞůĂƚŝŽŶ
WĂĐŬĂŐĞ ĐŽŶĐƌĞƚŝƐĞƐ ƚŚĞ ďĂƐĞ
ƉĂĐŬĂŐĞ
ZĞƐƚƌŝĐƚ ƚŚĞ ŶƵŵďĞƌ ŽĨ
ŽĐĐƵƌƌĞŶĐĞƐŽĨĂƌĞůĂƚŝŽŶ
ŽŵďŝŶĂƚŝŽŶ ŽĨ ƌĞůĂƚŝŽŶƐ ŝŶ Ă
ĐŽŶƚĞǆƚ
XML2RDF: It maps XML instances into RDF instances according to the semantic structure
defined in the ontology obtained after the application of XSD2OWL. This tool follows a
structure mapping approach, as it is intended to represent the structure of XML metadata
(i.e., XML tree) as an RDF graph. Initially, instances are generated as black nodes in the
RDF model. After that, the semantic information in the graph is completed using the
terminology defined in the OWL ontology (e.g., rdf:type properties binding each element in
the ontology to the corresponding instance). Figure 36 shows a graphical example of the
structural conversion performed by this tool. This approach enables the generation of RDF
metadata as transparently as possible.
Figure 36. Outline of the conversion of an XML tree into an RDF graph, from
http://rhizomik.net/html/redefer/xml2rdf/
Page 130/214
iTEC Project
17092012.Docx
5.2.3. KREXTOR
Krextor (Lange, 2009) is a library to support the translation of XML files into RDF. It includes
functionalities and templates to generate RDF resources from elements represented according to
the XML syntax, to generate URIs for these resources according to the Linked Data principles, and
to translate XML text and attributes into resource properties.
Krextor includes a Java wrapper that facilitates its direct integration in other software applications.
This framework also includes a command front-end for the development of the XSLT
transformation documents. This way, platform users may add an XSLT file to drive the mapping of
the desired XML elements into RDF. Besides, predefined templates are provided to create
resources instantiating specific classes or to add literal properties or URIs to existing resources.
5.3. Wrappers generating RDF from HTML (HTML2RDF)
The application of wrappers to HTML documents has been an active field along the last years,
practically since the popularization of web applications and services. This is so because in many
situations HTML documents are the only way to fetch information available on the web. Typically,
information producers expose information at web pages to be accessed and understood only by
human users (e.g., blogs, product catalogues, personal pages). When this information was needed
for other uses and information was not available in other formats conditioned for automated
processing, information had to be manually fetched and organized. As a consequence, a
generation of specialised Information Extraction wrappers to support the automated extraction of
information from web pages appeared. This field even received a specific name, Web Scraping
(Hepp, Bachlechner, & Siorpaes, 2006). In turn, this type of wrappers is known as web wrappers or
screen-scrapers (Alba, Bhagwan, & Grandison, 2008).
According to (Fiumara, 2007), data in HTML documents can be classified into three types
according to its structure:
•
•
•
Non-structured pages: free text documents, with no structure at all. This type of pages is
written in natural language to be specifically understood by human users. Wrappers in this
case use to be rather complex and the quality of the retrieved information is usually poor.
Structured pages: this type of pages typically exposes data retrieved from structured
sources (e.g., from a database) according to a well-defined hierarchical scheme. In this
case, wrappers are simpler in terms of Web Scraping, and support the retrieval of highquality information. Note that these pages provide a view to a structured source.
Semi-structured pages: a blend of the two types above. Wrappers in this case are based on
the detection of special patterns (e.g., HTML tags).
Besides the structure of the web page itself, we may consider the hyperlinks included in them.
They will provide grouping and layout to the relevant elements obtained after the extraction:
•
•
One-level one-page: a single page includes all relevant elements.
One-level multi-pages: elements are included in a collection of pages linked with each
other.
Page 131/214
iTEC Project
•
17092012.Docx
Two-level pages: these web sites are organized around a chain of pages including a
reduced version of the information in several elements. In turn, this reduced information
includes links to specific pages for each element, where information is provided with
additional detail.
Typically, screen-scrapping wrappers produce output information in a format suitable to be stored
in a database. Until recently, the direct generation of XML files was an optional feature in most
tools available.
We can find on the web several portals and wikis including scripts to support the direct extraction
of information from web pages. One of the most popular is the extraction facility in ScraperWiki
(ScraperWiki, 2012), which support the development of extraction scripts in Ruby, Python and PHP
to extract and map information. These scripts may also be executed from that facility, and may be
shared with the community to be reused. Information extracted is stored in a database hosted by
the same portal to be accessed through SQL queries.
The availability of wrapping solutions to convert extracted information from conventional HTML
pages directly to RDF is quite recent. We discuss below some of the outcomes in this field.
5.3.1. GRDDL
This technology (Connolly, 2007), which has been already discussed above when tackling XML to
RDF conversion (cf., Section 5.2.1), is also applicable to HTML pages, and more specifically to
XHTML documents. XHTML can be seen as a stricter version of HTML requiring page descriptions
to be well formed XML. In other words, it has the expressive power of HTML, but requires
complying with the XML requirements (e.g., all tags opened must be closed afterwards).
Besides, it supports the generation of XSLT transformation files to convert content in a web page
written in XHTML into an RDF structure. For that, we also need an XSLT processor. The process is
identical as the one described above for XML2RDF.
5.3.2. RDF Web Scraper
Among other activities, the Mindswap research group21 from the University of Maryland (MIND
LAB, 2012) develops tools to support the deployment of the Semantic Web. These tools have been
designed to enable users both to create and utilize semantic information.
One of the tools produced is RDF Web Scraper (Golbeck, Grove, Parsia, Kalyanpur, & Hendler,
2002). It enables the extraction of RDF information from the information in HTML pages. It relies
upon the fact that many web pages have a regular content structure. This structure is typically
created from tagged fields, lists or tables. This way, it is possible to apply a wrapper to process this
structure to be further converted into RDF. For that, the source code of the page has to be
analysed to detect relevant pieces of information. Information will be associated to HTML tags,
either directly or as attribute values. Once this analysis has been performed, users interact with the
tool interface to register the tag routes in the HTML document containing the information to be
21
http://www.mindswap.org/
Page 132/214
iTEC Project
17092012.Docx
extracted, binding them to the corresponding fields. In other words, the wrapper’s mapping pattern
is generated. After that, the tool executes the wrapper to fetch the desired information from the
web page. Collected information is presented to the user as a data table, according to the fields
defined. Users may then map each column in the table to the suitable ontological indications, that
is, to define the RDF template that will be applied to the retrieved data. Finally, RDF data is
produced using that mapping.
Figure 37 provides a screenshot from this tool in the process of mapping. Tool designers
themselves point out that this is a complex process that may require users to repeat it several
times to obtain the desired results.
5.3.3. Piggy Bank
Piggy Bank (Huynh, Mazzocchi, & Karger, 2005) is one of the outcomes of project SIMILE (Lee,
2004) (Mazzocchi, Garland, & Lee, 2006) from MIT. This application has been designed as an
extension of traditional web browsers, more specifically Firefox, facilitating users the navigation
across the content of the Semantic Web in a way similar to traditional web navigation. When
semantic annotations are detected in a web page, the user is offered the possibility to fetch that
information. Users may then navigate across the collected semantic information and process it at
their will.
Besides, Piggy Bank supports the invocation of screen scrapers in pages with no semantically
annotated content to extract relevant information fragments to be expressed in a semantic format.
This way, the obtained pieces may be processed and organized independently of their origin or
type. Scrapers may be downloaded if available for the active page, or may be manually generated.
These scrapers are pieces of Javascript code that may be generated by experts or programmed
using a visual tool known as Solvent (Simile Project, 2012). Solvent is a Firefox extension that
supports the generation of an RDF mapping algorithm just by clicking on the relevant elements in
the web page to be processed. Users select from the browser screen which information fragments
will be processed, and then indicate which mapping should be applied to these elements to convert
them into RDF. Finally, the tool generates Javascript code for the corresponding wrapper. Figure
38 captures a snapshot of this tool.
Piggy Bank also offers a Web service22 for the user community to register and share the collected
semantic information, either publicly or to restricted user groups. This repository, known as
Semantic Bank, may be used to share user-generated screen wrappers to make them available to
the user community.
5.3.4. WebCat
WebCat (Martins & Silva, 2005) is an extensible framework to automatically extract metadata from
web documents to generate RDF descriptions. It has a modular design facilitating its integration in
third-party tools. It has a block-based structure (cf. Figure 39) where each block as a specific
functionality that has to be coordinated with the rest of the blocks to complete the conversion
process.
22
http://simile.mit.edu/wiki/Piggy_Bank
Page 133/214
iTEC Project
17092012.Docx
Figure 37. RDF Web Scraper screenshot capture, from http://www.mindswap.org/
Figure 38. Solvent screenshot capture for Starbucks.com, from
http://simile.mit.edu/wiki/Solvent_Screencasts
Page 134/214
iTEC Project
17092012.Docx
Figure 39. WebCAT structure, from (Martins & Silva, 2005)
This wrapper processes non-structured documents, that is, plain text. Besides converting HTML
pages, it also processes other types of documents available on the web (e.g., PDF, Microsoft
Word, PostScript). For that, the tool extracts text of these documents and converts it into HTML
before applying the desired mapping.
This tool is based on name identity recognition in a text block. Target entities are those with
relevance and intrinsic representation (e.g. people, locations). From them, semantic annotations
are generated, including classes and instances referring to a semantic repository (i.e., an
ontology). The sentence below illustrates this:
Andrés, an engineer living in Vigo, worked together with Raquel in HP.
[PERSON Andrés], an engineer in [LOCATION Vigo], worked together with [PERSON Raquel] in
[ORGANIZATION HP].
This type of systems picks up the words in a block of text (i.e. it tokenizes the text) and applies to
them entity extraction rules. Rules are based on regular expressions. Finally, candidate entities are
extracted after being compared with other individuals present in the entity repository.
This tool is most useful as an information extractor for search engines. Presently, it is used as the
main component in a Portuguese search engine known as Tumba! (Silva, 2003).
5.3.5. On-to-Knowledge
The OntoKnowledge project (Fensel, 2002) proposes an ontology-based framework to efficiently
process the huge amount of heterogeneous and semi-structured documents available at the Web.
Among the tools developed under this project we may point out CORPORUM, which supports the
extraction of RDF metadata from documents in several formats. For that, it performs two basic
tasks, namely the interpretation of text in natural language and the extraction of information from
free text. The tool supports the extraction of concepts and not only simple words, to establish
semantic relations among them like subClassOf orInstanceOf. This way, this tool can semantically
Page 135/214
iTEC Project
17092012.Docx
analyse a given domain to automatically extract a thesaurus. The tool has two main components,
OntoExtract and OntoWrapper.
•
•
OntoExtract supports the extraction of ontologies from web pages by parsing, tokenising
and analysing text, both lexically and syntactically. OntoExtract generates nodes and
relations between keywords, and finds instances of concepts within the document. The tool
uses content in the local repository reflecting available knowledge about the universe of
discourse to improve specific aspects of the detection of elements in the text, and to apply
techniques such as discourse, coreference and sentence disposition analysis. OntoExtract
also supports the description of relations among taxonomies.
OntoWrapper is a screen-scraping tool that extracts information from specific web sites.
Unlike OntoExtract, which works autonomously, OntoWrapper needs users to manually
define information capture rules. These rules will typically be applied to structured or semistructured pages (e.g., tables, directories, etc. Figure 40 captures a snapshot of this tool.
Figure 40. OntoKnowledge screenshot capture, from (Fensel, Ontology-based knowledge
management, 2002)
5.3.6. TISP/TISP++
Table Interpretation for Sibling Pages, TIPS (Embley, Liddle, & Tao, 2011) (Tao, 2008) is a tool
that, as its name suggests, interprets HTML tables embedded in sibling pages. Sibling pages are
pages in a given web site that have been generated according to the same scheme or template.
Web pages in a web catalogue are a good example of sibling pages. Tables present in this type of
pages, typically following the same presentation template, are known as sibling tables.
Page 136/214
iTEC Project
17092012.Docx
Interpreting a table consists on extracting its pattern, that is, on associating the tags defining each
category or section in the table (i.e., table headers) to cell values. For that, TISP compares sibling
tables seeking common tags and variations in data values.
In turn, TISP++ is a tool to generate ontologies with the information available in tables, from a
pattern obtained using TISP. TISP++ generates OWL classes, properties and restrictions
according to the table pattern. Each section tag in the table is represented as a class. Properties
are extracted from the pattern structure. Finally, values in tables can be easily extracted to be
represented as RDF triples using the information above.
TISP++ supports the generation of ontologies in a rapid and automated way, but only from a single
collection of sibling pages. Therefore, ontologies from different Web sites cannot be combined, and
there is no support for user-defined ontologies.
5.3.7. A semantic scraping model for web resources
Project OMELETTE (OMELETTE, 2012), supported by the EU under the 7th Framework
Programme, proposes a framework (Fernández-Villamor, Blasco-García, Angel-Iglesias, & Garijo,
2011) to perform web scraping to represent HTML content as RDF graphs. For that, RDF-based
extractors are used that support the selection of the relevant data to be extracted from web
documents. Finally, RDF graphs are constructed from those pieces of non-structured information.
The proposed extraction model consists of three levels of abstraction that ensure the integrity of
semantic scraping:
•
•
Scraping service level: brings together services making use of the extracted semantic data
(e.g., enrichers, recommenders, mash-ups). For a service to be able to fetch data from nonstructured web documents some supervision from experts is needed. In other words, to
define one of these services the steps below have to be followed:
o Identification of the data to be extracted.
o Modelling of the extracted information in RDF, that is, to define ontologies adapted
to the extraction scope supporting the semantic representation of the extracted data
according to a standard terminology.
o Generalization of the extractor through the definition of suitable configurations. This
task may be performed by a human administrator or by automated or semiautomated modules.
Semantic scraping level: defines the model that maps HTML fragments into Semantic Web
resources. This level provides semantics to the syntactic scraping in the next layer. The
mapping model is directly defined in RDF, and includes the semantic term vocabulary to be
used. This model is outlined in Figure 41. Its most relevant classes are:
o Scraper: represents an automated agent able to extract specific fragments from the
web.
o Fragment: represents any element in an HTML document.
o Selector: represents a condition to identify the associated HTML fragment.
o Mapping: represents a mapping between an HTML fragment and an RDF resource
or blank node.
o Presentation: represents how an HTML fragment is defined (i.e., attributes and
visual parameters like colour, size, font).
Page 137/214
iTEC Project
17092012.Docx
Figure 41. Mapping model for semantic scrapping, from (Fernández-Villamor, Blasco-García, AngelIglesias, & Garijo, 2011)
•
Syntactic scraping level: defines the wrapping and extraction techniques (e.g., DOM
selector) to be used by the semantic scraping level. The most relevant techniques
considered are:
o CSS selectors to map elements through visual properties.
o Visual selectors to identify visual information for node selection.
o XPath selectors to select nodes through the tag route in an HTML document.
o URI patterns to select a complete HTML document.
This framework is placed at the top of a RESTful architecture. Additional semantics and data
mappings for information scraping on top of such RESTful architecture are defined at the upper
levels of the framework. Figure 42 represents the architecture above.
Figure 42. Architecture of the Framework discussed in (Fernández-Villamor, Blasco-García, AngelIglesias, & Garijo, 2011)
Page 138/214
iTEC Project
17092012.Docx
5.3.8. THRESHER
Thresher (Hogue, 2005) is a tool enabling final users to extract the underlying semantic structures
from human-readable HTML documents, independently of content providers. Users without
technical background can tell the system what fields in a web page have some semantic meaning
by using simple samples. For that, users point out and mark in a web browser screen the relevant
properties of the HTML page being displayed. After that, the tool generalizes these samples to
generate an extraction pattern suitable for that web page or similar pages. In other words, a
wrapper is generated for the target HTML structure. Samples should always be positive examples,
i.e., indications on what not to extract are not supported. The induced pattern is obtained by
applying tree edit distance metrics to find the best mapping between samples and the DOM
structure in the target HTML. Finally, once the wrapper has been created, users should give a
semantic meaning to the extracted information. For that, users should indicate to what class each
extracted data type belongs, or which properties are described. Figure 43 captures a screenshot of
the tool where a user defines the property type represented by an HTML field (Name property).
This tool is integrated into the Haystack semantic browser (Quan, Huynh, & Karger, 2003).
Figure 43. Thresher screenshot capture, from (Hogue, 2005)
5.4. Conclusions on the wrappers discussed
This Appendix collects some of the most relevant extraction and RDF conversion tools available.
These tools support the conversion of information in databases, XML documents, and HTML
pages. These sources have been chosen because there are huge amounts of them available at
the web containing extensive and detailed information, suitable for our enrichment objectives.
Relational databases are typically used as input sources to populate knowledge bases at
repositories, as databases are commonplace for data storage in institutions and companies. As a
Page 139/214
iTEC Project
17092012.Docx
consequence, RDB2RDF approaches are most popular in this field. Besides, as databases are a
highly structured source of information, the conversion process is greatly simplified. Indeed, most
of the tools discussed support the automated generation of RDF documents, requiring no user
participation. Presently, most of these tools provide excellent results with a reduced user effort.
W3C has created a working group focused on this field, which have already generated a standard
proposal.
The conversion of XML files into RDF is a relatively simple task. It does not involve large
computation requirements or processing complexity. Nevertheless, users should actively
participate in the design of mapping patterns due to the heterogeneity of XML documents. As a
consequence, solutions supporting the direct application of transformation patterns, like GRDDL,
experienced a great success.
Conversion of HTML pages into RDF is more complex. This kind of information is of a semistructured nature, as it combines detailed human-readable information and visualization patterns.
These sources require more processing power than the previous ones. Nevertheless, HTML pages
are in many cases the only available source to obtain relevant information in a given subject. The
main drawback in this case is the need of a specific extraction pattern for each single page. User
efforts are concentrated on this task, as a badly configured pattern is prone to generate errors
along the process. For this reason, many of the frameworks discussed try to alleviate the implicit
user workload by providing visual tools.
Page 140/214
iTEC Project
17092012.Docx
6. Appendix VI: METHODS AND FRAMEWORKS FOR
RECORD LINKAGE IN RDF
We can find in the Semantic Web literature several tools and frameworks to apply Record Linkage
techniques. Although having the same objectives, namely to find in different data sources entities
referring to the same object in the real world, these tools have different strategies and working
methods. This Appendix describes relevant frameworks and tools in this field, including a brief
introduction to the methods used to attain their objective. More specifically, Section 6.2 discusses
the most relevant tools based on probabilistic methods to compute the similarity between two
entities. Previously, in Section 6.1, we briefly introduce key-based approaches to identify entities
referring to the same object in the real world.
6.1. Key-based Record Linkage solutions
Key-based solutions are applied to records where a property value represents them no matter the
underlying dataset (e.g., an ISBN number, a social security number) Under this assumption, two
entities having the same representative property (i.e., the same key) reference the same object in
the real world.
(Hogan, Harth, & Decker, 2007) describes a Record Linkage technique based on OWL inverse
functional properties (IFP). These are sub-properties of owl:InverseFunctionalProperty, owl:IFP in
short. For these properties, each value uniquely identifies their subject. As a consequence, two
entities having the same IFP value must be the same (cf. Figure 44). This technique is a key-based
approximation technique, where the key is the property value.
book_A
book_A
ISBN (owl:IFP)
xxxxxx
ISBN (owl:IFP)
publication_B
publication_B
Figure 44. Representation of an inverse functional property, from our own sources
The effective operation of this method is based on the correct definition of IFP properties.
Regretfully, dataset creators use to commit errors that cause faults and incoherencies (e.g., by
incorrectly using properties that are functional inverses by definition as they were not). This causes
many entity linking or matching errors.
Another information extraction mechanism is based on functional properties (i.e., owl:FP), which
establish that an instance’s functional property must have a single value. As a consequence, two
Page 141/214
iTEC Project
17092012.Docx
values for the same property of the same instance must be equal (cf., Figure 45). Nevertheless,
relation extraction under this premise is fairly uncommon with respect to real IFP datasets.
These mechanisms enable relation extraction in a deterministic way, that is, entities either
reference the same object or reference different objects, beyond doubts.
ZZZ
book_A
ZZZ
YYY
YYY
Figure 45. Representation of the nature of the functional property, from our own sources.
6.2. Similarity-based Record Linkage solutions
Similarity-based Record Linkage solutions are applied to records not having unique identifiers.
They are based on the comparison of properties in each entity to measure the degree of similarity
between them. These approaches may be semi-automated or fully automated.
Semi-automated approaches require a human expert to actively participate in the Record Linkage
process. Experts should define the matching heuristics in a declarative way. For that, they use
declarative languages to explicitly describe relations to be established and matching algorithms to
be applied, and their weight. Thus, these tools are known as semi-automated because they require
the active participation of a human expert.
In turn, fully automated tools use input or training data to infer the tool configuration without the
contribution of human experts. In other words, they analyse already existing relations in input data
to extract properties, heuristics and other variables to configure the matching tool. This later
process is known as self-training (Zhou & Li, 2010).
We discuss below the most relevant similarity-based tools.
6.2.1. SILK
SILK (Semantic Inferencing on Large Knowledge) is an RDF probabilistic Record Linkage tool
(Volz, Bizer, Gaedke, & Kobilarov, 2009). It fetches relations explicitly defined by an expert, that is,
it is a semi-automated tool. It supports the generation of owl:sameAs relations between two
individuals or other type of RDF links.
Relation definition is based on the SILK-LSL declarative language (SILK – Link Specification
Language) to specify the data sources and entity classes to be analysed. This language also
supports the declaration of which entity properties are relevant and which (typically syntactic)
Page 142/214
iTEC Project
17092012.Docx
comparison method among the ones available should be used to measure similarity. Besides,
experts specify other configuration parameters like thresholds, output files, matchers’ weights, etc.
Figure 46 provides an example excerpt of a SILK configuration file including some of the main
configuration sections. Sentence in line 12 defines which property is used to link analogue records
(owl:sameAs in this case); sentences in lines 13 and 18 define instance classes in each repository
to be compared (in this case, any instance in BDPedia and Tool class instances in our knowledge
base); sentences between lines 29 and 32 define for each class which properties should be
analysed and which matching heuristic should be used (in this case, values in properties rdfs:label
in classes in BDpedia and our knowledge base using the Jaro distance-based syntactic similarity
metric (Jaro, 1995)); sentence in line 51 defines the degree of similarity to consider that two
records or instances are potentially equivalent (in our case, we defined a minimum acceptance
threshold of 91%); and finally sentences between lines 53 and 60 define two output information
flows. The first one (sentences 53-56) collects instance pairs whose similarity is above the
similarity threshold (91%), but don’t reach the maximum threshold of 97%. These instance pairs
will be stored in a file with the SILK custom alignment format (i.e., it collects all similarity
information fetched by the tool for each instance pair) for the human expert to revise whether these
instances are actually equal or not. The second output flow (sentences 57-60) collects all instance
pairs whose similarity is above 97%. These instance pairs will be directly considered as coreferenced and will be stored according to the ntriples format (i.e., triples of the form (source
repository instance as subject ,configuration-defined predicate, target repository instance as
object)).
12:
13:
14:
15:
16:
17:
18:
...
29:
30:
31:
32:
...
51:
...
53:
54:
55:
56:
57:
58:
59:
60:
<LinkType>owl:sameAs</LinkType>
<SourceDatasetdataSource="dbpedia" var="a">
<RestrictTo> ?a rdf:typeowl:Thing </RestrictTo>
</SourceDataset>
<SourceDatasetdataSource="local" var="b">
<RestrictTo> ?b rdf:typeitec:Tool </RestrictTo>
</SourceDataset>
<Compare metric="jaroSimilarity" optional="1">
<Param name="tag1" path="?a/rdfs:label" />
<Param name="tag2" path="?b/rdfs:label" />
</Compare>
<Thresholdsaccept="0.91" />
<Output maxConfidence="0.97" type="file">
<Param name="file" value="itec-dbp-revision.xml"/>
<Param name="format" value="alignment"/>
</Output>
<Output minConfidence="0.97" type="file">
<Param name="file" value="itec-dbp-accept.xml"/>
<Param name="format" value="ntriples"/>
</Output>
Figure 46. Excerpt of the SILK configuration file to compare two records from different datasets
according to their properties.
The standard version of SILK produces good results, but requires the active participation of a
human expert. Experts must correctly configure the tool in the most precise and exact way. Experts
must analyse the records in each dataset to find all possible relations to adequately generate
configuration files.
Page 143/214
iTEC Project
17092012.Docx
To reduce the tool dependency from expert users and their configurations, SILK creators
developed a new feature for this tool in 2011, in the framework of European project LOD223. The
new functionality supports the automated generation of complex linkage rules from a set of
reference links using genetic programming techniques (Isele & Bizer, 2011). For that, the new
module compares multiple properties and uses data transformations for value normalization.
According to experimental results, the automatically generated linkage rules’ precision is
comparable to linkage rules generated by experts. Nevertheless, linkage rules will be generated
only from relations that can be inferred from relatively simple input data. As a consequence, this
new feature is not applicable to more specialized and complex Record Linkage processes.
6.2.2. LIMES
LIMES is a descriptive language-based framework that automatically searches and retrieves equal
entities (Ngomo & Auer, 2011). This tool supports the configuration of the process parameters in a
way similar to SILK. Its main difference with respect to SILK corresponds to the processing mode,
and more specifically in the amount of subjects in the datasets to be compared. While SILK follows
a brute force approach, that is, it compares all selected entities among them, LIMES relies on the
triangle inequality theorem to dramatically reduce the number of operations needed to obtain the
desired results. According to this theorem, many instance pairs not fulfilling the mapping conditions
can be filtered out. This way, the number of comparisons needed is reduced by several orders of
magnitude.
Input matching information consists of a source knowledge base S, a target knowledge base T, an
heuristic for the computation of the syntactical distance between two values, and a threshold value
θ reflecting the minimum distance for two entities to be considered as equal. The process of
locating equal registries in S and T has two main challenges: the computational complexity of the
matching task, and the adequate selection of the heuristic for syntactic distance computation. The
expert configuring the tool manually selects the mentioned heuristic, which will be applied to the
value of some property of instances in S and T. If the computed distance between two values in an
instance pair is less or equal than threshold θ, both instances will be considered as candidates to
be linked. As a consequence, the number of comparisons needed grows with the size of databases
S and T, which increases the computational complexity.
To reduce the computational complexity, and therefore the execution time, LIMES relies on the
triangle inequality theorem. This theorem establishes that, provided the similarity distance among
two different values x and y, m(x, y) is known, and provided we also know the distance from and to
a third value z, m(y, z), we can estimate a range for the unknown distance m(x, z). Equation 1
shows this theorem in mathematical notation, and Figure 47 depicts its graphical representation.
m(x, y) ≤ m(x, z) + m(z, y) , m(x, z) ≤ m(x, y) + m(y, z) m(x, y) - m(y, z) ≤ m(x, z) ≤ m(x, y) + m(y, z)
m(x, y) - m(y, z) >θ
m(x, z) >θ
Equation 1- Triangle inequality theorem, from (Ngomo & Auer, 2011)
23
http://lod2.eu/
Page 144/214
iTEC Project
17092012.Docx
Figure 47. Graphical representation of distance approximation based on the triangle inequality
theorem, from (Ngomo & Auer, 2011)
6.2.3. LINQUER
LINQUER (Hassanzadeh, Kementsietsidis, Lim, Miller, & Wang, 2009) is a framework for the
automated search of entities in relational databases describing the same object in the real world
(Record Linkage) to establish semantic relations.
Many semantic repositories expose information according to the Linked Data model, which in turn
is fetched from large relational databases. For that, tools like Triplify or D2RQ are used (cf.,
Appendix V). These tools support the conversion of the information available in databases into
RDF. In turn, LINQUER supports the location of equal records in relational databases. Putting all
together, both types of tools can be combined to expose the relations found as semantic relations.
Like SILK or LIMES, LINQUER is based on a declarative link specification language that experts
use to configure and define on which entities and how the matching process will be performed. In
this case, the language, LinQL, is a SQL extension integrating queries with link discovery methods.
LinQL statements are directly translated into SQL queries on a relational database according to the
LinQL2SQL algorithm. LinQL grammar is outlined in Figure 48.
According to LinQL, a link specification or linkspec defines the conditions that two given values
must satisfy for a link to be established between them. As depicted in Figure 48, a CREATE
LINKSPEC instruction defines a new linkspec taking as parameters a name for it, and the column
names whose values will be necessary to establish the link. To create that link, LINQUER offers
several native methods, including synonym, hyponym, and several string similarity functions.
Native methods may be used directly or customized according to specific parameters.
Page 145/214
iTEC Project
17092012.Docx
linkspec_stmt:= CREATE LINKSPEC linkspec_name
AS link_method opt_args opt_limit;
link_method:= native_link | link_clause_expr | UDF;
native_link:= synonym | hyponym | stringMatch;
link_clause_expr:= link_clause AND link_clause_expr
| link_clause OR link_clause_expr
| link_clause;
link_clause:= LINK source WITH target
USING link_terminal opt_limit;
link_terminal:= native_link | UDF | linkspec_name
opt_limit:= LINKLIMIT number;
Figure 48. LinQL grammar, from (Hassanzadeh, Kementsietsidis, Lim, Miller, & Wang,
2009)
6.2.4. SemMF
SemMF (Semantic Matching Framework) is an open source tool that supports the computation of
the semantic similarity between two objects represented as RDF graphs (Oldakowski & Bizer,
2005). The matching process is performed on a source RDF instance, which is compared with a
collection of instances to detect equivalent records. Initially, a source instance is compared with
each of the target instances by comparing their properties one by one. To refine and focus this
process, the user may specify some input parameters to configure the tool, namely a common
taxonomy and a matching description.
In case these instances use concepts from a common taxonomy, the system accepts as an input
parameter a representation of such taxonomy, which in turn will serve to refine the matching
process to reduce complexity.
At the same time, users may indicate which object properties are relevant for comparison using a
matching description. With this, SemMF supports the explicit definition of the most relevant
properties in the RDF graph and the relations between properties with the same semantic meaning
(e.g., rdfs:label may be mapped to dc:title in many cases). Besides, the matchers to perform the
comparisons can also be specified. All this information will also be explicitly represented in RDF
according to a specific vocabulary developed in the framework of the project. Figure 49 represents
the matching proposed by SemMF.
Matchers offered by SemMF include:
•
•
•
Taxonomy matchers: to measure the semantic similarity between two entities according to
their distance in the taxonomy.
Numeric matchers: to measure the similarity between two properties having numerical
values.
String matchers: to measure the similarity between two properties represented as literal
strings.
Page 146/214
iTEC Project
17092012.Docx
Figure 49. Representation of a matching process in SemMF, from (Oldakowski & Bizer, 2005)
6.2.5. RDF-AI
The RDF-AI framework (Scharffe, Liu, & Zhou, 2009) takes as input two RDF data sources and
produces as output a new datased including the fusion of both sources and a list of equivalent
entities in both input datasets (Record Linkage). For that, it proposes an architecture enabling the
application of any matching algorithm on RDF graphs. This architecture is composed of five
independent modules addressing pre-processing, matching, fusion, interlink and post-processing
of RDF datasets. Figure 50 offers a general overview of this architecture.
Figure 50. RDF-AI architecture, from (Scharffe, Liu, & Zhou, 2009)
Page 147/214
iTEC Project
17092012.Docx
A brief description of each module is provided below:
•
•
•
•
•
Pre-processing: Data is conditioned for further processing. For example, a materialization
process is performed to generate RDF triples not present in the dataset, like the ones
corresponding to implicit relations resulting from inverse and transitive properties.
Matching: Similarity measures among different records are performed from the preprocessed data by syntactic comparison.
Interlink: owl:sameAs triples are generated to link entities with a similarity value above the
defined threshold.
Fusion: A new graph is generated from the fusion of input graphs. The new graph
consolidates in a single entity those entities with a similarity value above the defined
threshold.
Post-processing: Results are checked to detect inconsistencies produced along the
previous processing stages.
This framework can be considered a semi-automated one, as it requires the active contribution of
experts to establish the configuration parameters (e.g., the similarity threshold). Besides, graphs
have to be entered by the user, as it does not support queries to external graphs using techniques
like SPARQL.
6.2.6. RAVEN
RAVEN (Ngomo, Lehmann, Auer, & Höffner, 2011) is a semi-automated Record Linkage
framework based on the active learning of matching rules according to training data. It is intended
to provide a linkage tool requiring less exhaustive user participation. In this case, users must
iteratively validate the rules that the tool produces. This process is performed in two stages.
1. During the first stage, the system applies a collection of algorithms to extrapolate the
Record Linkage rule specifications that can be applied. For that, source repositories are
analysed to find records linked by owl:sameAs to other records. After that, the properties of
linked record pairs retrieved are analysed to detect the ones with most similar values. This
way, Record Linkage rules can be inferred indicating that the classes to which linked
entities belong may host equivalent entities. Besides, these entities may be considered
equivalent if given property pairs have a similar value.
2. During the second stage, users are asked about the validity of assumptions inferred
according to the extrapolated rules. Specifications will be iteratively updated according to
users’ responses until a final version is obtained. This way, users do not have to analyse
the data models in datasets to extrapolate matching rules. In turn, users do determine the
final version of linkage rules.
Finally, once the final version of the rules is available, they are applied to the corresponding
datasets using LIMES (cf., Section 6.2.2). Note that RAVEN can be seen as an abstraction module
on top of LIMES supporting the generation of its configuration file, according to active learning
techniques and simple user interaction. The RAVEN algorithm is outlined in Figure 51.
ZĞƋƵŝƌĞ͗ ^ŽƵƌĐĞŬŶŽǁůĞĚŐĞďĂƐĞ<^
ZĞƋƵŝƌĞ͗ dĂƌŐĞƚŬŶŽǁůĞĚŐĞďĂƐĞ<d
&ŝŶĚƐƚĂďůĞĐůĂƐƐŵĂƚĐŚŝŶŐďĞƚǁĞĞŶĐůĂƐƐĞƐŽĨ<^ĂŶĚ<d
Page 148/214
iTEC Project
17092012.Docx
&ŝŶĚƐƚĂďůĞƉƌŽƉĞƌƚǇŵĂƚĐŚŝŶŐĨŽƌƚŚĞƐĞůĞĐƚĞĚĐůĂƐƐĞƐ
ŽŵƉƵƚĞƐĞƚƐ^ĂŶĚd͖ƌĞĂƚĞŝŶŝƚŝĂůĐůĂƐƐŝĨŝĞƌϬ͖ƚ͗сϬ
ǁŚŝůĞ ƚĞƌŵŝŶĂƚŝŽŶĐŽŶĚŝƚŝŽŶŶŽƚƐĂƚŝƐĨŝĞĚ ĚŽ
ƐŬƚŚĞƵƐĞƌƚŽĐůĂƐƐŝĨǇϮɲĞǆĂŵƉůĞƐ͖hƉĚĂƚĞƚƚŽƚнϭ͖ƚ͗сƚнϭ
ĞŶĚǁŚŝůĞ
ŽŵƉƵƚĞƐĞƚDŽĨůŝŶŬƐďĞƚǁĞĞŶ^ĂŶĚdďĂƐĞĚŽŶƚ
ZĞƚƵƌŶD
Figure 51. Rapid actiVE liNking (RAVEN) algorithm, from (Ngomo, Lehmann, Auer, & Höffner, 2011)
6.2.7. ObjectCoref&Falcon-AO
ObjectCoref&Falcon-AO (Hu, Chen, Cheng, & Qu, 2010) supports the detection of multiple URIs in
the Semantic Web referring the same object in the real world, that is, the detection of URI aliases
referring to a single object. Its implementation is based on ObjectCoref and Falcon-AO.
ObjectCoref is a tool to resolve the similarity between Semantic Web entities using a self-training
technique. It computes the matchings to be applied from a collection of input data.
In turn, Falcon-AO is an ontology alignment system. Ontology alignment is a process to define
bindings between ontologies (Li, Zhong, Juanzi, & Tang, 2007) (Hu & Qu, 2008) (Zagal Flores,
2008) (Ehrig, 2007), that is, to locate duplicate concepts, properties or records. Typically, ontology
alignment is used to unify ontologies covering complementary concepts. A more precise definition
can be found in (Li, Zhong, Juanzi, & Tang, 2007):
Ontology alignment: the ontology alignment from O1 to O2, where O1 is the source
ontology and O2 is the target ontology, is defined as the process of finding semantic
correspondences (conciliations) between concepts in O1 to O2.
ObjectCoref&Falcon-AO operation is based on the analysis of source data to find relations to infer
matching mechanisms. For that, it searches specific semantic relations in datasets (cf. Table 95).
Using these relations, it analyses properties and their values to extract information on which
classes and properties have to be compared and which weights to use for that. This algorithm is
iterative, as once relations have been obtained, they can be used to infer new, previously
undetected information between properties (e.g., if two entities refer now to the same object,
established IFP properties may have a new meaning).
Table 95. Semantic properties considered in ObjectCoref&Falcon-AO, from (Hu, Chen, Cheng, & Qu,
2010)
Property
Inference
owl:sameAs
(X, owl:sameAs, Y) => X = Y
owl:InverseFunctionalProperty
(X, owl:IFP, Y) Ʌ=RZO,)3< !; =
owl:FunctionalProperty
(X, owl:FP, Y) Ʌ;RZO)3= !< =
owl:cardinality
Depending on the actual value, IFP or FP inferences may be
performed
owl:maxCardinality
Depending on the actual value, IFP or FP inferences may be
performed
Page 149/214
iTEC Project
17092012.Docx
This framework supports the generation of new relations, ideally without user participation, from
the already established relations between different datasets. Nevertheless, in many cases datasets
are full of errors and properties are incorrectly defined, which requires an expert to provide revised,
error-free training data.
6.2.8. KnoFuss
KnoFuss (Nikolov, Uren, & Motta, 2008) proposes a KnowledgeFusion-based framework.
KnowledgeFusion is a process to integrate semantic annotations obtained from different sources. It
is a complex process requiring the application of ontology matching, Record Linkage and
inconsistence resolution techniques. In our context, we will focus on its support to Record Linkage
and related methods. These methods are based on two concepts, namely generic machine
learning techniques and instance characteristics.
The framework provides a library of matching method descriptors. A matching method descriptor
collects all information available to perform a matching process. Table 96 illustrates one of the
default descriptors to be applied to compute the similarity between instance labels when no further
information is available, the Jaro-Winkler (Jaro, 1995) heuristic in this case.
Table 96. Descriptor of a matching method in KnoFuss, from (Nikolov, Uren, & Motta, 2008)
Method
Inputs
Outputs
Tackles
Selectioncriterion
Reliability
Description
Parameters
Threshold
Label-based Jaro-Winkler matcher
SourceKnowledgeBase :typeKnowledgeBase;
TargetKnowledgeBase :typeKnowledgeBase;
MergeSets :type list of MergeSet - Set of possible mappings between instances
of source and target knowledge bases
Coreferencing
SELECT ?uri WHERE {
?uri rdfs:label ?label }
0.9
A generic method, which performs matching based on the
label similarity measured using Jaro-Winkler metrics.
0.87
These methods may be associated to a context, so that they can only be applied if specific
parameters exist and specific conditions are met in the source datasets. The automated method
selection process to be applied operates in two stages. During the first stage, the source data is
analysed to find out which parameters and concepts are present. Then, during the second stage, a
library method is selected and executed according to the parameters and concepts detected. In
case there are no methods specific to the parameters and concepts detected, default methods are
executed. In turn, if a method is applied in a context for the first time, its descriptor will be stored in
the library to be available for future occasions.
KnoFuss is able to learn new descriptors according to the already established relations between
source ontology instances. This information is known as training data. This way, if the source
ontologies include an equivalence relation between two different entities sharing some parameters,
the system is able to infer (and record for future use) that the classes to which the entities belong
may have equivalent individuals. Besides, they will be equivalent only if specific parameters from
those individuals are similar beyond a given threshold.
Page 150/214
iTEC Project
17092012.Docx
6.3. Final comments on the tools discussed
We have discussed in this Appendix some of the most relevant Record Linkage tools available to
be applied to semantic data sources. These tools support the identification of entities in external
semantic sources that are equivalent to the ones in our knowledge base because both reference
the same object in the real world. This way, we will be able to locate external records with relevant
information to enrich our knowledge base.
We have discussed two approaches to Record Linkage. The first one is a key-based approach that
can be used to obtain linked records in a deterministic way. Regretfully, most datasets do not
satisfy the conditions required for its application, namely properties to be correctly defined.
As a consequence, state-of-the-art Record Linkage tools support a probability-based approach.
This solution is based on the computation of the degree of similarity between two entities to find
out if they are equivalent. However, the effectiveness of this technique is not complete, as two
similar records may not be equivalent, or two equivalent records may not be similar enough. In any
case, results use to be quite successful.
The best results are obtained when tools are configured by a human expert to establish the
appropriate linkages. This is so because humans are better conditioned to understand the nature
of each record to establish which the key characteristics to compute similarity are. Tools requiring
experts’ participation are known as semi-automated. On the other side, fully automated tools try to
replace human participation with the analysis of training data. In this later case, the system infers
linkage rules for the general case from already linked records in training data. The main problem of
automated frameworks is their dependency from training data to learn new matching methods. If
data is not error-free or many linkages are missing, results remain poor.
Therefore, if we wish to establish high-quality links and we have experts available, the most
convenient solution would be to apply semi-automated Record Linkage solutions. In turn, if experts
are missing and/or we only need basic linkages with other datasets, fully automated tools may be a
reasonable option.
Page 151/214
iTEC Project
17092012.Docx
7. Appendix VII: ONTOLOGY VERIFICATION
The first step of ontology evaluation consists on verifying if the model defined is able to respond
the competence questions posed at the specification phase (D10.1 – Sect. 1.3.4. (Anido, Santos,
Caeiro, Míguez, Cañas, & Fernández, 2011)). For this, we had to express these questions, initially
in natural language, in some semantic query language using the defined concepts and relations. In
our case, the selected language was SPARQL, as most semantic frameworks and reasoners
support it.
Competence questions identified along the semantic model specification process developed during
the first iTEC year, now expressed as SPARQL queries, are introduced below. These queries have
been submitted to a knowledge base including the ontology and some example data that was
specifically created for these tests. Tests were supported by the SPARQL engine and query
interface provided by Virtuoso Universal Server.
Competence questions are grouped into several groups according to Sect. 3.1.4 in deliverable
D10.1 (Anido, Santos, Caeiro, Míguez, Cañas, & Fernández, 2011), namely Scenario Design
Information, Tools/Technical Settings, People, Events, Content. SPARQL queries from
competence questions referring specific elements will use the element type’s acronym (e.g., <ES>
for an Educational Scenario; <LS> for a Learning Story, etc.). In those cases where we identified
some difficulties or deficiencies after the revision and implementation of some competence
questions, we will include the corresponding remarks below the questions involved.
7.1. Scenario Design Information
SDI1
Which Learning Stories have been generated from a given Educational Scenario?
SELECT ?learning_story
WHERE {
<ES> rdf:type itec:EducationalScenario;
itec:sourceOf ?learning_story
}
SDI2
Which are the Learning Activities belonging to a given Learning Story?
SELECT ?learning_activity
WHERE {
<LS> rdf:type itec:LearningStory;
itec:hasActivity ?learning_activity
}
SDI3
Which technical requirements (Tools, Functionalities) are required for the
implementation of a Learning Activity?
SELECT ?requirement
WHERE {
<LA> rdf:type itec:LearningActivity;
itec:obligatory ?requirement.
?requirement rdf:type ?req.
FILTER (
sameTerm(?req,itec:ToolRequirement) ||
sameTerm(?req,itec:ToolSpecification)
)
Page 152/214
iTEC Project
17092012.Docx
}
SDI4
Which technical requirements (Tools, Functionalities) are essential for the
SELECT ?requirement
WHERE {
FILTER (
)
}
SDI5
Which technical requirements (Tools, Functionalities) are nice to have for the
SELECT ?requirement
WHERE {
itec:niceToHave ?requirement.
FILTER (
)
}
SDI5a
Which Applications are required for the implementation of a Learning Activity?
SELECT ?app
WHERE {
?requirement rdf:type itec:ToolRequirement;
itec:largResource ?app.
?app rdf:type itec:Application
}
SDI5b
Which Devices are required for the implementation of a Learning Activity?
SELECT ?dev
WHERE {
?requirement rdf:type itec:ToolRequirement;
itec:largResource ?dev.
?dev rdf:type itec:Device
}
SDI6
Which Person requirements are essential for the implementation of a Learning
Activity?
SELECT ?requirement
WHERE {
Page 153/214
iTEC Project
17092012.Docx
FILTER (
sameTerm(?req,itec:PersonRequirement) ||
sameTerm(?req,itec:PersonSpecification)
)
}
SDI7
Which Person requirements are recommended for the implementation of a
Learning Activity?
SELECT ?requirement
WHERE {
itec:preferred ?requirement.
FILTER (
)
}
SDI8
Which Person requirements are nice to have for the implementation of a
Learning Activity?
SELECT ?requirement
WHERE {
FILTER (
)
}
SDI9
Which Event requirements are essential for the implementation of a Learning
Activity?
SELECT ?requirement
WHERE {
FILTER (
sameTerm(?req,itec:EventRequirement) ||
sameTerm(?req,itec:EventSpecification)
)
}
SDI10
Which Event requirements are recommended for the implementation of a
Learning Activity?
SELECT ?requirement
WHERE {
FILTER (
)
Page 154/214
iTEC Project
17092012.Docx
}
SDI11
Which Event requirements are nice to have for the implementation of a
Learning Activity?
SELECT ?requirement
WHERE {
FILTER (
)
}
SDI12
Which Learning Content requirements are essential for the implementation of a
Learning Activity?
SELECT ?requirement
WHERE {
FILTER (
sameTerm(?req,itec:ContentRequirement) ||
sameTerm(?req,itec:ContentSpecification)
)
}
SDI13
Which Learning Content requirements
are
recommended
for
the
SELECT ?requirement
WHERE {
FILTER (
)
}
SDI14
Which Learning Content requirements are nice to have for the implementation
of a Learning Activity?
SELECT ?requirement
WHERE {
FILTER (
)
}
SDI15
Is a given Learning Story feasible in a given Technical Setting?
Page 155/214
iTEC Project
17092012.Docx
ASK
{
<LS> itec:feasibleIn <TS>
}
The ontology described in D10.1 – Support for implementing iTEC Engaging Scenarios V1
collects concepts and relations relevant to domain experts. Property itec:feasibleIn was
intended for internal use, and it did not appear in D10.1. In the same way, D10.1 does not
include the heuristic rules needed to assign a value to this property.
SDI16
Which Learning Activities from a Learning Story are feasible in a given
Technical Setting?
WHERE
{
<LS> itec:has Activity ?learning_activity.
?learning_activity itec:feasibleIn <TS>
}
SDI17
Is a given Learning Activity feasible in a given Technical Setting?
ASK
{
<LA> itec:feasibleIn <TS>
}
SDI18
Which technology requirements (Tools, Functionalities) are missing in a given
Technical Setting to implement a Learning Story?
SELECT ?tool
WHERE
{
<LS> itec:has Activity ?learning_activity.
?learning_activity itec:obligatory ?requirement.
OPTIONAL {?requirement rdf:type ?type;
itec:isAccomplishedWith ?tool}.
FILTER (
sameTerm(?type,itec:ToolRequirement) ||
sameTerm(?type,itec:ToolSpecification)
).
FILTER NOT EXISTS {
<TS> itec:hasTool ?tool
}
}
In the same way as property itec:feasibleIn, property itec:isAccomplishedWith is only for SDE’s
internal use, so it was not included in deliverable D10.1.
The conversion of this competence question into an expression written in a semantic query
language requires the usage of epistemic operators. Thus, we used SPARQL’s draft version
1.1. (Seaborne, et al., 2008), as it includes methods to handle negations (i.e., MINUS and NOT
EXISTS). SPARQL 1.1, even as a Working Draft, is already supported by the execution engine
used for testing (i.e., OpenLink Virtuoso).
SDI19
Which technology requirements (Tools, Functionalities) are missing in a given
Page 156/214
iTEC Project
17092012.Docx
Technical Setting to implement a Learning Activity?
SELECT ?tool
WHERE
{
OPTIONAL {?requirement rdf:type ?type;
24
itec:isAccomplishedWith ?tool}.
FILTER (
sameTerm(?type,itec:ToolRequirement) ||
sameTerm(?type,itec:ToolSpecification)
).
FILTER NOT EXISTS {
<TS> itec:hasTool ?tool
}
}
As above, we use SPARQL 1.1 to represent this competence question.
SDI20
Which Learning Activities have been selected for a LARG?
WHERE {
<LARG> itec:hasActivity ?learning_activity
}
SDI21
Which are the most used Learning Activities in LARGs generated from a given
Learning Story?
SELECT ?learning_activity COUNT(?larg) AS ?uses
WHERE {
<LS> itec:sourceOf ?larg.
?larg itec:hasActivity ?learning_activity
}
GROUP BY ?learning_activity
ORDER BY ASC (?uses)
SDI22
Which Tools have been selected for a LARG?
SELECT ?tool
WHERE {
?us rdf:type itec:UserSelection;
itec:larg <LARG>;
itec:tool ?tool
}
SDI23
Which People have been selected for a LARG?
SELECT ?person
WHERE {
itec:larg <LARG>;
24
In the same way as property itec:feasibleIn, property itec:isAccomplishedWith is for internal use only, and
was not included in the ontology.
Page 157/214
iTEC Project
17092012.Docx
itec:person ?person
}
SDI24
Which Events have been selected for a LARG?
SELECT ?event
WHERE {
itec:larg <LARG>;
itec:event ?event
}
SDI25
Which Learning Content has been selected for a LARG?
SELECT ?content
WHERE {
itec:larg <LARG>;
itec:content ?content
}
7.2. Tools & Technical Settings
T1
Which functionalities provide the tools of a Technical Setting?
SELECT ?tool ?functionality
WHERE {
<TS> rdf:type itec:TechnicalSetting;
itec:hasTool ?tool.
?tool itec:weightedFunctionality [
itec:functionality ?functionality
]
}
T1a
What is the affordance level of a Technical Setting in a certain functionality?
SELECT MAX(xsd:double(?level))
WHERE {
itec:hasTool ?tool.
itec:functionality <F>;
wo:weight_value ?level
]
}
T2
Which tools are included as part of the Local Technology of a specific Technical
Setting?
SELECT ?tool
WHERE {
idct:hasPart ?ts_lt.
?ts_lt rdf:type itec:LocalTechnology;
itec:hasTool ?tool
}
Page 158/214
iTEC Project
T2a
Which hardware devices include a specific Technical Setting?
SELECT ?hw
WHERE {
itec:hasDevice ?hw.
?hw rdf:type itec:Hardware
}
T2b
Which software applications include a specific Technical Setting?
SELECT ?sw
WHERE {
itec:hasApp ?sw.
?sw rdf:type itec:Software
}
T2c
Which shells include a specific Technical Setting?
SELECT ?shell
WHERE {
itec:hasShell ?shell.
?shell rdf:type itec:iTECShell
}
T3
Which functionalities provide a particular tool?
SELECT ?tool ?functionality
WHERE {
<T> itec:weightedFunctionality [
itec:functionality ?functionality
]
}
T3a
What is the affordance level of a tool in a certain functionality?
SELECT MAX(xsd:double(?level))
WHERE {
itec:functionality <F>;
wo:weight_value ?level
]
}
T4
Which device is required for the execution of a particular application?
SELECT ?device
WHERE {
<A> itec:requires ?device.
?device rdf:type itec:Device;
}
T4a
Which widgets can be run in a specific shell?
SELECT ?widget
WHERE {
Page 159/214
17092012.Docx
iTEC Project
17092012.Docx
?widget rdf:type itec:Widget;
itec:worksWith <S>
}
T5
Which Tools are similar to Tool T?
This competence question cannot be answered with the concepts and relations included in the
first version of the ontology (D10.1 – Support for implementing iTEC Engaging Scenarios V1).
Thus, the second version of the ontology includes concept SimilarityLevel -ToolSimilarityLevel(cf. 9.2.5).
T6
Which Technical Specification has a specific tool?
SELECT *
WHERE {
<T> rdf:type itec:Tool.
OPTIONAL {<T> dct:conformsTo ?standard}.
OPTIONAL {<T> dct:requires ?requires}
}
T6a
Which are the requirements of a specific tool?
SELECT *
WHERE {
<T> dct:requires ?requires
}
7.3. People
P1
Which are the expertise areas of a person?
SELECT ?knowledge_area
WHERE {
<P> rdf:type foaf:Person;
itec:expertise [
rdf:type itec:WeightedExpertise;
wi:topic ?knowledge_area
]
}
P1a
Which is the expertise degree of a person in a certain expertise area?
SELECT ?degree
WHERE {
itec:expertise [
rdf:type itec:WeightedExpertise;
wi:topic <EA>;
wo:weight ?degree
]
}
P2
Which are the languages spoken by a person?
Page 160/214
iTEC Project
SELECT ?language
WHERE {
itec:fluency ?language
}
P3
Which are the contact details for a particular person?
SELECT ?email ?cc ?bc
WHERE {
<P> rdf:type foaf:Person.
OPTIONAL {<P> foaf:mbox ?email}.
OPTIONAL {<P> itec:onlineContact ?cc}.
OPTIONAL {<P> itec:bussinessCard ?bc}
}
P3a
Which is the email address of the person?
SELECT ?email
WHERE {
{
foaf:mbox ?email.
}
UNION
{
itec:bussinessCard [
v:email ?e
].
?e rdf:value ?email
}
}
P3b
Which communication channels does a person have (e.g. Skype)?
SELECT ?service ?nick
WHERE {
itec:account ?cc.
?cc foaf:accountServiceHomePage ?service;
foaf:accountName ?nick
}
P3c
Which is the postal address of the person?
SELECT ?street ?postalCode ?locality
WHERE {
v:adr ?address
].
?address v:street ?street;
v:postal-code ?postalCode;
v:locality ?locality
}
P3d
In which country the person resides?
Page 161/214
17092012.Docx
iTEC Project
SELECT ?country
WHERE {
v:adr ?address
].
?address v:country ?country
}
P3e
What is the geolocation of the address?
SELECT ?latitude ?longitude
WHERE {
v:geo ?geo
].
?geo v:latitude ?latitude;
v:longitude ?longitude
}
P4
What is his/her preferred contact method?
SELECT ?method
WHERE {
itec:bussinessCard ?bc.
OPTIONAL {
?bc ?y ?z.
?z rdf:type v:Pref;
rdfs:label ?method}.
}
P5
What is the homepage of a particular person?
SELECT ?homepage
WHERE {
foaf:homepage ?homepage
}
P6
Are there any other web pages related to this person?
SELECT ?doc
WHERE {
?doc rdf:type foaf:Document;
foaf:topic <P>
}
P7
To which group a person belongs?
SELECT ?group
WHERE {
org:memberOf ?group.
}
P8
Which People are similar to Person X?
Page 162/214
17092012.Docx
iTEC Project
17092012.Docx
Thus, the second version of the ontology includes concept SimilarityLevel –
PersonSimilarityLevel- (cf. 9.2.5).
P9
Who are the friends of person X taking into account the relationships in existing
networks?
SELECT ?person
WHERE {
<X> rdf:type foaf:Person;
foaf:knows ?person.
}
P9a
Which persons does a given person trust?
SELECT ?person
WHERE {
itec:trust [
wo:weight_value ‘X’^^xsd:double;
itec:trustedAgent ?person
]
?person rdf:type foaf:Person
}
7.4. Events
E1
What are the subjects of an event?
SELECT ?subject
WHERE {
<E> rdf:type itec:Event;
dct.subject ?subject
}
E2
Which are the languages of an event?
SELECT ?language
WHERE {
dct.language ?language
}
E3
Which is the location of an event?
SELECT ?latitude ?longitude
WHERE {
event:place [
geo:lat ?latitude;
geo:long ?longitude
]
Page 163/214
iTEC Project
17092012.Docx
}
E4
Which are the technology requirements needed to attend an event?
SELECT ?requirement
WHERE {
itec:obligatory ?requirement
}
E5
Is the event X on-line or face-to-face?
This competence question cannot be answered in a simple and concise way using the
concepts and relations included in the first version of the ontology (D10.1 – Support for
implementing iTEC Engaging Scenarios V1). Thus, the second version of the ontology includes
concepts itec:OnlineEvent and itec:PhysicalEvent (cf. 0).
E6
Is the event X free of charge?
Thus, the second version of the ontology defines the relation itec:cost (cf. 9.3.1).
E7
Which people are going to participate in an event?
SELECT ?person
WHERE {
itec:participant ?person
}
E8
What learning content is going to participate in an event?
This competence question has been removed because it is beyond the scope of the ontology.
E9
Which events are similar to event X?
Thus, the second version of the ontology includes concept SimilarityLevel –
EventSimilarityLevel- (cf. 2.3.2.5).
E10
Who likes a particular event?
Page 164/214
iTEC Project
17092012.Docx
SELECT ?person
WHERE {
<E> rev:hasReview ?review.
?review rev:rating ?rating;
rev:reviewer ?person.
FILTER (?rating>LIKE_THRESHOLD)
}
7.5. Content
The first version of the ontology (D10.1 – Support for implementing iTEC Engaging Scenarios V1)
does not define any of the concepts or relations on Learning Content, as there was no reference to
them in the DoW. The decision was to use a RDF binding for the LRE data model. This binding
was performed in spring 2012 and how will be used by the SDE to provide recommendations is still
open in the project. As a consequence, the first version cannot answer any of the competence
questions related to content. To overcome this situation, we defined concept itec:LearningContent
and its relations (cf. 9.2.4).
C1
What are the subjects of a learning content?
C2
Which are the languages of a learning content?
C3
What are the features for a particular content?
C3a
What is the location of a content?
C4
Which tools are needed to execute a content?
C5
Which learning contents are similar to learning content X (ordered according
similarity)?
C6
Who likes a learning content?
Page 165/214
iTEC Project
17092012.Docx
8. Appendix VIII: SDE API PRE-TESTING AND
DEVELOPERS USER INTERFACES
This appendix introduces the user manual of the Web interfaces developed for SDE pre-testing
and to support developers using the SDE-API. These interfaces have already been described in a
general way, attending to implementation decisions, in D10.2 (Sect. 1.3.2).
8.1. Developers’ user interface
The developers’ user interface is intended to provide information about the SDE-API and to
support the testing of its functionalities by system developers wishing to integrate those
functionalities. This interface is available at:
http://itec.det.uvigo.es/itec-sde/apidoc/index.html
Figure 52 depicts the Web interface’s main page. Options available are listed in a menu-like panel
to the left. The upper part includes entries offering general information about the API’s usage:
authentication, JSON ROC method invocation, JSON schema formats and the tools available for
their validation and processing, and API error codes. Then all API methods are grouped in two
categories, namely Technical Localisation and Resource Planning. Methods related to Validation
are included in this later category. Each entry offers specific information about the corresponding
method.
Figure 52. Main page of the developers’ interface
Page 166/214
iTEC Project
17092012.Docx
Figure 53 provides as an example the information provided for the description of method
GetFeasibleLearningStories. This information is provided at the central area of the interface.
Firstly, the description of the method’s functionality is provided together with the results of method
invocation and JSON-RPC input parameters. Then, some examples of the JSON schemes are
provided, both for requests and responses (the figure includes an excerpt of a response), together
with links to perform the corresponding example’s invocation and to edit a request to be processed
by the SDE. This way, it is possible to test API methods at will. Finally, the errors that may be
returned as a result of method invocation are listed (not seen in the figure). The complete
description of all API methods may be obtained through the URL provided above. All methods are
presented according to the structure just discussed.
Figure 53. Detailed information provided by the developers’ interface about method
GetFeasibleLearningStories
Page 167/214
iTEC Project
17092012.Docx
8.2. Pre-testing user interface
This interface has been deployed to support the testing of SDE API method’s implementation. It is
possible to provide all input parameters in a simple way according to a succession of structured
steps, and to visualize results of method execution. This interface is not intended for final users
(e.g., teachers or National Coordinators). Final users will benefit from SDE functionalities through
the Composer’s user interface, which in turn invokes the methods included in the SDE API. The
pre-testing interface is available at:
http://itec.det.uvigo.es/ext/javi/demo/pilot/
This interface is organized into three main parts corresponding to the three groups of SDE
functionalities (cf., Figure 54), that is, technical localisation, resource planning and validation. The
main page provides access to these three groups, and also includes an introductory text describing
the nature and purpose of the application. At this time, a notice is included indicating that the data
available for testing is not real data. Nevertheless, Learning Activities and Learning Stories
developed by WP3 along cycles 1, 2 and 3 and used in the pilots driven by WP4 have been also
included. Real data was included from the EUN’s LRE and from the WP8’s Widget Store that made
available some initial information about the widgets stored. As these Learning Activities do not
include requirements on people and events, WP10 has added some of these requirements to test
the methods related to these two resource types.
Figure 54. Main page of the SDE pre-testing interface.
Page 168/214
iTEC Project
17092012.Docx
The figure shows at the upper part of the screen a text statement discussing the experimental
character of both the interface and the testing data. Below this text, the three SDE functionality
groups are presented. The main page also includes at the upper left part a menu providing access
to these groups. This menu is active at all times. Similarly, the upper right part provides access to
the functionalities available within the active group. Thus, users may access any functionality at
any time using the upper menus. Once a functionality has been selected, the central part of the
screen will present the steps and forms to be filled in to invoke the corresponding SDE methods.
The last step will consist on the actual method invocation and the presentation of results.
The interface is intended to be self-explanatory for those familiar with iTEC technical concepts, so
buttons have been included to provide information and definitions of key iTEC elements. Concepts
like Technical Setting or Learning Activity have a particular meaning within iTEC that the interested
user may obtain through the information pop-up windows included in designated points of the
interface.
We describe along the next sections the interfaces developed to provide access to all of the
methods offered by the SDE. Within each functionality group, the corresponding main page
includes a description of each of the functionalities available.
8.2.1.Technical Localisation
The Technical Localisation functionality group is primarily targeted to provide information about
which LSs and LAs may be developed in a set of schools (i.e., the role of National Coordinators).
These functionalities inform about the technical suitability of a school’s TS to satisfy the technical
requirements defined for each LS and LA. The eventual response will be a binary one (i.e., yes /
no), but it will be accompanied by indications on the number of technical requirements fulfilled and
the specific LAs that can be satisfied. This will offer some orientation to the final user in case that a
completely satisfactory solution cannot be provided.
Figure 55 depicts the main page of this functionality group.
Figure 55. Page offering a list of Technical Localisation functionalities
Page 169/214
iTEC Project
8.2.1.1.
17092012.Docx
Functionality “Assess Technical Feasibility” checks if a Learning Story can be implemented in a
given Technical Setting. To invoke this functionality, a LS and/or a collection of LAs and a TS has
to be introduced. Besides, an optional parameter may be provided to declare a minimum
satisfaction level for the technical requirements. This value will override the values included in LAs.
As pointed out above, the selection/introduction of these parameters is organized as a series of
steps organized into tabs. The transition from one tab to the next one is disabled until all the
required parameters in a given step have been introduced. This system of tabs and steps is
common to all methods, although the number of steps and tabs will depend on each specific
method being tested. In any case, for the sake of brevity, we will only describe in a detailed way
each of the steps/tabs of this first command. When describing further commands’ tabs/steps, we
will reference the description provided immediately below, and we will enumerate the differences.
The first tab in command “Assess Technical Feasibility” facilitates the selection of a LS (cf., Figure
56). A list of available LSs is provided for the user to make a selection and to explore the
properties of the LS and its LAs, including their requirements. This way, access to information on
iTEC’s LAs and LSs is greatly simplified, particularly for users not familiarized with them.
Figure 56. Selecting a Learning Story (step 1) in method “Assess Technical Feasibility”
The second tab enables the selection of a TS (cf., Figure 57). As in the previous case, a list of TSs
is provided both to select one of them and to explore their properties and tools if desired. When
accessing information about a TS, a list of its tools and applications is provided, together with
detailed information about them.
The third tab enables an optional step to specify a minimum value for the requirements’ satisfaction
level (cf., Figure 58). LAs include technical requirements defining required features and the level at
which these features have to be supported by tools. This way, it is possible to alter this value to
Page 170/214
iTEC Project
17092012.Docx
use a stricter or a more relaxed one. A displacement bar that intuitively shows the desired
satisfaction level facilitates the specification of such value.
Figure 57. Selecting a Technical Setting (step 2) in method “Assess Technical Feasibility”
Figure 58. Selecting the minimum level (step 3) in method “Assess Technical Feasibility”
The last step enables the invocation of the corresponding method at the SDE. This action is
performed by clicking a button to the right of the interface. The central part will show a summary of
the previous steps. Just above the invocation button all the parameters selected along the previous
steps will be displayed for users’ convenience. This information is also present along the previous
steps, and it is incrementally completed as the users select parameters at each step. Finally, a
reset button is also available to delete the parameters provided so far, which will also drive the
user to the first step of input parameters’ selection.
Page 171/214
iTEC Project
17092012.Docx
The SDE method is invoked upon clicking the run button. Once the SDE returns the corresponding
results, they are presented to the user. Result presentation is performed iteratively (cf., Figure 59).
As a first approach, the interface will display general results on LS feasibility, and on the feasibility
of their LAs and the degree of fulfilment of their technical requirements (i.e. individual LAs are
listed together with their feasibility status). Then, the user may explore in detail each LA if desired,
either by exploring the tools available in the TS to satisfy the technical requirements, or by listing
the technical requirements that cannot be satisfied.
Figure 59. Presentation of results (step 4) in method “Assess Technical Feasibility”
8.2.1.2.
Method “Get Feasible Learning Stories” checks which Learning Stories can be implemented in a
specific Technical Setting. The first step consists of selecting a TS using the same tab as in step 2
of method “Assess Technical Feasibility”. The second step consists on the selection of a set of
LSs25. Although the tab in this case and in the previous one are practically the same, here it is
possible to select several LSs or even all LSs available using a check-box (cf., Figure 60).
The third and last step/tab is the one enabling SDE method invocation. The only differences with
respect to the previous case are in the presentation of results. Now, only general feasibility results
are presented, classified into two groups, namely feasible LSs and non-feasible LSs. For each LS,
the interface displays the percentage of feasible LAs and the percentage of satisfied requirements.
25
A single LS may also be selected. However, the results obtained in this case would be the same as the
results of method “Asses Technical Feasibility “above.
Page 172/214
iTEC Project
17092012.Docx
Figure 60. Selecting a Learning Stories (step 2) in method “Get Feasible Learning Stories”
8.2.1.3.
Get Suitable Technical Settings
Method “Get Suitable Technical Settings” checks the feasibility of a Learning Story according to a
list of Technical Settings. The first step consists on the selection of a LS using the same tab as in
step 1 of method “Assess Technical Feasibility”. The second step consists on the selection of a set
of TSs26. Although the tab in this case and in step 2 of method “Assess Technical Feasibility” are
practically the same, here it is possible to select several TSs or even all TSs available using the
provided check-box.
The third and last step/tab is the one enabling SDE method invocation. Again, general feasibility
results are presented (cf., Figure 61). For each TS, the interface displays the percentage of
feasible LAs and the percentage of satisfied requirements.
8.2.2.Resource Planning
The Resource Planning functionality group collects SDE methods offering recommendations to
teachers interested in the implementation of a LS or a set of LAs. For that, the SDE offers several
methods to facilitate LARG creation. These methods offer recommendations on the resources
available at the SDE’s Knowledge Base that best satisfy the requirements of the LSs, taking into
account the properties of the particular context indicated by the teacher. Several methods have
been developed to provide this functionality. Some of them are driven by the LSs/LAs (“Create
LARG” and “Recommend” methods) and are intended to be used for LARG creation. Other
methods are oriented to general resource identification, without referencing any particular LS/LA.
These later methods are intended to freely explore the SDE Knowledge base.
26
Again, a single TS may also be selected with the same results as above.
Page 173/214
iTEC Project
17092012.Docx
Figure 61. Presentation of results in method “Get Suitable Tecchnical Settings”
8.2.2.1.
Create LARG
This method provides as a result the selection of the most suitable resources to satisfy the
requirements of a set of Learning Activities, and automatically creates a preconfigured LARG to be
used by the teacher. If the requirements of the Learning Activities cannot be fulfilled using the
resources available, a report on the degree of fulfilment of each requirement is returned, including
the reasons why they are not satisfied.
Figure 62. Providing metadata (step 1) in method “Create LARG”
Page 174/214
iTEC Project
17092012.Docx
The first step in this case requires a name and a description for the LARG to be created (cf., Figure
62). The user may also provide a previously created LARG to be explored or modified. In this later
case, as shown in the figure, the tabs will be pre-loaded with data from the selected LARG. The
user may then re-create the LARG or modify the parameters in the different tabs/steps to create a
new LARG based on the initial one.
If a new LARG is created from scratch, the second tab/step requires the selection of an LS in the
same way as the first tab/step of method “Assess Technical Feasibility” (cf. Figure 63). After that,
the third tab/step requires a TS in the same way as step 2 in the mentioned method (cf. Figure 64).
Figure 63. Selecting a Learning Story (step 2) in method “Create LARG”
Figure 64. Selecting a Technical Setting (step 3) in method “Create LARG”
Page 175/214
iTEC Project
17092012.Docx
The fourth step requires the definition of a LARG context (cf., Figure 65). The LARG context is
composed of a collection of properties defining a framework for the implementation of the selected
LS. This step is optional, and the properties that may be defined are:
•
•
•
•
•
Audience: age of the students to whom the LARG is targeted.
Education level: the educational level corresponding to the LARG.
Date range: expected starting and ending dates for this LARG.
Language: languages to be used in the LARG.
Subject: knowledge field of the LARG.
To assign values to these properties the user must utilize terms from iTEC vocabularies (i.e., the
ones obtained by WP4 from VBE (EUN, 2012)). From each field, zero, one, or several values may
be introduced. SDE recommendations will provide more relevance to the resources (content,
event, people and tools) that better comply with the specified properties.
The next step enables the invocation of the corresponding method at the SDE. Result presentation
is performed iteratively. As a first approach, the interface will provide a general indication telling the
user if there are resources available that will fulfil all the requirements included in LAs. A listing of
the LAs is also provided. Then, the user may explore in detail each LA if desired to see which
requirements are satisfied by which resources, according to the SDE. If no suitable resources are
found, no resource will be displayed. In any case, the user may add or modify the resources
displayed or remove the resources assigned to satisfy each of the requirements. In method “Create
LARG”, the SDE selects the first resource in the list of recommended resources, but the system
provides access to the recommendation list to modify that selection. Figure 66 illustrates this
possibility in the case of a requirement on people. Here, the user may select an expert different to
the one selected by the SDE as the first option. If a requirement is replicated in several LAs, the
system will ask the user whether the proposed change should be propagated to these other LAs in
the LARG. This way, the user has complete freedom to configure a LARG independently of the
SDE recommendation. Finally, the user may click on button “Save LARG” to save the generated
LARG.
Figure 65. Selecting a LARG Context (step 4) in method “Create LARG”
Page 176/214
iTEC Project
17092012.Docx
Figure 66. Presentation of results (step 5) in method “Create LARG”
8.2.2.2.
Recommend Methods
The SDE includes a collection of methods to provide recommendations on tools (from a particular
Technical Setting) and other resources that can be used to satisfy the requirements of a set of LAs
for a LARG under a specific LARG Context. These methods are “Recommend Resources”,
“Recommend Tools”, “Recommend Events”, Recommend People” and “Recommend Learning
Content”. The operation of these methods is similar to the previous case, the only difference being
that now the system will not select any resource for each requirement, but will offer a list of
recommended resources. An additional step/tab is also included before the last step to define the
number of recommended resources expected for each requirement (cf., Figure 67). By default, the
number of recommended resources is 10.
Figure 67. Selecting the maximum number of results (step 5) in “Recommend” methods.
Page 177/214
iTEC Project
17092012.Docx
This way, the user may obtain recommendations of a specific type. Figure 68 illustrates the results
for method “Recommend Tools”. Note the pop-up window displayed for the user to select
resources either from the list of recommended resources, from the specified TS, or from the
collection of iTEC widgets. This functionality is not provided by the SDE, but it is a feature to show
that teachers eventually have the final word. They may decide to pick up recommendations from
the SDE (not necessarily the first one) or pick up resources from other sources to implement their
LSs.
Figure 68. Presentation of results (step 6) in method “Recommend Tools”
8.2.2.3.
Search Methods
The interface provides access to search methods for each type of resource. These methods
perform queries to the SDE KB without considering requirements from the reference LSs/LAs.
These methods are “Search Tool”, “Search Person”, “Search Event” and “Search Learning
Content”. Each of these methods provides sorted lists of resources (tools, persons, events,
learning content) that satisfy all the resource (technology, person, tool, content) requirements
defined exclusively by the user. The returned list is created in accordance with the semantic
knowledge and rules of the iTEC SDE.
The steps to be completed to invoke these methods from the interface are always the same
independently of the type of resource (cf., Figure 69). First, the user defines the requirements of
the resource to search. Then, the user optionally indicates the maximum number of results to be
returned. Finally, the method is invoked and the results are provided to the user. The “Search Tool”
method includes an additional intermediate step to select one or several TSs, as in step 2 of
method “Get Suitable Technical Settings” (cf., Figure 70). This way, the search is restricted to the
selected TS.
Requirement specification in step 1 depends on the type of resource being sought. In method
“Search Event” the search criteria below may be defined (cf., Figure 69):
•
Subject. The subject of the event.
Page 178/214
iTEC Project
•
•
•
•
•
•
•
•
•
17092012.Docx
Based near address or latitude/longitude. The geographical location of the event, either as
a postal address (complete or partial) or its geographical coordinates.
Has cost. Whether participation in the event is free or payment is required.
Audience. Age range to which the event should be targeted.
Education level. Intended educational level of the event.
Languages. Languages that may be used.
Rating. Other users’ perception about the (e.g. quality) of the event.
Type. Available types are: community event, conference, workshop, virtual meeting,
seminar, school event, in-service training, hot-seat.
Keywords. Keywords describing the event.
Dates (start and end). Event’s celebration dates.
Figure 69. Overview of method “Search Event”
Method “Search Tool” expects the search criteria below (cf., Figure 70):
•
•
•
•
•
•
•
•
•
•
Functionality. Features and the extent to which they are supported. Any functionality
available in iTEC may be specified.
Has cost. Whether tool usage is free or (license) payment is required.
Audience. Age range to which the tool should be targeted.
Education level. Intended educational level of the tool.
Languages. Languages that may be used by the tool.
License. Type of license that may be used to distribute the tool.
Rating. Other users’ perception about the (quality, usability, etc.) of the tool.
Format. Formats supported by the tool, as MIME types.
Type. Two types are supported: application and device.
Keywords. Keywords describing the tool.
Method “Search Person” expects the search criteria below (cf., Figure 71):
•
Expertise. Fields of knowledge, competence or skills of the person sought.
Page 179/214
iTEC Project
•
•
•
•
•
17092012.Docx
Based near address or latitude/longitude. The geographical location of the person, either as
a postal address (complete or partial) or as geographical coordinates.
Rating. Other users’ perception about the (quality, skills, etc.) of the person.
Person type. Expert, parent, teacher, etc.
Role. Role the individual sought should play within an organization.
Keywords. Keywords describing the person.
Figure 70. Overview of method “Search Tool”
Figure 71. Overview of method “Search Person”
Method “Search Learning Content” expects the search criteria below (cf., Figure 72):
•
•
Subject. The subject of the content.
Audience. Age range to which the content should be targeted.
Page 180/214
iTEC Project
•
•
•
•
17092012.Docx
Education level. Intended educational level of the content.
Languages. Languages used.
Rating. Other users’ perception about the (e.g., quality) of the content.
Type. There are more than 20 types available, like application, assessment, audio, image,
presentation, etc.
Figure 72. Overview of method “Search Learning Content”
The presentation of results is performed similarly in all search methods. Figure 73 shows an
example of method “Search Tool”. A list is displayed including the name and short description of all
resources found.
Figure 73. Presentation of results in method “Search Tool”
8.2.3.Validation
This group of methods is intended to check if a LARG includes the resources needed to satisfy all
the requirements in its LAs, according to the characteristics and limitations of the associated LARG
context. A method is provided to validate a LARG taking into account all the requirements, and
separate methods are also provided to selectively validate each type of resource.
Page 181/214
iTEC Project
8.2.3.1.
17092012.Docx
Validate LARG
This method analyses if the current selection of tools and other resources satisfies the
requirements of a set of LAs included in a LARG under a specific LARG Context.
To invoke this method, the user should select a previously created LARG. Validation results are
iteratively displayed (cf., Figure 74). First, a global validation result is provided, indicating if the
LARG includes enough resources to satisfy all the requirements, and a list of LAs. Then, the user
may consult each LA to check whether its requirements are satisfied. Requirements are classified
according to the type of resource, namely Technical Requirements, People Requirements, Event
Requirements and Content Requirements.
8.2.3.2.
Selective Validation Methods
This group collects methods to analyse if a LARG satisfies the (technology, person, event, content)
requirements of a set of Learning Activities included in a LARG under a specific LARG Context.
Invocation of these methods is similar to “Validate LARG” above. The user selects a LARG to be
validated, the method is invoked, and results are displayed to perform an iterative analysis of them.
In this case, only the requirements related to the specific type of resource are displayed.
Presentation of results is also similar to the previous case. Figure 75 shows an example where
several LAs with resources fully or partially satisfying their technological requirements are
displayed.
Figure 74. Presentation of results in method “Validate LARG”
Page 182/214
iTEC Project
17092012.Docx
Figure 75. Presentation of results in method “Analyse Technology
Page 183/214
iTEC Project
17092012.Docx
9. Appendix IX: DETAILS OF THE ONTOLOGY UPDATE
9.1. Ontology Updates
Ontologies are living artefacts that must be continuously revised and updated along its life cycle.
Aware of this fact, the main methodologies in the field of Knowledge Engineering consider the
periodical maintenance of the relations and concepts included in a conceptualization as discussed
in D10.2 (Sect. 2.1). WP10 follows the recommendations provided by these guides, and includes in
its work plan two specific tasks, T10.1.4 and T10.2.4, devoted to perform a continuous revision of
the models developed along the complete project’s life cycle, refining them to be adapted to the
new functional requirements identified in each project iteration.
This appendix discusses the main changes introduced in the semantic models developed along the
first year (cf., D10.1, Sect. 3 (Anido, Santos, Caeiro, Míguez, Cañas, & Fernández, 2011)). These
changes are consequence of the new requirements identified by Control Boards, agreements
among project partners, and design considerations that eventually will facilitate the development of
SDE’s software modules. Due to the extension of the semantic model, we decided to document
these changes in an incremental way. According to this approach, this section only collects new
classes and/or properties, and also those that experienced some modification with respect to the
base model introduced in D10.1. Please refer to both documents to gain a full insight of the
system’s model.
Changes made are discussed in this section according to three broad categories:
•
•
•
Additions – new concepts and/or instances added to the Knowledge Base.
Updates – modifications in the meaning of concepts and/or associated properties.
Deletions – removal of concepts and/or instances from the Knowledge Base.
To improve the readability of this section, each documented change is presented according to its
context, that is, to the corresponding element’s functional group (e.g., description of people,
events) Besides, an explanation of the reasons of especially relevant updates is also provided.
9.2. Additions
9.2.1. ICT Competences
We included the possibility to take into account the information available about teachers’
competences when providing recommendations, mainly about tools, on the resources that
teachers may use to realize a Learning Activity. WP10 took as a starting point the competence
framework defined by WP4 to generate a formal semantic model enabling the characterization of
skills and aptitudes of individuals. The developed representation is inspired by the design
principles of the IMS-RDCEO specification (IMS-GLC, 2002). Specifically, the terms and properties
below have been included in the semantic model27.
27
WP10 directly contributed to the work performed by WP4 concerning the identification of an
appropriate model for teachers’ competences and tagging of Learning Activities and Learning
Page 184/214
iTEC Project
17092012.Docx
Table 97. Subclass itec:ICTCompetence in the semantic model
itec:ICTCompetence
Context
Miscellaneous Artefacts
Description
The skills of a person related to the use of information technologies.
Subclass Of:
skos:Concept
SUMO Mapping
SubjectiveAssessmentAttribute (s)
Relations
skos:prefLabel – Competence’s short name.
skos:definition – Description of the skills or abilities included in the
competence.
itec:model – An identifier of the model or structure upon which the
definition of the competence is based.
skos:broader – Indicates that the competence is a part of a broader
one.
skos:narrower – Indicates that the competence includes one or more
specific competences.
Table 98. Subclass itec:ICTWeightedCompetence in the semantic model
itec:ICTWeightedCompetence
Context
Description
Assigns a relative degree to the skills a person has related to the use of
information technologies.
Subclass Of:
wo:Weight
Note:
To model users’ competences we follow the same design pattern as for
itec:WeightedFunctionality and itec:WeightedTrust.
Relations
wo:weighted_value – Level of skill an individual declares to hold in
relation to a given competence.
wo:scale – Range of values for the ICTWeightedCompetence. It is
Stories with “required” and “to-achieve” competences”. The current proposal is based on the
UNESCO framework (UNESCO & Microsoft, 2011). This work is reflected in the corresponding
updates of the ontology. Nevertheless, the use of competence information has a number of
implications for other work packages, and therefore the decision to proceed with technical
implementation will be taken as part of the planning for the third year of the project.
Page 185/214
iTEC Project
17092012.Docx
defined as a maximum value, a minimum value, and a step_size.
itec:ICTcompetence – Competence on which the person declares to
hold a certain level of skill.
The actual competence vocabulary to be used in the framework of this project is being developed
by WP4. Presently, and according to the indications of this work package, an instance:
“ICTGeneralCompetence” has been created to provide a value between 1 and 5 to the level of ICT
knowledge an individual has.
Figure 76. Subclasses and relationships to include competences in the semantic model
9.2.2. Social Annotation
The general architecture of the iTEC project provides support to a scenario where users may
collaborate to describe the universe of discourse. This way, users may collaboratively add tags and
assessments on system resources. The SDE will gain access to this information to take the most
of Web 2.0 and 3.0 technologies according to a hybrid approach, where resources are dynamic
entities that evolve according to the descriptions provided by their own users. The SDE data model
supports this functionality through the SocialAnnotation concept:
Table 99. Subclass itec:SocialAnnotation in the semantic model
itec:SocialAnnotation
Context
Miscellaneous Artifacts
Description
Keeps a record with social information provided by a user about a resource
(tags, like/dislike, etc.)
SUMO Mapping
Report (s)
Page 186/214
iTEC Project
Relations
17092012.Docx
ǣȂǤ
ǣȂǤ
ǣȂǤǡǡǡ
ǡǡǤ
ǣȂȋǤǤǡȌǤ
ǣ Ȃ ȋ Ȍ
Ǥ
Figure 77. Subclasses and relationships to include Social Annotations in the semantic model
Table 100. Subclass itec:Tag in the semantic model
itec:Tag
Context
Description
Label describing a given system resource.
ǣȂǤ
ǣȂǤ
ǣ Ȃ
Ǥ
Relations
9.2.3. Events
Two new classes have been added to the Event group: itec:OnlineEvent and itec:PhysicalEvent.
This way, we can now discriminate between both types of events.
Page 187/214
iTEC Project
17092012.Docx
9.2.4. Learning Content
An initial semantic model has been generated to characterize the main properties of a learning
content. This model has been designed according to the LRE’s information representation
mechanisms. Note that LRE is the ultimate source of iTEC’s content data.
Table 101. Subclass itec:LearningContent in the semantic model
itec:LearningContent
Context
Description
Piece of learning content that may be utilized as a resource to implement a
Learning Activity.
Subclass Of:
itec:Resource
ǣȂǯǤ
ǣȂǤ
ǣȂǤ
ǣȂǤ
ǣȂǤ
ǣȂǯǤ
ǣȂǤ
ǣȂȋȌǤ
ǣ Ȃ ǡ
Ǥ
Relations
9.2.5. Resource similarity analysis
The SDE computes the degree of similarity between resources according to its enriched
descriptions. Using this information, it is possible to provide recommendations on resources similar
to a given one identified as a Learning Activity requirement. Class itec:SimilarityLevel provides
support to this information, and facilitates real-time queries on resource similarity.
Table 102. Subclass itec:SimilarityLevel in the semantic model
itec:SimilarityLevel
Context
Description
A value reflecting the degree of similarity between two resources, as computed
by the SDE.
ǣȂǤ
ǣȂǤ
ǣǡǣǡ
ǣǡǣ
Relations
Subclasses
Page 188/214
iTEC Project
17092012.Docx
9.2.6. Vocabularies
When the first version of the semantic model was developed, a consensus on the vocabularies to
describe functionalities, person types, events, etc. had not been reached yet. The present model
includes vocabularies to be used within the project, which are collected in the VBE (Vocabulary
Bank for Education28). For each concept, all the information available at the VBE is retrieved. Each
vocabulary’s base URI is composed by the URI of the iTEC’s ontology (represented by the term
<itec>29), suffix “/vocabularies/”, and the name of the selected scheme. We introduce below the
instances added to the model:
Table 103. Audience vocabulary
Audience Schema (itec:Audience)
base URI <itec>/vocabularies/Audience#
Element
URI
"1"
<itec>/vocabularies/Audience#1
"2"
"3"
"4"
"5"
"6"
"7"
"8"
"9"
"10"
"11"
"12"
"13"
"14"
"15"
"16"
28
http://europeanschoolnet-vbe.lexaurus.net/vbe/
29
En la actualidad el namespace de la ontología es http://itec.det.uvigo.es/itec
Page 189/214
iTEC Project
"17"
"18"
"19"
"20"
"21"
"22"
"23"
"24"
">50"
"25"
"26"
"27"
"28"
"29"
"30-35"
"36-39"
"40-49"
Table 104. KnowledgeArea vocabulary
KnowledgeArea Schema (itec:KnowledgeArea)
base URI <itec>/vocabularies/KnowledgeArea#
Element
URI
"art"
<itec>/vocabularies/KnowledgeArea#91
"astronomy"
"biology"
"chemistry"
"citizenship"
"classical languages"
"cross-curricular education"
"culture"
Page 190/214
17092012.Docx
iTEC Project
"economics"
"educational administration"
"environmental education"
"ethics"
"European studies"
"foreign language"
"geography"
"geology"
"health education"
"history"
"home economics"
"informatics/ICT"
"language and literature"
"law"
"mathematics"
"media education"
"music"
"natural sciences"
"philosophy"
"physical education"
"physics"
"politics"
"pre-school education"
"primary education"
"psychology"
"religion"
"school-community relationship"
"social sciences"
"special (needs) education"
"technology"
Page 191/214
17092012.Docx
iTEC Project
17092012.Docx
Table 105. Educational Level vocabulary
Educational Level Schema (itec:EducationalLevel)
base URI <itec>/vocabularies/EducationalLevel#
Element
URI
"compulsory education”
<itec>/vocabularies/EducationLevel#compulsory.education
"continuing education"
<itec>/vocabularies/EducationLevel#continuing.education
"distance education"
<itec>/vocabularies/EducationLevel#distance.education
"educational administration”
<itec>/vocabularies/EducationLevel#educational.administration
“first stage of tertiary education"
<itec>/vocabularies/EducationLevel#5
"higher education"
<itec>/vocabularies/EducationLevel#higher.education
"library"
<itec>/vocabularies/EducationLevel#library
"lower secundary or second stage of basic
education"
"other"
<itec>/vocabularies/EducationLevel#other
"policy making"
<itec>/vocabularies/EducationLevel#policy.making
"post-secondary non-tertiary education"
"pre-primary education"
"pre-school"
<itec>/vocabularies/EducationLevel#pre-school
"primary education or first stage of basic
education"
"professional development"
<itec>/vocabularies/EducationLevel#professional.development
"second stage of tertiary education"
"special education"
<itec>/vocabularies/EducationLevel#special.education
"vocational education"
<itec>/vocabularies/EducationLevel#vocational.education
"(upper) secondary education"
Table 106. Event Type vocabulary
Event Type Schema (itec:EventType)
base URI <itec>/vocabularies/EventType#
Element
URI
"community event"
<itec>/vocabularies/EventType#4
"conference"
Page 192/214
iTEC Project
"hot seat"
"in-service training"
"other"
"school event"
"seminar"
"virtual meeting"
"workshop"
Table 107. Event Place vocabulary
Event Place Schema (itec:EventPlace)
base URI <itec>/vocabularies/EventPlace#
Element
URI
"aquarium"
<itec>/vocabularies/EventPlace#1
"art museum"
"classroom"
"garden"
"history museum"
"home"
"movie theatre"
"other"
"park"
"performing arts venue"
"planetarium"
"playground"
"school campus"
"science museum"
"stadium"
"street"
"university campus"
"virtual"
Page 193/214
17092012.Docx
iTEC Project
"zoo"
17092012.Docx
Table 108. Functionality vocabulary
Funcionality Schema (itec:Functionality)
base URI <itec>/vocabularies/Functionality#
Element
URI
has_broader
"activity management tool"
<itec>/vocabularies/Functionality#actman
"student information system"
"annotation tool"
<itec>/vocabularies/Functionality#anntoo
"social networking tool"
"application sharing tool"
<itec>/vocabularies/Functionality#appsha
"synchronous
tool"
"asynchronous
tool"
<itec>/vocabularies/Functionality#asycom
"communication tool"
"audio capture tool"
<itec>/vocabularies/Functionality#audcap
"capture tool"
"audio conference tool"
<itec>/vocabularies/Functionality#audcon
"synchronous
tool"
"audio editor"
<itec>/vocabularies/Functionality#audedi
"media authoring tool"
"audio sharing tool"
<itec>/vocabularies/Functionality#audsha
"data sharing tool"
"automated assessment tool"
<itec>/vocabularies/Functionality#autass
"blog"
<itec>/vocabularies/Functionality#blog
"asynchronous
tool"
communication
"bulletin board system"
<itec>/vocabularies/Functionality#bulboa
"asynchronous
tool"
communication
"calendar"
<itec>/vocabularies/Functionality#calend
"collaboration tool"
"capture tool"
<itec>/vocabularies/Functionality#captoo
"chat client"
<itec>/vocabularies/Functionality#chacli
"synchronous
tool"
"classroom management system"
<itec>/vocabularies/Functionality#claman
"virtual learning environment"
<itec>/vocabularies/Functionality#coltoo
<itec>/vocabularies/Functionality#comtoo
"competency management tool"
<itec>/vocabularies/Functionality#comman
"concept-mapping tool"
<itec>/vocabularies/Functionality#contoo
"content management tool"
<itec>/vocabularies/Functionality#conman
"data analysis tool"
<itec>/vocabularies/Functionality#datana
"data sharing tool"
<itec>/vocabularies/Functionality#datsha
communication
Page 194/214
communication
communication
communication
iTEC Project
17092012.Docx
"database"
<itec>/vocabularies/Functionality#databa
"dictionary"
<itec>/vocabularies/Functionality#dictio
"reference tool"
"discrete event simulation"
<itec>/vocabularies/Functionality#diseve
"simulation software"
"email"
<itec>/vocabularies/Functionality#email
"messaging client"
"encyclopedia"
<itec>/vocabularies/Functionality#encycl
"reference tool"
"feedback tool"
<itec>/vocabularies/Functionality#feetoo
"file sharing tool"
<itec>/vocabularies/Functionality#filsha
"data sharing tool"
"file transfer client"
<itec>/vocabularies/Functionality#filtra
"forum"
<itec>/vocabularies/Functionality#forum
"asynchronous
tool"
"game"
<itec>/vocabularies/Functionality#game
"geotagging tool"
<itec>/vocabularies/Functionality#geotoo
"grading tool"
<itec>/vocabularies/Functionality#gratoo
<itec>/vocabularies/Functionality#groind
"feedback tool"
"ideas sharing"
<itec>/vocabularies/Functionality#idesha
"image editor"
<itec>/vocabularies/Functionality#imaedi
"instant messaging client"
<itec>/vocabularies/Functionality#insmes
"synchronous
tool"
"instructional design tool"
<itec>/vocabularies/Functionality#insdes
"location aware application"
<itec>/vocabularies/Functionality#locawa
"mapping tool"
<itec>/vocabularies/Functionality#maptoo
"reference tool"
<itec>/vocabularies/Functionality#medaut
"instructional design tool"
"messaging client"
<itec>/vocabularies/Functionality#mescli
"asynchronous
tool"
"mms"
<itec>/vocabularies/Functionality#mms
"messaging client"
"multi-media repository client"
<itec>/vocabularies/Functionality#mulrep
"offline game"
<itec>/vocabularies/Functionality#offgam
"offline multi-player game"
<itec>/vocabularies/Functionality#offmul
"offline single-player game"
<itec>/vocabularies/Functionality#offsin
"online game"
<itec>/vocabularies/Functionality#onlgam
"game"
"online journal"
<itec>/vocabularies/Functionality#onljou
"asynchronous
tool"
"group
individual
review"
contribution
Page 195/214
communication
communication
communication
"game"
communication
iTEC Project
17092012.Docx
"online multi-player game"
<itec>/vocabularies/Functionality#onlmul
"online portfolio tool"
<itec>/vocabularies/Functionality#onlpor
"online single-player game"
<itec>/vocabularies/Functionality#onlsin
"online storage tool"
<itec>/vocabularies/Functionality#onlsto
"pdf editor"
<itec>/vocabularies/Functionality#pdfedi
"peer assessing tool"
<itec>/vocabularies/Functionality#peeass
"feedback tool"
"phone"
<itec>/vocabularies/Functionality#phone
"synchronous
tool"
"photo capture tool"
<itec>/vocabularies/Functionality#phocap
"capture tool"
"photo sharing tool"
<itec>/vocabularies/Functionality#phosha
"data sharing tool"
"podcast client"
<itec>/vocabularies/Functionality#podcli
"presentation graphics tool"
<itec>/vocabularies/Functionality#pregra
"projection tool"
<itec>/vocabularies/Functionality#protoo
"QR Code reader"
<itec>/vocabularies/Functionality#qrcode
"capture tool"
"rating tool"
<itec>/vocabularies/Functionality#rattoo
"reference tool"
<itec>/vocabularies/Functionality#reftoo
"scanner"
<itec>/vocabularies/Functionality#scanne
"search engine"
<itec>/vocabularies/Functionality#seaeng
"shared editing tool"
<itec>/vocabularies/Functionality#shaedi
<itec>/vocabularies/Functionality#simsof
"sms"
<itec>/vocabularies/Functionality#sms
"messaging client"
"social bookmarking tool"
<itec>/vocabularies/Functionality#socboo
<itec>/vocabularies/Functionality#socnet
"spreadsheet tool"
<itec>/vocabularies/Functionality#sprtoo
<itec>/vocabularies/Functionality#stuinf
"student reporting tool"
<itec>/vocabularies/Functionality#sturep
"survey tool"
<itec>/vocabularies/Functionality#surtoo
"feedback tool"
"synchronous communication tool"
<itec>/vocabularies/Functionality#syncom
"syndication feed"
<itec>/vocabularies/Functionality#synfee
"tagging tool"
<itec>/vocabularies/Functionality#tagtoo
Page 196/214
communication
"capture tool"
iTEC Project
17092012.Docx
"task management tool"
<itec>/vocabularies/Functionality#tasman
"team sharing"
<itec>/vocabularies/Functionality#teasha
"ubiquitous messaging"
<itec>/vocabularies/Functionality#ubimes
"messaging client"
"video capture tool"
<itec>/vocabularies/Functionality#vidcap
"capture tool"
"video conferencing client"
<itec>/vocabularies/Functionality#vidcon
"synchronous
tool"
"video editor"
<itec>/vocabularies/Functionality#videdi
"video sharing client"
<itec>/vocabularies/Functionality#vidsha
"data sharing tool"
<itec>/vocabularies/Functionality#virlea
"virtual world client"
<itec>/vocabularies/Functionality#virwor
"voting tool"
<itec>/vocabularies/Functionality#vottoo
"feedback tool"
"web authoring tool"
<itec>/vocabularies/Functionality#webaut
"web browser"
<itec>/vocabularies/Functionality#webbro
"wiki"
<itec>/vocabularies/Functionality#wiki
"word processor"
<itec>/vocabularies/Functionality#worpro
communication
Table 109. LearningContentType vocabulary
LearningContentType Schema (itec:LearningContentType)
base URI <itec>/vocabularies/LearningContentType#
Element
URI
has_broader
"application"
<itec>/vocabularies/LearningContentType#application
"learning resource"
"assessment"
<itec>/vocabularies/LearningContentType#assessment
"learning resource"
"audio"
<itec>/vocabularies/LearningContentType#audio
"learning asset"
"bookmark sharing platform"
<itec>/vocabularies/LearningContentType#bookmarkshare
"social media"
"broadcast"
<itec>/vocabularies/LearningContentType#broadcast
"learning resource"
"case study"
<itec>/vocabularies/LearningContentType#case.study
"learning resource"
"course"
<itec>/vocabularies/LearningContentType#course
"learning resource"
"data"
<itec>/vocabularies/LearningContentType#data
"learning asset"
"demonstration"
<itec>/vocabularies/LearningContentType#demonstration
"learning resource"
"drill and practice"
<itec>/vocabularies/LearningContentType#drill.and.practice
"learning resource"
"educational game"
<itec>/vocabularies/LearningContentType#educational.game
"learning resource"
Page 197/214
iTEC Project
17092012.Docx
"enquiry-oriented activity"
<itec>/vocabularies/LearningContentType#enquiryoriented.activity
"learning resource"
"experiment"
<itec>/vocabularies/LearningContentType#experiment
"learning resource"
"exploration"
<itec>/vocabularies/LearningContentType#exploration
"learning resource"
"glossary"
<itec>/vocabularies/LearningContentType#glossary
"learning resource"
"guide"
<itec>/vocabularies/LearningContentType#guide
"learning resource"
"image"
<itec>/vocabularies/LearningContentType#image
"learning asset"
"image sharing platform"
<itec>/vocabularies/LearningContentType#imageshare
"social media"
"learning asset"
<itec>/vocabularies/LearningContentType#learning.asset
"learning resource"
<itec>/vocabularies/LearningContentType#resource
"lesson plan"
<itec>/vocabularies/LearningContentType#lesson.plan
"learning resource"
"model"
<itec>/vocabularies/LearningContentType#model
"learning asset"
"open activity"
<itec>/vocabularies/LearningContentType#open.activity
"learning resource"
"other"
<itec>/vocabularies/LearningContentType#other
"learning resource"
"other web resource"
<itec>/vocabularies/LearningContentType#other.web.resource
"presentation"
<itec>/vocabularies/LearningContentType#presentation
"learning resource"
"project"
<itec>/vocabularies/LearningContentType#project
"learning resource"
"reference"
<itec>/vocabularies/LearningContentType#reference
"learning resource"
"reference sharing platform"
<itec>/vocabularies/LearningContentType#refshare
"social media"
"role play"
<itec>/vocabularies/LearningContentType#role.play
"learning resource"
"simulation"
<itec>/vocabularies/LearningContentType#simulation
"learning resource"
"social media"
<itec>/vocabularies/LearningContentType#social.media
"learning resource"
"sound sharing platform"
<itec>/vocabularies/LearningContentType#soundshare
"social media"
"text"
<itec>/vocabularies/LearningContentType#text
"learning asset"
"textbook"
<itec>/vocabularies/LearningContentType#textbook
"learning resource"
"tool"
<itec>/vocabularies/LearningContentType#tool
"learning resource"
"video"
<itec>/vocabularies/LearningContentType#video
"learning asset"
"video sharing platform"
<itec>/vocabularies/LearningContentType#videoshare
"social media"
"weblog"
<itec>/vocabularies/LearningContentType#weblog
"social media"
"website"
<itec>/vocabularies/LearningContentType#web.page
"learning resource"
Page 198/214
iTEC Project
"wiki"
17092012.Docx
<itec>/vocabularies/LearningContentType#wiki
Table 110. Mime Types vocabulary
Mime Types Schema (itec:MimeType)
base URI <itec>/vocabularies/MimeType#
Element
URI
"application/base64"
<itec>/vocabularies/MimeType#application/base64
"application/binary"
<itec>/vocabularies/MimeType#application/binary
"application/java"
<itec>/vocabularies/MimeType#application/java
"application/macbinhex40"
<itec>/vocabularies/MimeType#application/macbinhex40
"application/msexcel"
<itec>/vocabularies/MimeType#application/msexcel
"application/msword"
<itec>/vocabularies/MimeType#application/msword
"application/ogg"
<itec>/vocabularies/MimeType#application/ogg
"application/pdf"
<itec>/vocabularies/MimeType#application/pdf
"application/postscript"
<itec>/vocabularies/MimeType#application/postscript
"application/ppt"
<itec>/vocabularies/MimeType#application/ppt
"application/rtf"
<itec>/vocabularies/MimeType#application/rtf
"application/uue"
<itec>/vocabularies/MimeType#application/uue
"application/x-compressed"
<itec>/vocabularies/MimeType#application/x-compressed
"application/x-gzip-compressed"
<itec>/vocabularies/MimeType#application/x-gzip-compressed
"application/x-pn-realmedia"
<itec>/vocabularies/MimeType#application/x-pn-realmedia
"application/x-shockwave-flash"
<itec>/vocabularies/MimeType#application/x-shockwave-flash
"application/x-stuffit"
<itec>/vocabularies/MimeType#application/x-stuffit
"application/x-zip-compressed"
<itec>/vocabularies/MimeType#application/x-zip-compressed
"application/zip"
<itec>/vocabularies/MimeType#application/zip
"audio/basic"
<itec>/vocabularies/MimeType#audio/basic
"audio/midi"
<itec>/vocabularies/MimeType#audio/midi
"audio/mp3"
<itec>/vocabularies/MimeType#audio/mp3
"audio/mpeg"
<itec>/vocabularies/MimeType#audio/mpeg
"audio/wav"
<itec>/vocabularies/MimeType#audio/wav
Page 199/214
"social media"
iTEC Project
"audio/x-pn-realaudio"
<itec>/vocabularies/MimeType#audio/x-pn-realaudio
"audio/x-pn-realaudio-plugin"
<itec>/vocabularies/MimeType#audio/x-pn-realaudio-plugin
"image/bmp"
<itec>/vocabularies/MimeType#image/bmp
"image/gif"
<itec>/vocabularies/MimeType#image/gif
"image/jpeg"
<itec>/vocabularies/MimeType#image/jpeg
"image/png"
<itec>/vocabularies/MimeType#image/png
"image/tiff"
<itec>/vocabularies/MimeType#image/tiff
"image/x-wmf"
<itec>/vocabularies/MimeType#image/x-wmf
"model/vrml"
<itec>/vocabularies/MimeType#model/vrml
"text/html"
<itec>/vocabularies/MimeType#text/html
"text/plain"
<itec>/vocabularies/MimeType#text/plain
"text/richtext"
<itec>/vocabularies/MimeType#text/richtext
"text/xml"
<itec>/vocabularies/MimeType#text/xml
"video/avi"
<itec>/vocabularies/MimeType#video/avi
"video/mpeg"
<itec>/vocabularies/MimeType#video/mpeg
"video/quicktime"
<itec>/vocabularies/MimeType#video/quicktime
"video/x-pn-realvideo"
<itec>/vocabularies/MimeType#video/x-pn-realvideo
"video/x-pn-realvideo-plugin"
<itec>/vocabularies/MimeType#video/x-pn-realvideo-plugin
Table 111. Person Type vocabulary
Person Type Schema (itec:PersonType)
base URI <itec>/vocabularies/PersonType#
Element
URI
"author"
<itec>/vocabularies/PersonType#author
"counsellor"
<itec>/vocabularies/PersonType#counsellor
"expert"
<itec>/vocabularies/PersonType#expert
"learner"
<itec>/vocabularies/PersonType#learner
"manager"
<itec>/vocabularies/PersonType#manager
"other"
<itec>/vocabularies/PersonType#other
Page 200/214
17092012.Docx
iTEC Project
"parent"
<itec>/vocabularies/PersonType#parent
"teacher"
<itec>/vocabularies/PersonType#teacher
17092012.Docx
9.3. Updates
In addition to the new classes and instances, some updates have been applied to existing
concepts. A thorough revision of the main classes and associated properties has been performed
to adapt them to the new functional requirements and to the agreements reached in the framework
of the project. We may point out the simplification effort performed upon the model to reduce its
computational cost. The new version of the semantic model keeps only the information strictly
needed to perform recommendations (i.e., the information used by the SDE’s internal heuristics),
or to perform analysis and comparative studies on external resources (i.e. the information used by
the KB’s enrichment systems). Initially available properties that have been deleted after this
internal revision process have been tagged as “deprecated” and removed from the semantic
model’s present version.
9.3.1. Concept Updates
Table 112. Concept updates in the itec:Person class
Context
People Group, itec:Person
Updates
itec:Person is subclassOf itec:Resource
ǣȂ
Ǥ
ǣȂǡǤ
ǣ Ȃ ȋǣȌǤ
ǣȂǤ
ǣ Ȃ ǯ
Ǥ
ǣǡǣǡǣǡǣǡǣ
Added
Properties
Deprecated
Properties:
Table 113. Concept updates in the org:Organisation class
Context
Deprecated
Properties:
Organisation Group, org:Organisation
ǣǡǣǡǣ
Table 114. Concept updates in the org:Site class
Context
Deprecated Properties:
Organisation Group, org:Site
ǣǡǣ
Page 201/214
iTEC Project
17092012.Docx
Table 115. Concept updates in the itec:Event class
Context
Added
Properties
Event Group, itec:Event
ǣ Ȃ ǡ
Ǥ
ǣ Ȃ
Ǥ
ǣȂǤ
ǣȂǤ
Table 116. Concept updates in the geo:SpatialThing class
Context
Added
Properties
Event Group, geo:SpatialThing
ǣ Ȃ
ǡǤ
Table 117. Concept updates in the itec:Tool class
Context
Tool Group, itec:Tool
Updates
itec:Tool is subClassOf itec:Resource
ǣ Ȃ ǡ
Ǥ
ǣ Ȃ ǡ
Ǥ
ǣȂǯ
Ǥ
ǣǤ
ǯ
ȋǤǤǡȌǤ
ǣ
Added
Properties
Deprecated
Properties
Table 118. Concept updates in the itec:TechnicalSetting class
Context
Added
Properties
Tool Group, itec:TechnicalSetting
ǣȂ
Ǥ
ǣȂ
Ǥ
Page 202/214
iTEC Project
17092012.Docx
Table 119. Concept updates in the itec:ShellSpecificApp class
Context
Tool Group, itec:ShellSpecificApp
Updates
The concept name
itec:ShellSpecificApp
was
changed
from
itec:Plugin
to
Table 120. Concept updates in the itec:Application class
Context
Added
Properties
Tool Group, itec:Application
ǣȂǯǤ
ǣȂ
Ǥ
Table 121. Concept updates in the itec:EventSpecification class
Context
Added
Properties
EducationalScenario Group, itec:EventSpecification
ǣ Ȃ
Ǥ
ǣȂ
Ǥ
ǣȂ
Ǥ
Table 122. Concept updates in the itec:PersonSpecification class
Context
Added
Properties
Deprecated
Properties
EducationalScenario Group, itec:PersonSpecification
ǣȂ
Ǥ
ǣ Ȃ
Ǥ

ǣǡǤ
ǣ Ȃ
Ǥ
ǣ
Table 123. Concept updates in the itec:ToolSpecification class
Context
Added
Properties
EducationalScenario Group, itec:ToolSpecification
ǣȂ
Ǥ
ǣ Ȃ
Ǥ
Page 203/214
iTEC Project
17092012.Docx
Table 124. Concept updates in the itec:ContentSpecification class
Context
Added
Properties
EducationalScenario Group, itec:ContentSpecification
ǣ Ȃ
Ǥ
ǣȂ
Ǥ
Table 125. Concept updates in the itec:UserSelection class
Context
EducationalScenario Group, itec:UserSelection
Updates
The concept name was changed from itec:UserSelection to
itec:ResourceSelection
ǣ Ȃ
Ǥ
ǡ
Ǥ

Ǥ
Added
Properties
Table 126. Concept updates in the itec:LearningActivity class
Context
Added
Properties
Deprecated
Properties
EducationalScenario Group, itec:LearningActivity
ǣȂ
Ǥ
͵

Ǥ
ǣǡǣǡ
ǡǡǣǡ
ǣǡǣǡǣ
Justification: as a part of the ontology’s simplification effort, and according to the
SDE’s functional standpoint, it has been deemed as unnecessary to keep this
information. Insofar the recommendation engine is concerned, a LearningActivity
is composed only of requirements.
Table 127. Concept updates in the itec:LearningStory class
Context
Added
Properties
Deprecated
Properties
EducationalScenario Group, itec:LearningStory
ǣȂ
Ǥ
ǣǡǣǡǣ
information. Insofar the recommendation engine is concerned, a LearningStory is
just a container of LAs.
Page 204/214
iTEC Project
17092012.Docx
Table 128. Concept updates in the itec:LARG class
Context
Deprecated
Properties
EducationalScenario Group, itec:LARG
ǣǡǣǡǣ
information. Insofar the recommendation engine is concerned, a LARG is a
container of LAs together with the resources selected to satisfy the requirements
specified.
Table 129. Concept updates in the itec:LARGContext class
Context
Added
EducationalScenario Group, itec:LARGContext
ǣȂ

Ǥ
Properties
Deprecated
Properties
ǣ
Ȃǡ
Ǥǡ

Ǥ
Table 130.Property updates in the semantic models
itec:tags
The new range of the property itec:tag is itec:Tag
The property name was changed from itec:tags to itec:tag
itec:technicalSetting
Added itec:Person as domain of the property.
Justification: the definition of TS has been extended. Now, a TS is a set of
tools, independently of these tools being associated to a school or to a
person.
itec:obligatory
The property name was changed from itec:obligatory to
itec:critical
itec:preferred
The property name was changed from itec:preferred to
itec:important
itec:largResource
The property name was changed from itec:largResource to
Page 205/214
iTEC Project
17092012.Docx
itec:resource
itec:downloadURL
The property name was changed from itec:downloadURL to
itec:accessURL
9.4. Deletions
Besides the changes introduced above, some concepts and properties have been removed. In
most cases, element deletion is motivated by the recommendations performed by experts along
the fourth iteration of Control Boards. The model provided in the first year was intended to be as
complete as possible. Along the second year many concepts in the original ontological model have
been deemed unnecessary insofar the SDE is concerned.
Table 131. Deletions in the semantic model
Context - Concept
Justification
People Group - bio:Birth
Specific information about the age of each single
individual
is
not
needed.
Insofar
the
recommendation systems is concerned, we only
need the age range assigned to a given class.
The management of group information has been
Organisation Group org:OrganisationalCollaboration, simplified.
itec:Group, org:StudentGroup
People Group - itec:SystemUser,
itec:Pupil, itec:Teacher,
itec:ICTCoordinator, itec:Expert
User types have been revised, modelled and
replaced by the SKOS PersonType vocabulary.
People Group – rev:Review
Replaced by the SocialAnnotation class, which
offers greater expressive capabilities.
Event Group –
itec:VirtualMeeting,
itec:InServiceTraining,
itec:SchoolEvent,
itec:CommunityEvent,
itec:Conference, itec:Seminar,
itec:Workshop, itec:HotSeat
Event types managed by the system has been
revised, modelled and replaced by the SKOS
EventType vocabulary.
Educational Scenario Group –
EducationalScenario
Technological work packages consider information
offered by WP3 as Learning Stories, but not from
Educational Scenarios generated by WP2.
Educational Scenarios are not relevant insofar the
SDE is concerned.
Page 206/214
iTEC Project
Educational Scenario Group –
17092012.Docx
itec:Guidelines
Pedagogical
guides
contain
user-friendly
information, but this information is not conditioned
to be used by the recommender.
Miscellaneous Group EducationalScenarioRecord
No information is collected about Educational
Scenarios from external sources.
Page 207/214
iTEC Project
17092012.Docx
10. REFERENCES
Alba, A., Bhagwan, V., & Grandison, T. (2008). Accessing the deep web: when good ideas go bad.
23rd ACM SIGPLAN conference on Object-oriented programming systems languages and
applications. ACM, New York, NY, USA.
Ananthakrishna, R., Chaudhuri, S., & Ganti, V. (2002). Eliminating fuzzy duplicates in data
warehouses. . Very Large Databases. Hong Kong, China.
Anido, L., Santos, J., Caeiro, M., Míguez, R., Cañas, A., & Fernández, M. (2011). Support for
Implementing iTEC Engaging Scenarios. Vigo.
Antoniou, G., & Van Harmelen, F. (2004). A Semantic Web Primer. MIT Press.
Arenas, M., Bertails, A., Prud'hommeaux, E., & Sequeda, J. (2011). A Direct Mapping of Relational
Data to RDF. Technical report, W3C Working Draft.
Auer, S., Dietzold, S., Lehmann, J., Hellmann, S., & Aumueller, D. (2009). Triplify – Light-Weight
Linked Data Publication from Relational Databases. 18th International World Wide Web
Conference.
Baumgartner, R., Gottlob, G., & Herzog, M. (2009). Scalable web data extraction for online market
intelligence. Very Large Data Base Endowment, (págs. 1512–1523).
Beckett, D., & Berners-Lee, T. (2008). Turtle - Terse RDF Triple Language. W3C Team
Submission.
Bilenko, M., & Mooney, R. J. (2003). On Evaluation and Training-Set Construction for Duplicate
Detection. Data Cleaning, Record Linkage, and Object Consolidation, (págs. 7-12).
Washington DC.
Bilenko, M., Kamath, B., & Mooney, R. J. (2003). Adaptive Blocking: Learning to Scale Up Record
Linkage. 6th IEEE International Conference on Data Mining.
Bishop, B., Kiryakov, A., Ognyano, D., Peikov, I., Tashev, Z., & Velkov, R. (2009). FactForge: A
fast track to the web of data. Semantic Web Journal.
Bizer, C., Cyganiak, R., & Heath, T. (2007). How to publish Linked Data on the Web. Retrieved
July 20, 2012, from http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
Bizer, C., Cyganiak, R., Becker, C., Langegger, A., & Leimer, H. (2012). The D2RQ platform.
Retrieved Junio 11, 2012, from http://d2rq.org/
Bizer, C., Heath, T., & Berners-Lee, T. (2009). Linked Data - The Story So Far. Semantic Web &
Information systems, 5(3):1-22.
Bizer, C., Jentzsch, A., & Cyganiak, R. (19 de September de 2011). State of the LOD Cloud.
Recuperado el 20 de July de 2012, de Freie Universität Berlin: http://www4.wiwiss.fuberlin.de/lodcloud/state/
Bizer, C., Lehmann, J., Kobilaro, G., Aue, S., Becker, C., Cygania, R., et al. (2009). DBpedia - A
Crystallization Point for the Web of Data. Journal of Web Semantics, 154-165.
Page 208/214
iTEC Project
17092012.Docx
Bollacker, K., Evans, C., Paritosh, P., Sturge, T., & Taylor, J. (2008). Freebase: a collaboratively
created graph database for structuring human knowledge. Special Interest Group on
Management Of Data, (págs. 1247-1250).
Bray, T., Paoli, J., & Sperberg-McQueen, C. M. (1998). Extensible markup language (XML) 1.0
W3C recommendation. Technical report, W3C.
Brickley, D. (2000). FOAF home. Retrieved July 31, 2012, from The Friend of a Friend (FOAF)
project: http://www.foaf-project.org/
Bumans, G., & Cerans, K. (2010 ). RDB2OWL : a Practical Approach for Transforming RDB Data
into RDF/OWL. 6th International Conference on Semantic Systems.
Carroll, J. J., Dickinson, I., Dollin, C., Reynolds, D., Seaborne, A., & Wilkinson, K. (2004). Jena:
Implementing the Semantic Web Recommendations. 13th World Wide Web Conference.
New York.
Chang, C., Kayed, M., Girgis, M. R., & Shaalan, K. F. (2006). A survey of web information
extraction systems. IEEE Transactions on Knowledge and Data Engineering, 1411 1428.
Chaudhuri, S., Ganjam, K., Ganti, V., & Motwani, R. (2003). Robust and efficient fuzzy match for
online data cleaning. Special Interest Group on Management of Data (págs. 313–324).
ACM Press.
Cheng, G., & Qu, Y. (2009). Searching Linked Objects with Falcons: Approach, Implementation
and Evaluation. Semantic Web and Information Systems 5(3), 49-70.
Clark,
J.
(1999).
Obtenido
de
XSL
http://www.w3.org/TR/XSLT/xslt.html
Transformations
(XSLT)
Version
1.0.:
Connolly, D. (2007). Gleaning Resource Descriptions from Dialects of Languages (GRDDL). World
Wide Web Consortium, W3C Recommendation.
Cowie, J., & Lehnert, W. (1996). Information extraction. Communications of the ACM, 39(1):80–91.
Cudré-Mauroux, P., Haghani, P., & Jost, M. (2009). idMesh: Graph-Based Disambiguation of
Linked Data. 18th International World Wide Web Conference. Madrid.
d’Aquin, M., & Motta, E. (2011). Watson, more than a semantic web search engine. Semantic Web,
55–63.
d’Aquin, M., Sabou, M., Dzbor, M., Baldassarre, C., Gridinoc, L., Angeletou, S., et al. (2007).
Watson: A Gateway for the Semantic Web. European Semantic Web Conference.
Das, S., Sundara, S., & Cyganiak, R. (2011). R2RML: RDB to RDF mapping language. . World
Wide Web Consortium, Working Draft WD-r2rml-20110324.
DCMI. (1995). DCMI Home. Retrieved July 31, 2012, from Dublin Core Metadata Initiative:
http://dublincore.org/
Ding, L., Finin, T., Joshi, A., Pan, R., Cost, R. S., Peng, Y., et al. (2004). Swoogle: A Semantic
Web Search and Metadata Engine. 13th Information and Knowledge Management.
Page 209/214
iTEC Project
17092012.Docx
Ehrig, M. (2007). Ontology Aligment – Bridging the Semantic Gap. Springer: New York, NY US.
Embley, D., Liddle, S., & Tao, C. (2011). A Web of Knowledge: A Conceptual-Modeling
Perspective, in The Evolution of Conceptual Modeling: From a Historical Perspective
towards the Future of Conceptual Modeling. Lecture Notes in Computer Science, 137-160.
Erling, O., & Mikhailov, I. (2007). RDF support in the Virtuoso DBMS. 1st Conference on Social
Semantic Web.
EUN.
(2012). Vocabulary Bank for Education.
http://europeanschoolnet-vbe.lexaurus.net/vbe/
Retrieved
07
13,
2012,
from
Fensel, D. (2001). Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce.
Berlin: Springer-Verlag.
Fensel, D. (2002). Ontology-based knowledge management. Computer.
Fernández-Villamor, J. I., Blasco-García, J., Angel-Iglesias, C., & Garijo, M. (2011). A Semantic
Scraping Model for Web Resources - Applying Linked Data to Web Page Screen Scraping.
International Conference on Agents and Artificial Intelligence, (págs. 451-456).
Ferrara, E., Fiumara, G., & Baumgartner, R. (2011). Web data extraction, application and
techniques: A survey. Technical Report.
Fibbe, G. H. (2004). Screen-Scraping and Harmful Cybertrespass After Intel. Mercer Law Review.
Fiumara, G. (2007). Automated Information Extraction from Web Sources: a Survey, Between
Ontologies and Folksonomies. 3rd International Conference on Communities and
Technology.
Garcia, R., Perdrix, F., Gil, R., & Oliva, M. (2008). The semantic web as a newspaper media
convergence facilitator. Journal of Web Semantics 6(2), 151–161.
Glaser, H., Jaffri, A., & Millard, I. C. (2009). Managing Co-reference on the Semantic Web. Linked
Data on the Web.
Golbeck, J., Grove, M., Parsia, B., Kalyanpur, A., & Hendler, J. (2002). New Tools for the Semantic
Web. European Knowledge Acquisition (pp. 392–400). Springer-Verlag.
Hart, J. (2012). Centre for Learning & Performance Technologies. Retrieved July 20, 2012, from
http://c4lpt.co.uk
Harth, A., Hogan, A., Delbru, R., Umbrich, J., O’Riain, S., & Decker, S. (2007). SWSE: Answers
Before Links! 6th International Semantic Web. Busan, Korea.
Hassanzadeh, O., Kementsietsidis, A., Lim, L., Miller, R. J., & Wang, M. (2009). A Framework for
Semantic Link Discovery over Relational Data. Proceedings of the 18th ACM conference on
Information and knowledge management (pp. 1027-1036 ). ACM.
Hausenblas, M., & Karnstedt, M. (2010). Understanding Linked Open Data as a Web-Scale
Database. Advances in Databases.
Page 210/214
iTEC Project
17092012.Docx
He, B., Patel, M., Zhang, Z., & Chang, K. (2007). Accessing the deep web. Communications of the
ACM 50(5), 94–101.
Heath, T., & Bizer, C. (2011). Linked Data: Evolving the Web into a Global Data Space. . Morgan &
Claypool.
Hepp, M., Bachlechner, D., & Siorpaes, K. (2006). Harvesting Wiki Consensus - Using Wikipedia
Entries as Ontology Elements. ESWC. Budva, Montenegro.
Hogan, A., Harth, A., & Decker, S. (2007). Performing object consolidation on the semantic web
data graph. 1st Identity, Identifier, Identification Workshop.
Hogue, A. (2005). Thresher: Automating the unwrapping of semantic content from the world wide
web. 14th International World Wide Web Conference (págs. 86–95). ACM.
Hu, W., & Qu, Y. (2008). Falcon-AO: A practical ontology matching system. Journal of Web
Semantics.
Hu, W., Chen, J., Cheng, G., & Qu, Y. (2010). ObjectCoref & Falcon. Ontology Alignment
Evaluation Initiative.
Huynh, D., Mazzocchi, S., & Karger, D. (2005). Piggy Bank: Experience the Semantic Web Inside
Your Web Browser. ISWC (págs. 413-430). Springer .
IMS-GLC. (2002, 10 25). IMS Global Learning Consortium. Retrieved 07 09, 2012, from IMS
Reusable Definition of Competency or Educational Objective Specification:
http://www.imsglobal.org/competencies/
Intershare. (2012). Softonic. Recuperado el 20 de July de 2012, de http://www.softonic.com/
Irmak, U., & Suel, T. (2006). Interactive wrapper generation with minimal user effort. 15th
international conference on World Wide Web (págs. 553-563). ACM.
Isele, R., & Bizer, C. (2011). Learning Linkage Rules using Genetic Programming. . Ontology
Alignment Evaluation Initiative.
Jaro, M. A. (1995). Probabilistic linkage of large public health data files. Statistics in Medicine 14,
491–498.
Köpcke, H., & Rahm, E. (2009). Frameworks for entity matching: A comparison. Data & Knowledge
Engineering.
Koster, M. (2007). A Standard for Robot Exclusion. Recuperado el 20 de 7 de 2012, de Robots
Exclusion Protocol: http://www.robotstxt.org/orig.html
Kushmerick, N. (2000). Wrapper induction: Efficiency and expressiveness. Artificial Intelligence ,
118(1-2):15-68.
Laclavik, M. (2006). RDB2Onto: Relational Database Data to Ontology Individual Mapping. Tools
for Acquisition, Organisation and Presenting of Information and Knowledge.
Page 211/214
iTEC Project
17092012.Docx
Laender, A. H., Ribeiro-Neto, B. A., Da Silva, A. S., & Teixeira, J. S. (2002). A brief survey of web
data extraction tolos. Special Interest Group on Management Of Data , (págs. 84-93).
Lange, C. (2009). Krextor. An extensible XML◊RDF extraction framework. Scripting and
Development for the Semantic Web.
Lassila, O., & Swick, R. (1999). Resource Description Framework (RDF) Model and Syntax
Specification. W3C Recommendation, World Wide Web Consortium.
Lee, R. (2004). Scalability report on triple store applications. Technical Report, Massachusetts
Institute of Technology.
Levy, A. (1998). The Information Manifold Approach to Data Integration. IEEE Intelligent Systems.
Li, L., & Horrocks, I. (2004). A Software Framework for Matchmaking Based on Semantic Web
Technology. International journal of electronic commerce, 39-60.
Li, X., Morie, P., & Roth, D. (2004). Identification and traci ng of ambiguous names: Discriminative
and generative approaches. Association for the Advancement of Artificial Intelligence.
Li, Y., Zhong, Q., Juanzi, L., & Tang, J. (2007). Result of Ontology Aligment with RiMOM at
OAEI'07. Ontology Alignment Evaluation Initiative.
Martins, B., & Silva, M. J. (2005). The webcat framework : Automatic generation of meta-data for
web resources. IEEE/WIC/ACM International Conference on Web Intelligence.
Mazzocchi, S., Garland, S., & Lee, R. (2006). Simile: Practical metadata for the semantic web.
XML.com.
McCallum, A., Nigam, K., & Ungar, L. (2000). Efficient cluste ring of high-dimensional data sets
with application to reference matching. Knowledge Discovery and Data Mining, (pp. 169–
17).
MIND
LAB, U. o. (2012). Mindswap.
http://www.mindswap.org/
Recuperado
el
31
de
July
de
2012,
de
MIT. (2008, August 13). RDFizer. Retrieved July 20, 2012, from Simile Project, MIT:
http://simile.mit.edu/wiki/RDFizers
Newcombe, H. B., Kennedy, J. M., Axford, S. J., & James, A. P. (1959). Automatic Linkage of Vital
Records. Science, 954-959.
Ngomo, A. N., & Auer, S. (2011). Limes - a time-efficient approach for large-scale link discovery on
the web of data. International Joint Conference on Artificial Intelligence.
Ngomo, A.-C. N. (2011). A Time-Eƥcient Hybrid Approach to Link Discovery. Ontology Aligment
Evaluation Iniatitive.
Ngomo, A.-C. N., Lehmann, J., Auer, S., & Höffner, K. (2011). RAVEN – Active Learning of Link
Specifications. Ontology Matching OM-2011, ISWC Workshop.
Page 212/214
iTEC Project
17092012.Docx
Nikolov, A., Uren, V., & Motta, E. (2008). Handling instance coreferencing in the KnoFuss
architecture. Identity and Reference on the Semantic Web. Tenerife, Spain.
Oldakowski, R., & Bizer, C. (2005). A Framework for Calculating Semantic Similarity of Objects
Represented as RDF Graphs. Poster of the 4th International Semantic Web Conference.
OMELETTE. (2012). OMELETTE. Retrieved July 2012, 10, from http://www.ict-omelette.eu/
OpenLink-Software. (2012). Virtuoso
http://virtuoso.openlinksw.com/
Universal
Server.
Retrieved
07
13,
2012,
from
Prud'hommeaux, E., & Seaborne, A. (2008). SPARQL Query Language for RDF. W3C
Recommendation.
Quan, D., Huynh, D., & Karger, D. (2003). Haystack: A Platform for Authoring End User Semantic
Web Applications. International Semantic Web Conference.
Raimond, Y., Sutton, C., & Sandler, M. (2008). Automatic Interlinking of Music Datasets on the
Semantic Web. Linked Data on the Web.
Rodríguez, J. B., & Gomez-Perez, A. (2006). Upgrading relational legacy data to the semantic
web. 15th international Conference on World Wide Web (págs. 1069-1070). ACM.
Sahoo, S., Halb, W., Hellmann, S., Idehen, K., Thibodeau Jr, T., Auer, S., et al. (2009). A survey of
current approaches for mapping of relational databases to rdf. Technical report, W3C.
Sarawagi, S. (2008). Information extraction. Foundations and trends in databases.
Sarawagi, S., & Bhamidipaty, A. (2002). Interactive deduplication using active learning. Knowledge
Discovery and Data Mining.
Scharffe, F., Liu, Y., & Zhou, C. (2009). RDF-AI: an Architecture for RDF Datasets Matching,
Matching, Fusion and Interlink. International Joint Conferences on Artificial Intelligence
(IJCAI). California, USA.
ScraperWiki. (2012). ScraperWiki. Retrieved July 10, 2012, from https://scraperwiki.com/
Seaborne, A., Manjunath, G., Bizer, C., Breslin, J., Das, S., Davis, I., et al. (2008). SPARQL
Update. A language for updating RDF graphs. W3C Technical Report, World Wide Web
Consortium.
Sequeda, J., Depena, R., & Miranker, D. (2009). Ultrawrap: Using SQL views for RDB2RDF. 8th
International Semantic Web Conference.
Shearing, L. (2012). Cool Tools For Schools.
http://cooltoolsforschools.wikispaces.com
Retrieved
July
20,
2012,
from
Silva, M. J. (2003). The case for a Portuguese Web search engine. IADIS International Conference
on the WWW/Internet.
Simile Project, M. (2012). Solvent. Retrieved July 31, 2012, from http://simile.mit.edu/wiki/Solvent
Page 213/214
iTEC Project
17092012.Docx
Singhal, A. (12 de May de 2012). Introducing the Knowledge Graph: things, not strings.
Recuperado el 15 de June de 2012, de Google - Official Blog:
http://googleblog.blogspot.co.uk/2012/05/introducing-knowledge-graph-things-not.html
Singla, P., & Domingos, P. (2005). Object identification wit h attribute-mediated dependences.
Principles and Practice of Knowledge Discovery in Databases. Porto, Portugal.
Tao, C. (2008). Ontology Generation, Information Harvesting and Semantic Annotation for
Machine-Generated Web Pages. PhD dissertation, Brigham Young University, Department
of Computer Science.
Tummarello, G., Delbru, R., & Oren, E. (2007). Sindice.com: weaving the open linked data. 6th
International Semantic Web Conference.
UNESCO, & Microsoft. (2011). UNESCO ICT Competency Framework for Teachers. Paris: United
Nations Educational.
Van Assche, F. (2011). D9.1 - Analysis and design documents for the directory. Leuven.
Volz, J., Bizer, C., Gaedke, M., & Kobilarov, G. (2009). Silk – A Link Discovery Framework for the
Web of Data. Linked Data on the Web. Madrid, España.
Volz, J., Bizer, C., Gaedke, M., & Kobilarov, G. (2009). Silk – A Link Discovery Framework for the
Web of Data. Linked Data on the Web. Madrid, España.
W3C.
(2012). Converter to RDF. Recuperado
http://www.w3.org/wiki/ConverterToRdf
el
20
de
July
de
2012,
de
w3c:
Winkler, W. (2006). Overview of Record Linkage and Current Research Directions. US Bureau of
the Census, Technical Report.
Winkler, W. E. (1999). The State of Record Linkage and Current Research Problems. U.S. Census
Bureau.
Zagal Flores, R. E. (2008). Alineación de Ontologías usando el método de Boosting. PhD in the
Instituto Politécnico Nacional. México.
Zhou, Z. H., & Li, M. (2010). Semi-supervised learning by disagreement. Knowledge and
Information Systems, 415–439.
Page 214/214