The population of elderly people is increasing rapidly, which becomes a predominant aspect of our society. For several reasons so significant a share of the human society is simply regarded as “retired” – a word condemning the elderly to a reduced participation in all active life, regardless of their actual conditions and abilities. In previous work, we discussed how community resources can be organized in a better way. In particular we introduced a so-called mutual assistance community – a digital ecosystem that removes any predefined and artificial distinction between care-givers and care-takers and provides a service-oriented infrastructure for intelligent matching of the supply and demand of services. According to this new paradigm all people are potentially active participants to activities defined by the people’s current needs, abilities, locations, and availabilities. Moving from this conceptual view to practical implementation calls for an architecture able to match adequately demand and supply of services. This paper presents an implementation of such an architecture based on semantic service description and matching. In comparison with our previous implementation, main added values include a greater flexibility in service representation and service matching and considerable improvements in performance.

1. Implementing a Role Based Mutual Assistance Community
with Semantic Service Description and Matching
Hong Sun
Vincenzo De Florio
Chris Blondia
AGFA Healthcare
100 Moutstraat,
Gent, Belgium
Univerisity of Antwerp and iMinds
1 Middelheimlaan
Antwerp, Belgium
Univerisity of Antwerp and iMinds
1 Middelheimlaan
Antwerp, Belgium
hong.sun@agfa.com
vincenzo.deflorio@ua.ac.be
chris.blondia@ua.ac.be
ABSTRACT
The population of elderly people is increasing rapidly, which
becomes a predominant aspect of our society. For several reasons
so significant a share of the human society is simply regarded as
“retired” – a word condemning the elderly to a reduced
participation in all active life, regardless of their actual
conditions and abilities. In previous work, we discussed how
community resources can be organized in a better way. In
particular we introduced a so-called mutual assistance
community – a digital ecosystem that removes any predefined
and artificial distinction between care-givers and care-takers and
provides a service-oriented infrastructure for intelligent matching
of the supply and demand of services. According to this new
paradigm all people are potentially active participants to
activities defined by the people’s current needs, abilities,
locations, and availabilities. Moving from this conceptual view to
practical implementation calls for an architecture able to match
adequately demand and supply of services. This paper presents
an implementation of such an architecture based on semantic
service description and matching. In comparison with our
previous implementation, main added values include a greater
flexibility in service representation and service matching and
considerable improvements in performance.
Categories and Subject Descriptors
H.3.5 [Information Storage and Retrieval]: Online Information
Services – web-based services, data sharing. I.2.4 [Artificial
Intelligence]: Knowledge Representation Formalisms and
Methods – semantic networks.
General Terms
Performance, Design, Experimentation.
Keywords
Ambient Assisted Living, Semantic Web, Digital Ecosystem.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MEDES’13, October 29-31, 2013, Neumü
nster Abbey, Luxembourg.
Copyright © 2013 ACM 978-1-4503-2004-7...$10.00.
1. INTRODUCTION
Traditional healthcare organizations are currently being
confronted with an increasingly difficult situation: almost
everywhere the rate of the elderly population older than 65 is
increasing, which translates in increased costs, e.g., for
professional care and hospitalization. The associated individual
and societal costs are not the only problem though, as the ever
increasing demand of specialized services is bound to overcome
the “manageability region” of traditional services, namely the
natural thresholds that allow management services to be timely
and appropriately orchestrated. Rather than “inflating” the
current traditional organizations, a more effective and forwardlooking approach appears that of identifying novel solutions able
to make a better use of the available resources and tap into the
undrawn well of “social energy” [1] of our societies so that they
are made able to self-satisfy their growing needs. One such
solution is the Mutual Assistance Community (MAC) – a digital
ecosystem for the ambient assistance of elderly and disable
persons [2, 3]. A peculiar characteristic of the MAC with respect
to other ambient assisted living organizations is the avoidance of
the artificial distinction between care-givers and care-takers.
Said discrimination is eliminated through a peer-to-peer
approach that regards people simply as potential participants to
activities without introducing a systemic classification into
primary, secondary, or tertiary users [4]. What differentiates
MAC users is not their age or condition, but rather how their
current location, attitude, abilities, and state, match the current
requests. Our past studies provide evidence that digital
ecosystems such as our MAC have the potential to raise the
“manageability region” characterizing traditional organizations
[5]. At the same time, the MAC favors social inclusion and helps
preserve the dignity of the elderly population [6].
The present contribution extends the above cited works in
several ways. First, a new semantic service matching algorithm
based on the N3 representation and the SPARQL query language
replaces our previous OWL-S matcher. This largely improves the
flexibility in service description and matching, at the same time
reducing considerably service matching time. Secondly, in this
paper we replaced our simulation engine and carried out our
performance analyses through experiments with a large set of
randomly generated services. Third, we introduced service
lifecycle management so as to better maintain the service
repository. Finally, we investigated the integration of link open
data into our semantic framework.

