Enabling the Semantic Web with Ready-to-Use Web Widgets

14 Pages·2007·2.71 MB·English

Enabling the Semantic Web with Ready-to-Use
Web Widgets
Eetu M¨akel¨a, Kim Viljanen, Olli Alm, Jouni Tuominen, Onni Valkeap¨a¨a, Tomi
Kauppinen, Jussi Kurki, Reetta Sinkkil¨a, Teppo K¨ans¨al¨a, Robin Lindroos,
Osma Suominen, Tuukka Ruotsalo, and Eero Hyv¨onen
Helsinki University of Technology (TKK) and University of Helsinki
[email protected], http://www.seco.tkk.fi
Abstract. A lot of functionality is needed when an application, such
asamuseumcataloguingsystem,isextendedwithsemanticcapabilities,
for example ontological indexing functionality or multi-facet search. To
avoidduplicateworkandtoenableeasyandcost-efficientintegrationof
information systems with the Semantic Web, we propose a web widget
approach.Here,datasourcesarecombinedwithfunctionalityintoready-
to-use software components that allow adding semantic functionality to
systemswithjustafewlinesofcode.Asaproofoftheconcept,wepresent
a collection of general semantic web widgets and case applications that
usethem,suchastheontologyserverONKI,theannotationeditorSAHA
and the culture portal CultureSampo.
1 Introduction
To implement new semantic applications or to extend existing information sys-
tems (e.g. a museum cataloguing system) with semantic capabilities requires a
lotoffunctionalitydealingspecificallywithontologiesandmetadata.Currently,
needed functionalities are typically created for each application individually, re-
quiringalotofwork,timeandspecificskills.Beingabletolowertheseimplemen-
tation costs would be hugely beneficial to the adoption of the Semantic Web [1]
asawhole.Onagenerallevel,therearethreetasksinanysemanticinformation
environment that need to be handled, either by humans or machines:
Semantic Content Consumption. Searching,browsing,visualizingandoth-
erwiseconsumingsemanticcontent.Inthisgroupbelongforexamplelibrary
users in a semantic library environment and visitors of a semantic museum
portal [2]. RSS aggregation services are a programmatic example.
Content Indexing. The production of semantic metadata by indexing and
publishing content with references to shared vocabularies (e.g. museum cu-
rators indexing exhibits). Sometimes, the end-users themselves fill the role
of content indexers, as in the social bookmarking site del.icio.us1 and photo
sharing site Flickr2.
1 http://del.icio.us/
2 http://flickr.com/
Ontology Maintenance and Publishing. Creating and maintaining the on-
tologiesusedasreferencesforbothsemanticindexingandretrieval.Inorga-
nized fields, this is often done by dedicated information workers, but again
in the case of Web 2.0 [3] sites, it may be the users themselves that develop
their vocabulary in an ad-hoc manner alongside indexing.
Wearguethatinmanycases,tasksinthecontextsabovecontainmanycom-
mongeneralsubtasks.Specifically,wehavefoundatleastthefollowingcommon
functionalities:1)concept and instance selection,2)semantic linking,3)concept
and instance viewing, and 4) shared concept and instance storage and mainte-
nance.Toavoidduplicateworkandtoenablemoreindividualsandorganizations
tojointheSemanticWeb,weproposeawebwidget3 approach,wherethesefunc-
tionalitiesarecreatedandpublishedasready-to-usesoftwarecomponentswhich
can easily and cost-effectively be added to applications.
A web widget is a reusable, compact software component that can be em-
bedded into a web page or application to provide functionality. Most useful web
widgets also combine on-line data resources with site data to create mash-ups,
suchasinusualusecasesoftheGoogleMapsandGoogleAdSensewebwidgets.
Web widgets can also be combined together and published as new components,
e.g. with the Yahoo! Pipes service4. What makes web widgets very interest-
ing, is that they allow developers to easily add otherwise very complicated or
costly features to virtually any application. For example, Google Maps provides
a map and satellite image database of the planet Earth combined with search
and browsing capabilities for all to use.
Semantic web widgets then, as we envision them, are software components
that:1)arehookedupwitheitherSemanticWebdatasourcessuchasontologies
or instance databases, or the processed outputs of other components, 2) offer
a single, compact functionality, yet do that as completely as possible (often
including user interface elements), 3) are amenable to be combined with other
components and data to solve complex problems, and 4) can be easily and cost-
efficiently used for adding semantic functionalities to an application.
During our research, we found that while the semantic functionalities we
want to implement themselves are general, the best implementation for them
varies with the type of the underlying data they are to be hooked up with.
For example, selection from a geographical location ontology naturally benefits
from map-based user interfaces, actor ontologies need handling of pen names
and transliterations [4], while concept ontologies such as the Suggested Upper
Merged Ontology SUMO [5] and the health ontology SNOMED CT5 require
other methods. Therefore, we present several widget solutions to each of the
tasks based on the different requirements of each content domain.
The context for this work is the goal of creating a national semantic web
infrastructure in Finland [6], where critical Semantic Web resources, such as
3 http://en.wikipedia.org/wiki/Web widget
4 http://pipes.yahoo.com/
5 http://www.snomed.org/snomedct/
ontologies and the web widgets for using them, are published as centralized
services.
Inthefollowing,asproofoftheviabilityoftheideaofsemanticwebwidgets,
we first present some of the components we have created for solving common
subtasks, and then apply them to one combined mash-up service, the ONKI
ontology server, and two end-user applications: the SAHA metadata editor for
contentcreationandtheCultureSampoculturalheritageportal.Finally,related
work is presented, followed by discussion and suggestions for future work.
2 Common Subtasks in Semantic Applications and
Widgets for Solving Them
2.1 Concept and Instance Selection
Inontologicalsystemsfindingandselectingtherightconceptsandinstancesisa
central task of its own in ontological user interfaces. For end-user applications,
anysearchusuallybeginsbyfirstfindingtherightconceptswithwhichtodothe
actual ontological querying [7]. For efficient semantic content indexing, accurate
indexing entitities need to be found with as little effort as possible [8]. Also
ontology developers need concept search when creating links between concepts,
especially when developing distinct, yet heavily interlinked ontologies. In the
following,webwidgetstoprovideefficientconceptselectionindifferentsituations
are presented.
Semantic Autocompletion and Context Visualization When the user
knows with relative certainty what they are looking for, and the labels of the
entities do not overlap much, as in most non-instance vocabularies, a keyword
searchisanaturalwayofselectingconcepts.Forthis,wehavedevelopedmultiple
text literal matching semantic autocompletion interfaces [9] that can be hooked
into various semantic data sources to provide concept selection functionality.
Particular among these are two that also expose the semantic contexts of the
concepts matched.
There are two main reasons for desiring such functionality. First, this allows
the user to get acquainted with the vocabularies and how they are organized.
Second,particularlywithlargecomplexinterlinkedvocabularies,itisneverguar-
anteedthattheconceptthatfirstoccurstotheuseristhebestonefortheirtask.
Showing the ontological context or otherwise derived concept recommendations
is a powerful way of gently guiding the user and giving more options.
The first of the context exposing interfaces created, depicted in figure 1(a)
showstheautocompletionsdirectlyinsideatree.Thisisapplicablewhentheen-
titiesformahierarchyandthisisclearlythemostimportantcontextforthem.A
particularcaseforthisisinview-basedsearch,wheretheviewtreeisusuallyal-
readyshownforvisualizationandselectionpurposes.Thesecondisanavigation
widget for exploring the contexts of matched entities, depicted in figure 1(b).
Here the ontological context and otherwise derived concept recommendations
are shown to the user as a tree menu, with new levels of context opening when
the user mouses over the concepts.
(a) inside a tree (b) with context navigation
Fig.1. Semantic autocompletion
Map-based Search and Visualization URIs concerning geographic objects
might carry coordinate information, e.g. in terms of WGS84 latitude and lon-
gitude. We have created a method, n-point search [10,11], for selecting entities
based on this kind of coordinate data. A search query in this method is done by
pointing out n points on a map. The user clicks on the map and a search poly-
gon is formed accordingly. If an area point of a certain place is found inside the
user-given polygon, or a region-defining polygon is found to overlay the search
polygon, the region instance is retrieved and added to the results.
We have also taken into account two special cases, namely, where n = 1 or
n=2. If n=1 a circle is drawn around the point and the places that are inside
the circle are retrieved. An alternative treatment would be to simply find the
nearest places. If n = 2, we create a bounding box where the points are the
opposite, e.g. South-West and North-East corners, of the search area. We have
implemented the n-point search as a mash-up that itself uses Google Maps6.
We used SVG [12] for drawing the polygon as a transparent layer on top of the
map. In addition to selecting locations, the component is also able to visualize
semantic content related to geographical locations on the map.
An example of using the component is depicted in figure 2. The n polygon
corners are depicted as small crosses. The system has found from a historical
placeontology[13]themunicipalityofViipuriinannexedKarjalaasitexistedin
1906-1921,becauseitscenterpointsaresituatedwithintheuser-specifiedsearch
polygon. The municipality is visualized on the map as a red circle. The figure
alsodepictsanotherusefulfeatureofourcomponent,inthatitisabletooverlay
multiple maps of our own on top of the ones provided by Google [11]. Here, a
6 http://www.google.com/maps
historicalmapoverlayoftheareashowshowViipurilookedatthetimespecified,
which can be constrasted to how the place looks now.
Fig.2. Search and visualization using loca- Fig.3. A floatlet (encircled) displays
tion data and overlaid maps. links to MuseumFinland.
Multi-Facet Search View-based, or multi-facet search is a paradigm that has
recently become prominent as an easy to use interface for querying semantic
content [14–16]. Here, the idea is to offer multiple views to different aspects of
the content, both to visualize it and to select a subset from it by specifying
constraints in the views [7].
Wehaveimplementedageneralmulti-facetsearchenginethatpluggedintoan
instancedatabaseusestheothercreatedvisualizationandselectioncomponents
as views. This also represents one of the more complex interaction patterns
betweencomponents,asfirsttheviewsprovideconstraintselectionforthesearch
engine, which then calculates a result set based on the instance database, and
feeds this result set back to the views for visualization. As an example, the
selection tree in figure 1(a) is actually part of such a configuration, with the
numbers representing how many items annotated with that concept are in the
currentmulti-facetsearchresultset.Anearlierversionofthecomponent[17]has
already been used in the portals MuseumFinland7 [2], Orava8 [18], Veturi9 [19]
and SW-Suomi.fi10 [20]
Concept Location, Disambiguation and Extraction from Text It is of-
ten useful to be able to locate concepts in textual resources. In annotating doc-
uments, suggestions for annotations can be found from the text [21,22]. In web
7 http://www.museosuomi.fi/
8 http://demo.seco.tkk.fi/orava/
9 http://demo.seco.tkk.fi/veturi/
10 http://demo.seco.tkk.fi/suomifi/
browsing, on the other hand, semantic content can be linked to topics being
discussed in the text [23].
Wehaveimplementedacomponent[8]thatcanlocateconceptsandinstances
intextdocumentsbasedonthelabelsassociatedwiththem.Theextractionpro-
cessstartswithdocumentpreprocessing,whichinthecaseofHTMLdocuments
means extracting the textual content from the document. Then, the text is tok-
enized and lemmatized if needed. Next, the extraction component iterates over
thetokenizeddocumentandfindsstringscorrespondingtotheconceptlabels.In
cases where labels are ambiguous (e.g. “bank”), the component can make use of
the ontological neighbourhoods of the concepts by counting nearby occurrences
ofneighbourconceptlabelsofeachcandidateinordertoguessthepropermean-
ing. After finding the matches, the component then tags the occurences of the
concepts and instances in the document and outputs this tagged copy.
2.2 Semantic Linking
Semantic metadata combined with logical rules makes it possible to automati-
cally link related content together to support semantic browsing (semantic rec-
ommendations) [24,2]. Automatic linking is an especially important feature in
Semantic Web based systems where the content is typically aggregated from
different sources. Here, manual linking is difficult because the content providers
typically consider only the local view on their content excluding the global view
on the aggregated content [25].
Forautomaticlinkgeneration,wehavecreatedfunctionalitiesbasedonthree
different techniques. First, used in the already mentioned portals MuseumFin-
land, Orava and SW-Suomi.fi is the rule-based linking server Ontodella [24],
which is accessed by a simple HTTP request containing the URI of the current
document. The system then responds, based on the item metadata and ontolo-
gies linked to it, with a set of related documents. Each recommendation also
contains a human-readable explanation of the relation between the current and
the recommended document. For example, when looking at a nautical flag in
MuseumFinland, the object is linked to sailor’s clothes because, based on the
metadata and the ontologies, they are used in the same situation, seafaring.
Our second link generation component is based on calculating a similarity
measure between items in the linked instance database using an event-based
schema, which allows one to compare items annotated using dissimilar anno-
tation schemas [26]. This is the component used in CultureSampo, the case
application described later in this paper.
Finally, particularly for inter-portal semantic linking, we have exposed the
multi-facet functionalities of our portals to mash-up use. For utilizing them,
we propose the concept of floatlets, semantic linking widgets that can be eas-
ily plugged into any web page. Based on metadata and shared ontologies, the
floatlet is able to make semantically relevant queries to the portals and show
them in the context of the page. For example, figure 3 shows how the Finnish
Broadcasting Company’s video archive11 has been semantically linked based on
metadata with relevant content in MuseumFinland. In the example, the current
video is about the history of speed skating, which has also been described in its
metadata. Based on this information, the floatlet is able to query for old skates
from MuseumFinland. By clicking on the floatlet links, the skates can be exam-
inedinmoredetailintheiroriginalportal.Fromthesemanticportalpublisher’s
point of view, floatlets provide a new way for publishing and promoting their
content on the web. By clicking on the floatlet links, new visitors move over to
the floatlet’s host portal.
The idea of floatlets is similar to Google AdSense12 which is used for adding
advertisements to web pages. However, in floatlets the returned links are based
on explicit ontological annotations. This allows the web developer to specify in
detailwhatinformationistobelinked,eithermanuallyorbasedonthemetadata
of the current web page.
2.3 Concept and Instance Views
To be able to comprehend the meanings of concepts and their relations, content
visualization techniques are needed. The simplest way to approach this is to
show the properties of a concept or an instance to the user, e.g. simply as a list
of properties and their respective values. If a value is a resource, it can also act
as a link to allow browsing the content.
Ontologies are typically organized into hierarchical structures based on sub-
sumption, partition or other properties. This structural context of the concept
gives important information about its meaning and relations to other concepts.
These functions can be fulfilled by such context visualizations as already de-
scribed with reference to semantic autocompletion and depicted in figure 1.
2.4 Shared Concept and Instance Storage and Maintenance
In many semantic applications, there is a need for storing ontological metadata,
be they the annotations of an indexer or links forged between ontologies by an
ontology maintainer. However, existing systems may lack the means by which
to store arbitrary semantic constructs or even just URIs. For example, a mu-
seum indexing system may contain databases for museum items and actors, but
provide only a text field for storing locations. On the Semantic Web however,
locations need to be stored as instances with properties of their own.
To address this need, we have developed a browser-based metadata editor
SAHA, which can be used either as is or as depicted in figure 4, as a web
widgetinexistingindexingsystemslackingsemanticcapabilities[27].Connecting
SAHA to indexing systems can be done simply by linking to SAHA with a
GET parameter specifying the identifier (URI) of the document being currently
edited. By clicking on the link, a SAHA window opens, containing indexing
11 http://www.yle.fi/elavaarkisto/
12 http://www.google.com/adsense/
fields relevant for the current document. Afterwards, the annotations located in
the indexing system and SAHA can be combined by their common document
identifiers.
An indexing system missing URL
semantic annotation capabilities
URL
ONKI Browser
mash-up component
YSO ONKI-YSO-service
ontology SAHA annotation editor
Fig.4. The Finnish General Ontology connected to SAHA.
3 Case Applications
In the following, we present how we have combined and applied the previously
described semantic web widgets in actual systems, both in content creation as
well as end-user consumption.
3.1 The ONKI Server: Publishing Ontologies as Web Widgets
Currently,ontologiesaretypicallysharedbydownloadingthem,andeachappli-
cation must separately implement the functionatily to support them. To avoid
duplicated work and costs, and to ensure that the ontologies are always up-to-
date, we argue that the ontologies should also be published as shared services.
To demonstrate this aproach, we have implemented the ontology library service
ONKI, which is used for maintaining, publishing and using ontologies [6].
AspartoftheONKIconcept,auser-interfacewebwidgetcombiningaseman-
ticautocompletionsearchsub-componentwithconceptfetchingfunctionalityhas
been implemented, which can be added to any application requiring access to
a certain ontology. The widget looks like an ordinary text field, but when the
user types in characters, matching concepts found from the ONKI server are
listed. By selecting a concept from the result list, the concept’s URI, label or
other information is fetched to the client application for further processing and
storage.Inthecontextofabrowser-basedapplication,thisfetchingfunctionality
has been implemented with JavaScript window referencing [28].
Another ONKI feature is the concept browser, which can be integrated to
an application as an “ONKI button”. When the button is pressed, a separate
ONKIBrowserwindow(seefigure5)opens,inwhichannotationconceptscanbe
searched for and browsed, making use of semantic autocompletion, tree context
visualizationandconceptpropertyviewcomponents.Foreachconceptentry,the
browsershowsaFetchconcept buttonwhich,whenpressed,transfersthecurrent
concept information to the client application. For geographical data, a separate
browserapplication,ONKI-Paikka13 [29]hasbeencreated.Thisbrowser,shown
in figure 6, has been implemented by combining ontological information with
our geographical search and visualization widget.
Fig.5. The ONKI Ontology Browser’s Fig.6. The ONKI-Paikka browser.
concept view.
IntegratingtheseONKIservicestoclientapplicationsonlyrequiresaminimal
modification to the user interface implementation. For example, in the case of
HTMLpagesandAJAX,onlyashortsnippetofJavaScriptcodemustbeadded
to the web page for using the ONKI functionalities.
To test the ONKI solution, we have used the widgets in the browser-based
annotation editor SAHA14 [8,27]. For example (figure 4), the Finnish General
OntologyYSO[6]hasbeenpublishedasanONKIservice15,andhasbeenadded
as a web widget to SAHA for selecting annotation concepts. SAHA can also
make use of our automatic text extraction component in extracting potential
annotations from web resources.
InthecaseoftheONKIbrowsers,allconceptandinstanceURIsareintended
tobedesignedsothattheyfunctionalsoasURLs.WhentheURIofaconceptis
accessed with a web browser, the relevant view is opened in the ONKI browser.
ThismeansthattheURIitselfactsasafunctionallinkwhenaddedtoaHTML
13 http://www.seco.tkk.fi/services/onkipaikka/
14 http://www.seco.tkk.fi/services/saha/
15 http://www.yso.fi/onto/yso/
page.InaccordancetoW3C16,iftheURIisaccessedwithanRDFawaresystem,
themachinereadableRDFpresentationofthecontentisreturnedinsteadofthe
ONKI browser’s HTML presentation. This makes it easier to use ONKI services
also in programmatic mash-up applications.
ComparedtogeneralontologyserverinterfacessuchastheSKOSAPI17,our
approach is to publish highly specified functionalities as semantic web widgets
that solve a specific user task, such as the need for concept search and fetch.
In this, our approach complements the general APIs. The general APIs make it
possible to create completely new functionality but require more programming
work, while semantic web widgets make handling the most common tasks as
cost-effective as possible.
3.2 CultureSampo: A Semantic Portal for Cultural Content
CultureSampo [30] is a semantic portal that gathers together a comprehensive
collection of Finnish culture, including photographs, paintings, poems and bi-
ographies. Much of the functionality of the portal has been accomplished by
combining the various components described above, as depicted in figure 7
Fig.7. The mash-up architecture of the CultureSampo portal
First, we have harnessed our automatic concept extraction component to
enchance external web pages with CultureSampo content when viewed through
the portal. For example, on the left in figure 7, a web page from Wikipedia18 is
16 http://www.w3.org/TR/swbp-vocab-pub/
17 http://www.w3.org/2001/sw/Europe/reports/thes/skosapi.html
18 http://www.wikipedia.org/