Implementing a Role Based Mutual Assistance Community with

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

[email protected]

[email protected]

[email protected]

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.

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.

Table 1. Service Description 1 @prefix service: . 2 @prefix xsd: . 3 a service:Activity. 4 service:hasCreator . 5 service:creationTime "2013-05-27T08:00:00"^^xsd:dateTime. 6 service:startTime "2013-05-27T12:00:00"^^xsd:dateTime. 7 service:endTime "2013-05-27T16:00:00"^^xsd:dateTime. 8 service:playRole _:role_10100000. 9 _:role_10100000 a service:GroupAcitivityParticipant. 10 _:role_10100000 service:hasScope . 11 service:hasServiceCategory service:Walking. 12 service:hasServiceLocation _:serviceLocation_20200000. 13 _:serviceLocation_20200000 a . 14 _:serviceLocation_20200000 .

Table 2. An excerpt of Sample Ontology – in N3 @prefix rdfs: . @prefix service: . @prefix 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

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 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: 2 prefix xsd: 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: . @prefix rdfs: . @prefix 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

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: prefix xsd: 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: 2 prefix xsd: 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: prefix xsd: INSERT DATA { #Service Description, as line 3–line 14 in Table 1. 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: prefix xsd:

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 }

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? Yes select

No publish

No exist?

exist?

Yes select

Yes select

bind

bind

No

publish

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: , 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 = ) }

Table 8.b An Excerpt of Retrieved Open Data from DBpedia @prefix dbpedia: @prefix geo: @prefix foaf: @prefix xsd: @prefix ns18:

. . . . .

dbpedia:Ekeren

geo:long "4.41667"^^xsd:float ; geo:lat "51.2833"^^xsd:float ; foaf:homepage ; 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

Table 9. Query Performance target graph size

time

activities

1000

10000

50000

100000

150000

200000

250000

triples

12000

120000

600000

1200000

1800000

2400000

3000000

thread 1

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

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 [email protected] 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

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.