2. The rest of this article is structured as follows. Section 2
discusses the main design traits of MAC and recalls its major
assumptions and features. Our new semantic service framework
is presented in Sect. 3. Experiments and assessments are then
reported in Sect. 4. Conclusions and future work are finally
drawn in Sect. 5.
2. MUTUAL ASSISTANCE COMMUNITY
A mutual assistance community (MAC) is a digital ecosystem for
ambient assistance to the elderly and the impaired population.
The key distinctive feature of MAC with respect to approaches
with similar objectives lies in the fact that MAC removes any
predefined and artificial distinction between care-givers and
care-takers and provides a service-oriented infrastructure for
intelligent matching of the supply and demand of services. By
doing so we come up with a role-based system in which every
participant, depending on the activities he or she is currently
involved in, may decide to play different roles. This enables the
elderly people not to be confined to a passive role and allows
them to take those active roles that are compatible with their
state and condition. This avoids discriminating people and at the
same time harnesses new social resources for the benefit of all
[2].
Apart from the common demand-supply service mode, the MAC
introduced a symbiotic service mode, called Participant, by
means of which several service requesters would mutually fulfill
their requirements. We referred to this type of mode as to a
Group Activity [6]. In the cited paper we showed how the
introduction of such mode results in a better utilization of social
resources.
A major drawback in our previous implementation [7] was the
design choice of relying on OWL-S [8] for service description
and matching. This resulted in a strict and inflexible format of
service expression and in a considerable performance penalty.
This paper presents a new approach to semantically represent,
publish, and match services, based on N3 [9] representation, an
endpoint supporting SPARQL 1.1 specification [10], and a N3
rule engine. In what follows we show how the above mentioned
architectural choices helped addressing the problems
encountered in our previous research.
3. SEMANTIC SERVICE DESCRIPTION
AND MATCHING IN THE MAC
As introduced in the previous section, service description and
publication as well as a sound service matching algorithm are
among the key issues to be addressed in a mutual assistance
community. This section introduces the semantic service
description and matching algorithms which allow more flexible
service description and publication.
3.1 Role Based Semantic Service Description
This paper uses N3 syntax to represent the services/activities in
the proposed mutual assistance community. N3 is compact and
more human readable compared to RDF/XML [11], and it can be
used to express the entire semantic web stack formalism. A
service in MAC is represented as an RDF graph.
When the dwellers of a MAC are requesting for services, the
system first will attempt to organize the requested activity as
Group Activity by gathering dwellers with similar requests.
Semantic processing is used to unravel similarity of seemingly
unrelated requests. The system will issue a request for service
providers for the requested activity only when it is not possible to
organize the activity as Group Activity (or when a service
requester explicitly states so).
To organize such a mutual assistance community, it is important
to allow dwellers to publish service requests or their capabilities
to provide services in an easy manner. Meanwhile, the published
services or service requests should be able to be parsed by
computer, which allows the matching process to be carried out in
an automated way. Semantic web technology is an ideal tool to
fulfill the above mentioned requirements in that it allows
services to be reasoned upon by machine. In our previous
research, OWL-S [8] was used to represent the available services.
A sample set of ontologies were defined and used to represent
the available services. Those services were published to a central
repository, and service requests were also represented as OWL-S
services and sent to the central repository. Once there, service
matching was carried out by comparing the similarity of the
services available in the repository and the service request. After
defining a set of service categories in the ontology with
hierarchical relationship, (e.g. defining “Walking” as a sub-class
of “Fitness”), two services though literally represented
differently as Fitness and Walking would still result in a match.
Figure 1. An excerpt of a Sample Ontology Hierarchy
Table 1 shows an example of an RDF graph which describes a
group activity for walking service. We created an ontology
describing a set of roles that a user could play in the proposed
mutual assistance community; the sub-class relations between the
defined roles are also stated which allows extra knowledge to be
inferred, thus increasing the chance to unravel analogies and
match seemingly different services. A set of sample service
categories are also created in the ontology – together with their
hierarchical relationships. An excerpt of said ontology is shown
in Figure 1 and Table 2.
The roles that a dweller plays in a mutual assistance community
can be categorized into the following three classes:
ServiceProvider: Dweller who is able to provide service to others
in the specified activity.
ServiceRequester: Dweller who is requesting for service from
others in the specified activity.

