Implementing a Role Based Mutual Assistance Community

with Semantic Service Description and Matching Hong Sun

AGFA Healthcare 100 Moutstraat, Gent, Belgium

hong.sun@agfa.com

Vincenzo De Florio Univerisity of Antwerp and iMinds

1 Middelheimlaan Antwerp, Belgium

vincenzo.deflorio@ua.ac.be

Chris Blondia Univerisity of Antwerp and iMinds

1 Middelheimlaan Antwerp, Belgium

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.

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 forward-

looking 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.

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.

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.

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.

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.

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.

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#>.

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.

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

SPARQL

Endpoint

Rule

Engine

Query

Generator

Activity

Publisher

Web Portal

Repository

Service Lifecycle Management

Link

Open Data

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

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.

Table 3. Inference Rules

1 @prefix service: <http://www.pats.ua.ac.be/AALService#>.

2 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.

3 @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–

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 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

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:

?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 5.c. Sample Query – Second Formulation

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.

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 prefix service: <http://www.pats.ua.ac.be/AALService#>

2 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 }

query existing service request

group activity

No

invokeprovide service

User

publish

request service

?

as group activity

?

query existing group activity

exist?query existing

available service

Yes

exist?exist?

exist?

No

publish No

select

bind

select

bindselect

bind

select

bind

publish No

Yes

Yes

Yes Yes

No

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: <http://dbpedia.org/resource/> .

@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .

@prefix foaf: <http://xmlns.com/foaf/0.1/> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

@prefix ns18: <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-be-

published 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

Table 9. Query Performance

target graph size

activities

triples

time

thread 1

thread 5

1000

12000

16.2ms

44.2ms

10000

120000

99.8ms

291.5ms

50000

600000

638.8ms

1.82s

100000

1200000

1.36s

4.14s

150000

1800000

2.17s

6.91s

200000

heap

space

exceptionthread 10 81.1ms 616.3ms 3.99s 8.05s 13.95s

250000

2400000

18.75s

115.38s

250s

3000000

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.

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 sub-

communities 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

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 (CBMS-

2007), 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.