3. Table 1. Service Description
1 @prefix service: <http://www.pats.ua.ac.be/AALService#>.
2 @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
3 <http://www.pats.ua.ac.be/aal/Activity/10100000#this> a service:Activity.
4 <http://www.pats.ua.ac.be/aal/Activity/10100000#this> service:hasCreator <http://www.pats.ua.ac.be/aal/User/234442#this>.
5 <http://www.pats.ua.ac.be/aal/Activity/10100000#this> service:creationTime "2013-05-27T08:00:00"^^xsd:dateTime.
6 <http://www.pats.ua.ac.be/aal/Activity/10100000#this> service:startTime "2013-05-27T12:00:00"^^xsd:dateTime.
7 <http://www.pats.ua.ac.be/aal/Activity/10100000#this> service:endTime "2013-05-27T16:00:00"^^xsd:dateTime.
8 <http://www.pats.ua.ac.be/aal/user/234442#this> service:playRole _:role_10100000.
9 _:role_10100000 a service:GroupAcitivityParticipant.
10 _:role_10100000 service:hasScope <http://www.pats.ua.ac.be/aal/Activity/10100000#this>.
11 <http://www.pats.ua.ac.be/aal/Activity/10100000#this> service:hasServiceCategory service:Walking.
12 <http://www.pats.ua.ac.be/aal/Activity/10100000#this> service:hasServiceLocation _:serviceLocation_20200000.
13 _:serviceLocation_20200000 a <http://schema.org/Park>.
14 _:serviceLocation_20200000 <http://dbpedia.org/ontology/location> <http://dbpedia.org/resource/Ekeren>.
Table 2. An excerpt of Sample Ontology – in N3
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix service: <http://www.pats.ua.ac.be/AALService#>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
Link
Open Data
service:Activity a owl:Class.
service:ServiceCategory a owl:Class.
service:Fitness a owl:Class; rdfs:subClassOf service:ServiceCategory.
service:Cycling a owl:Class; rdfs:subClassOf service:Fitness.
Service:Walking a owl:Class; rdfs:subClassOf service:Fitness.
Service
Lifecycle
Management
GroupActivityParticipant: Dweller who would like to participate
in a Group Activity as a peer participant.
As introduced in Section 2, a dweller in a MAC is not restricted
to a single role; rather, their roles vary depending on the
activities that a dweller joins in. Therefore, we use
service:hasScope to restrict the scope of a role. The domain of
service:hasScope is a role (service:Role), and its range is an
activity (service:Activity).
The service description presented in Table 1 indicates the service
is created by a user with userid 2334442 (Line 4); the user has a
role of GroupActivityParticipant in this activity (Lines 8–10).
The creation time, start time and end time of this activity are
stated (Lines 5–7), the end time is mandatory to determine the
expiration of a service, so that it can be removed from the
repository when expired. The location (Lines 12–14) of the
activity is represented with the ontology and data retrieved from
the DBpedia endpoint [15].
This RDF graph based service description allows user to describe
their service in a flexible way. Only a limited set of properties
(service creator, end time, service category, user role) are
mandatory to be filled in, and the user is free to add additional
info, e.g., service location, etc.
3.2 Architecture
Figure 2 shows the components used for semantic service
description and matching. A community dweller publishes or
searches services/activities to the service repository via web
portal. When a dweller requests to join an activity, the query
generator will generate the request and query over the repository;
when a dweller is willing to provide a service, the activity
Rule
Engine
Query
Generator
Repository
SPARQL
Endpoint
Web Portal
Activity
Publisher
Figure 2. Architecture
publisher will insert the available services in the repository. The
rule engine is used to derive additional knowledge by semantic
inference. The service repository interacts with the web portal
via a SPARQL endpoint, – both publish and request of services
are sent to the SPARQL endpoint. A service lifecycle
management module is contained in the service repository to
remove the expired services. A link open data module is also
contained in the repository to provide additional data by querying
other existing open resources over the web.
3.2.1 SPARQL Endpoint
In the proposed mutual assistance community, one of the most
important features is that the role of a user is not restricted as a
service consumer, but should also be encouraged to act as a
service provider when the user is qualified. Therefore, a dweller
may get involved in many actions, e.g., publish, search for,
update, or withdraw a service from the service repository. The
service repository is thus requested to provide the above
mentioned create, read, update, and delete (CRUD) services in a
semantic way.
The SPARQL query language is probably the most widely used
semantic query language, and is considered as a counterpart of
SQL language in the semantic domain. While SQL is able to

4. carry the CRUD operations over the contents of a database, the
SPARQL 1.0 version lacks such support and only works as a
query language. Due to this deficiency, in our previous research,
we used OWL-S to describe, publish and match services.
Nevertheless, the deficiency of lacking update language in
SPARQL language was made up by the SPARQL 1.1 Update
language, which became W3C recommendation in March, 2013.
The SPARQL 1.1 update language is an update language for
RDF graphs, and uses syntax derived from the SPARQL Query
Language. It provides operations to update, create and remove
RDF graphs in a Graph store.
Fuseki [12] is a Jena SPARQL server which supports a range of
operations on RDF graph, including support for the SPARQL 1.1
update language. This paper uses Fuseki to build a SPARQL
endpoint to manage the services in MAC. The services are
described as RDF graphs with N3 syntax and are managed
through the SPARQL endpoint. The performance of the SPARQL
endpoint in service matching is presented in Section 4.
3.2.2 Semantic Rule Engine
One of the great benefits in using semantic technology in service
matching is being able to match services which are literally
different but semantically similar. As an example, the service
type Walking could be considered as a match to a service
requesting for Fitness – provided that the user agrees about such
inference and at the same time Walking is explicitly stated as a
sub class of fitness in the ontology. Meanwhile, if a service type
Fitness is stated in the service description, it can also be deduced
that it is possible to provide Jogging, Cycling, and Walking
services. Through such inferencing, the chances to have a service
match are much increased.
The Semantic Rule Engine is responsible to carry the above
mentioned inferencing process. It uses Euler YAP Engine (EYE)
[13], an open source reasoning engine, as the rule engine. EYE is
able to apply N3 rules on RDF graphs. Table 3 shows the
inference rules in inferring the service categories, represented as
N3 rules. The symbol '=>' stands for log:implies [14], its subject
(the left side graph of '=>') is the antecedent graph, and the object
(the right side graph) is the consequent graph.
10 are used to infer the relations e.g. providing Jogging is a
subclass of Fitness, a service has service category Jogging can
also has inferred service category Fitness. Lines 11–14 are used
to infer relations. As an example, provided that Jogging is a
subclass of Fitness, if a service has service category Fitness it is
possible to infer it is also a Jogging service. When executing the
rules in Table 2, together with the service graph in Table 1 and
the service ontology in Table 2, the triple stated in Table 4 is
received.
Table 4. Inferred Service Category
<http://www.pats.ua.ac.be/aal/Activity/10100000#this>
service:hasInferredServiceCategory service:Fitness.
3.2.3 Query Generator
When a user wants to request/provide a service, the system first
queries the SPARQL Endpoint to check whether some are
available in the repository. A Query Generator generates
SPARQL query for the above mentioned query.
Table 5.a. Sample Query
1 prefix service: <http://www.pats.ua.ac.be/AALService#>
2 prefix xsd: <http://www.w3.org/2001/XMLSchema#>
3 CONSTRUCT {
4
?service ?p ?o.
5
?o ?p2 ?o2.
6
?o2 ?p3 ?o3.
7 } WHERE {
8
?service service:hasServiceCategory ?type.
9
?service service:hasCreator ?creator .
10
?creator service:playRole ?role.
11
?role a ?roleType.
12
?role service:hasScope ?service.
13
?service service:endTime ?endTime.
14
FILTER(?endTime > "2013-05-27T12:00:00"^^xsd:dateTime)
15
FILTER(?type = service:Walking)
16
FILTER(?roleType =service:GroupAcitivityParticipant)
17
?service ?p ?o.
18
OPTIONAL {?o ?p2 ?o2. OPTIONAL {?o2 ?p3 ?o3.}}
19 }
Table 3. Inference Rules
1
2
3
@prefix service: <http://www.pats.ua.ac.be/AALService#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix log: <http://www.w3.org/2000/10/swap/log#>.
4
{?C rdfs:subClassOf ?D. ?D rdfs:subClassOf ?E} => {?C rdfs:subClassOf ?E}.
5 #service category inference rule
6 { ?service service:hasServiceCategory ?serviceCategory.
7
?serviceCategory rdfs:subClassOf ?serviceCategoryClass.
8
?serviceCategoryClass log:notEqualTo service:ServiceCategory.
9 } => {
10 ?service service:hasInferredServiceCategory ?serviceCategoryClass. }.
11 { ?service service:hasServiceCategory ?serviceCategory.
12
?serviceCategoryClass rdfs:subClassOf ?serviceCategory.
13 } => {
14
?service service:hasPossibleServiceCategory ?serviceCategoryClass. }.
In the rules displayed in Table3, Line 4 is the rdf:subClass
inference rule, it means if C is a sub class of D, D is a sub class
of E, then C is also a sub class of E. The rule stated in Lines 6–
Table 5.a provides the general pattern to query for activities in
the mutual assistance community. Lines 4–6 state the graph to be
returned. Lines 8–9 query the basic element for service matching:
service end time, service category, and the role type that the
activity creator is to play. Filter conditions on these elements can
be specified as stated in Lines 14–16. The service matching
scheme based on the above listed filter conditions are very basic
–a user may express more complex service matching schemes,
e.g., comparing the location distance between the activity
published in the repository and the user who is querying for the
activity. Nevertheless, it is better to avoid introducing complex
service matching schemes in the SPARQL due to performance
and implementation concerns. Executing the query generated by
the Query Generator following the pattern stated in the Table 5.a
returns a list of activities fulfilling the basic search criteria; more
advanced service matching criteria can be expressed as N3 rules.
Such N3 rules can be very complex and are to be executed by the

5. Table 5.c. Sample Query – Second Formulation
EYE reasoning engine on the returned services to find the
activity that best fit the users’ requirement.
In the query listed in Table 5.a, Lines 8–16 list the basic
matching criteria, while Lines 17–18 extract the content listed in
the query. Line 17 retrieves all the properties directly linked to
the service; however, if a property is an object property, e.g. its
location, then only the URI will be returned. As an example,
Line 12 in Table 1 can be returned, but Line 13 and Line 14 will
not be returned as they are not directly linked to the service.
Therefore, Line 18 is added to retrieve associated sub-graphs in
the service description.
As presented in Table 3, the inference rules allow knowledge to
be inferred, which may help to increase the chance of successful
service matching. Such a benefit is not reflected in the query
listed in Table 5.a. If there is a fitness activity published in the
repository, the corresponding triple is:
_:service service:hasServiceCategory service:Fitness .
The inference rules in Table 3 can generate an extra triple:
_:service service:hasPossibleServiceCategory service:Walking .
However, the query in Table 5.a could not create a match as it is
querying as follows:
prefix service: <http://www.pats.ua.ac.be/AALService#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
DESCRIBE ?creator
WHERE {
?service ?servicetype ?type.
?service service:hasCreator ?creator .
?creator service:playRole ?role.
?role ?serviceRole ?roleType.
?role service:hasScope ?service.
?service service:endTime ?endTime.
FILTER(?endTime > "2013-05-01T17:00:00"^^xsd:dateTime)
FILTER(?type = service:Fitness)
FILTER(?roleType =service:GroupAcitivityParticipant)
}
3.2.4 Activity Publisher
When the service request can not find the activities that a user is
searching for, what requested/provided from the user need to be
published in the repository. The Activity Publisher adds the
service description into the repository by executing the INSERT
operation over the endpoint. Table 6 shows the sample script to
add the service described in Table 1 into the repository.
?service service:hasServiceCategory service:Walking .
In order to create a match for the above mentioned case, we
modified Line 8 and Line 11 in Table 5.a. The modified query is
shown in Table 5.b, which would create a match regardless the
service category and service role is either an inferred one or the
one stated originally.
However, the expressions in Line 8 and 11, in combination of the
optional statements expressed in Line 18, largely affected the
query performance. As a consequence, we introduced the query
presented in Table 5.c, which though returning the same results
as in Table 5.b exhibits a considerably better query performance.
The query performance of Table 5.c is presented in detail in
Section 4.
Table 5.b. Sample Query – First Formulation
1 prefix service: <http://www.pats.ua.ac.be/AALService#>
2 prefix xsd: <http://www.w3.org/2001/XMLSchema#>
3 CONSTRUCT {
4
?service ?p ?o.
5
?o ?p2 ?o2.
6
?o2 ?p3 ?o3.
7 } WHERE {
8
?service ?servicetype ?type.
9
?service service:hasCreator ?creator .
10
?creator service:playRole ?role.
11
?role ?serviceRole ?roleType.
12
?role service:hasScope ?service.
13
?service service:endTime ?endTime.
14
FILTER(?endTime > "2013-05-27T12:00:00"^^xsd:dateTime)
15
FILTER(?type = service:Walking)
16
FILTER(?roleType =service:GroupAcitivityParticipant)
17
?service ?p ?o.
18
OPTIONAL {?o ?p2 ?o2. OPTIONAL {?o2 ?p3 ?o3.}}
19 }
Table 6. Sample Script to Publish Service
prefix service: <http://www.pats.ua.ac.be/AALService#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
INSERT DATA {
#Service Description, as line 3–line 14 in Table 1.
<http://www.pats.ua.ac.be/aal/Activity/10100000#this> a service:Activity.
...
}
3.2.5 Service Lifecycle Management
As introduced in the service description section, an activity in the
mutual assistance community has an end time to indicate the
expiration of the activity. The expired activity has to be removed
from the repository. The service lifecycle management
component executes the script shown in Table 7 to remove
expired activities.
Table 7. Service Lifecycle Management
1
2
prefix service: <http://www.pats.ua.ac.be/AALService#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
3 DELETE {
4
?service ?p ?o.
5
?o ?p2 ?o2.
6
?o2 ?p3 ?o3.
7 } where {
8
?service service:endTime ?endtime.
9
FILTER ( ?endtime < "2013-05-26T00:00:00"^^xsd:dateTime )
10
?service ?p ?o.
11
OPTIONAL {?o ?p2 ?o2. OPTIONAL {?o2 ?p3 ?o3.}}
12 }

6. User
provide service
group activity
invoke
?
request service
Yes
as group
activity
query existing
service request
?
query existing
group activity
No
No
publish
query existing
available service
exist?
No
publish
exist?
exist?
Yes
select
Yes
select
No
publish
Yes
select
bind
No
bind
exist?
Yes
bind
select
bind
Figure 3. Service Query and Matching Workflow
3.2.6 Link Open Data
One advantage of using the semantic web in service
representation is that it is able to link open data published on the
web. In Line 14 of Table 1, the location is represented as a URI
from DBpedia: <http://dbpedia.org/resource/Ekeren>, as a
consequence, the link open data service could retrieve extra
description of the specified URI. The data presented in Table 8.b
is retrieved by executing the script in Table 8.a at the DBpedia
endpoint (http://dbpedia.org/sparql),
Table 8.a Script to Retrieve Open Data from DBpedia
DESCRIBE ?location
WHERE {
?location ?p ?o.
FILTER (?location = <http://dbpedia.org/resource/Ekeren>)
}
Table 8.b An Excerpt of Retrieved Open Data from DBpedia
@prefix dbpedia:
@prefix geo:
@prefix foaf:
@prefix xsd:
@prefix ns18:
<http://dbpedia.org/resource/> .
<http://www.w3.org/2003/01/geo/wgs84_pos#> .
<http://xmlns.com/foaf/0.1/> .
<http://www.w3.org/2001/XMLSchema#> .
<http://www4.wiwiss.fu-berlin.de/flickrwrappr/photos/> .
dbpedia:Ekeren
geo:long "4.41667"^^xsd:float ;
geo:lat
"51.2833"^^xsd:float ;
foaf:homepage
<http://ekeren.antwerpen.be/> ;
dbpprop:hasPhotoCollection
ns18:Ekeren .
……
Besides retrieving the open data from the web, the Link Open
Data service may also be used to retrieve a user’s social context.
In the service description shown in Table 1, the service creator is
associated using a URI. The social context of the creator, namely
creator’s location and creator’s states, are not listed. This is
because the social context of a user is constantly changing, and at
the same time also to avoid a lengthy service description.
However, such user related data can also be managed by the Link
Open Data service so as to provide dynamically updated
information for complex service matching scheme.
3.3 Workflow
Figure 3 shows the workflow of processing a user’s request. A
user’s request is categorized as three types, corresponding to the
roles the user would like to play: provide service, request for
service, and participate in a Group Activity.
If a user intends to provide a service, the system will first query
whether there is service request in the system that the to-bepublished service could satisfy. If it exists, this service provider
will be bound to a service requester that best fits; otherwise, the
service provision will be published in the repository.
If a user is intending to participate to a Group Activity, the
system will first query whether there is a Group Activity
initiative in the system that meets the user’s requirement. If it
exists, that user will be bound to the best fitting Group Activity
initiative; otherwise, the initiative to have a Group Activity will
be published in the repository.
When a user is requesting for a service, the system will first try
to satisfy the user’s request by organizing a Group Activity.
Unless the user explicitly states he/she does not want to
participate in Group Activities, the system will first search
whether there is a Group Activity initiative in the system that
meets the user’s requirements. For example, if user U is
requesting a service to identify someone to do jogging with, the
system will first try to check whether there is some ongoing
initiative of jogging as Group Activity. If such initiatives can be
found, U will be bound to the Group Activity initiative that best
fits. If no such a Group Activity initiative can be found in the
repository, the system will query for service provisions that can

7. Table 9. Query Performance
1000
10000
50000
100000
150000
200000
250000
triples
12000
120000
600000
1200000
1800000
2400000
3000000
16.2ms
99.8ms
638.8ms
1.36s
2.17s
18.75s
thread 5
44.2ms 291.5ms
1.82s
4.14s
6.91s
115.38s
thread 10
time
activities
thread 1
target
graph
size
81.1ms 616.3ms
3.99s
8.05s
13.95s
250s
meet U’s requirement. If candidate services exist, the best one
will be bound with U; otherwise, the request for service will be
published in the repository.
Through the above mentioned workflow, the system aims to
organize activities as group activities whenever possible as said
service mode corresponds to the most economical way in that the
community resources are best utilized while still meeting the
users’ requirements. The absence of a providing side and a
receiving side also preserves the dignity of all parties involved.
4. EXPERIMENT
In order to test the performance of the service matching
algorithm, we have generated a set of sample activity graphs that
defines a different number of activities. The number of activities
in the graphs ranges from 1000 to 250000, as shown in Table 9.
The activities are generated following the pattern presented in
Table 1. In generating the sample service activities, the service
activity ID, and service location ID are generated incrementally,
while the service category (service:hasServiceCategory) and the
role (service:playRole) are generated by randomly choosing a
value from a predefined list. The service creation, start, and end
date are also randomly generated. A sample piece of the
generated service activities can be found at the following Web
page: http://win.uantwerpen.be/~vincenz/MEDES13.
The graphs are loaded into the SPARQL endpoint separately, and
they are stored in the default built-in-memory graph. Queries are
executed on these graphs. The SPARQL endpoint is built with
Fuseki, and the test is executed on a conventional laptop,
equipped with an Intel i7@2.8GHz CPU and an 8GB memory.
The query executed for the performance test is the one displayed
in Table 5.c. The query is tested for different number of threads,
where different numbers of queries are executed concurrently.
The execution time increases following the increase of either the
graph size or the number of threads. The execution time
increases dramatically when the graph size exceeds 150,000
activities (equivalent to 1,800,000 triples). When the graph size
is 150,000 activities, a single query as listed in Table 5.c takes
2.17 seconds, when the thread number is 10, the same query
takes 13.95 seconds. When the graph size reaches 200,000
activities, which is equivalent to 2,400,000 triples, the same
single query takes 18.75 seconds; when the thread number is 10,
it takes 250 seconds. When the graph size further increases, a
heap space threshold is reached and the SPARQL endpoint
throws an exception.
heap
space
exception
The performance displayed in Table 9 exhibits big improvements
compared to OWL-S service matching. In [16], it is stated that
the OWL-S Matcher takes more than 6 seconds to load the
profile for service publication, and it takes around 6 seconds to
compare two services. In [17], it shows that the OWLS-MX takes
more than 1 second when the service size is around 400.
Conversely, Table 9 shows a query with the approach proposed
in this paper takes around 1 second when the service size is
100,000.
The heap space exception is caused by the in-memory graph and
can be solved by replacing it with a TDB store. TDB is a
component of Jena for RDF storage and query. A copy of TDB is
included in the Fuseki server as default. Another solution is to
divide big communities into sub communities, each with their
own repository and endpoint. Queries are first executed inside
the sub-community that a user is located in. Once the service is
not found inside that sub-community, queries are forwarded to
other endpoints to explore the resources in other subcommunities and super-communities as described in [18] [19].
5. Conclusion
This paper presents the implementation of a role based mutual
assistance living community with semantic service description
and matching. In the mutual assistance community, dwellers are
not playing fixed and pre-determined roles, e.g., as service
providers or service receivers; their roles vary dynamically
depending on the activities they participate in. Such a community
may avoid confining the elderly people to inactive and passive
roles only on the receiving side of human societies. By providing
them with the chance of being a peer participant of group
activities, and even active service providers in those activities
that match their capabilities, the MAC promotes active
participation and reduces isolation, thus resulting in a healthy
digital ecosystem.
The implementation of such a community with semantic web
technology is discussed in detail in this paper. It has been shown
how the N3 graph based service representation and SPARQL 1.1
based service publication, matching and termination schemes
allow services to be presented and matched in a flexible way.
The EYE rule engine is used for inference and could be used in
the future to support complex service matching schemes. A
SPARQL Endpoint is set up to serve as the service repository; it
is built with Fuseki. The performance of the endpoint is tested
and results are presented in this paper. Results prove that the
implementation presented in this paper solves most if not all the
deficiencies experienced in our previous research and enables the
deployment of mutual assistance communities. Future work

8. includes extending the model of the MAC by adopting
hierarchies of communities as depicted in [18, 19]. Furthermore,
an automated method of generating the scripts in the Query
Generator and Activity Publisher, currently manually generated,
will need to be developed. Finally, the current solution returns a
set of services that fulfills the basic service matching criteria. N3
rules shall be developed to take post processing on the returned
results from the endpoint, together with the data from the Link
Open Data service, so as to support complex service matching
schemes.
Acknowledgement
The authors would like to thank the anonymous reviewers for
their valuable comments and suggestions, which were helpful in
improving the paper. The authors would also like to thank Jos De
Roo from Agfa Healthcare for his support and advices on
Semantic Web.
6. REFERENCES
[1] V. De Florio & C. Blondia. 2010. Service-oriented
Communities: Visions and Contributions towards Social
Organizations. In Proc. of the Fifth International Workshop
on MObile and NEtworking Technologies for social
applications (MONET 2010), Lecture Notes in Computer
Science vol.6428.
[2] H. Sun, V. De Florio, N. Gui & C. Blondia. 2009. Promises
and Challenges of Ambient Assisted Living Systems. In
Proc. of the 6th International Conference on Information
Technology: New Generations (ITNG 2009), Las Vegas,
Nevada, USA.
[3] H. Sun, V. De Florio, N. Gui & C. Blondia. 2010. The
Missing Ones: Key Ingredients Towards Effective Ambient
Assisted Living Systems. In Journal of Ambient Intelligence
and Smart Environments.
[4] K. Eason. 1987. Information Technology and
Organizational Change. London: Taylor and Francis.
[5] H. Sun, V. De Florio, & C. Blondia. 2006. A Design Tool to
Reason about Ambient Assisted Living Systems. In Proc. of
the International Conference on Intelligent Systems Design
and Applications (ISDA 06), IEEE Comp. Soc.
[6] H. Sun, V. De Florio, N. Gui & C. Blondia. 2007.
Participant: A New Concept for Optimally Assisting the
Elder People. In Proc. of the 20th IEEE International
Symposium on Computer-Based Medical Systems (CBMS2007), IEEE Comp. Soc.
[7] H. Sun, V. De Florio, N. Gui & C. Blondia. 2007. Service
Matching in Online Community for Mutual Assisted Living.
In Proc. of the 3rd Int.l Conference on Signal-Image
Technology & Internet based Systems (SITIS 2007), IEEE
Comp. Soc.
[8] OWL-S Technical Committee (T.C), Web Ontology
Language for Web Services (OWL-S),
http://www.w3.org/Submission/OWL-S/, 2002
[9] Notation 3, http://www.w3.org/TeamSubmission/n3/
[10] SPARQL 1.1 query language for RDF,
http://www.w3.org/TR/sparql11-query/
[11] RDF Vocabulary Description Language 1.0: RDF Schema,
http://www.w3.org/TR/rdfschema/
[12] Fuseki server,
http://jena.apache.org/documentation/serving_data/index.ht
ml
[13] Euler Yap Engine,
http://eulersharp.sourceforge.net/2003/03swap/eye-note.txt
[14] Log ontology, http://www.w3.org/2000/10/swap/log#
[15] DBpedia SPARQL Endpoint, http://dbpedia.org/sparql
[16] N. Georgantas. 2006. Amigo middleware core: Prototype
implementation & documentation. IST Amigo Project
Deliverable D3.2.
[17] M. Klusch, B. Fries, K. Sycara. Automated semantic web
service discovery with OWLS-MX, in proceedings of the
fifth international joint conference on Autonomous agents
and multiagent systems. ACM, 2006: 915-922.
[18] V. De Florio, A. Coronato, M. Bakhouya & G. Serugendo.
2012. Service-oriented Communities: Models and Concepts
towards Fractal Social Organizations. In Proc. of the 8th
International Conference on signal, image technology and
internet based systems (SITIS 2012), IEEE Comp. Soc.
[19] V. De Florio, M. Bakhouya, A. Coronato, and G. Di Marzo
Serugendo. 2013. Models and Concepts for Socio-technical
Complex Systems: Towards Fractal Social Organizations.
To appear in Systems Research and Behavioral Science.