Hong Sun, AGFA Healthcare Vincenzo De Florio, Chris Blondia, University of Antwerp, PATS

Implementing a Role Based Mutual Assistance Community with Semantic Service Description and Matching

Hong Sun, AGFA HealthcareVincenzo De Florio, Chris Blondia, University of Antwerp, PATS

ForecastForecast

MEDES 2013 30 October, Luxembourg 2

The proportion of elderly people keeps increasing and poses challenges in healthcare in providing cost effective services.

Our answer: constructing a role-based mutual assistance community (MAC) to fully utilize the community resourcesand improve the physical and psychological health of the assisted people.

Cornerstone of MAC: Service publication and matching

An architecture based on semantic service description and matching is presented in this paper.

OutlineOutline

Role-based MAC: Introduction

Semantic service description and matching for MAC

Experiments and performance

Conclusions


Mutual Assistance CommunityMutual Assistance Community


Mutual Assistance CommunityMutual Assistance Community


A community dweller is encouraged to act as service provider

A community dweller may play different roles

- so as to removes any predefined and artificial distinction between care-givers and care-takers

A community dweller is encouraged to participate group activities

Community resources are therefore better utilized

Previous OWL-S Based Previous OWL-S Based ImplementationImplementation


Setting MatchingRequirements

Drawbacks of OWL-S Based Drawbacks of OWL-S Based ApproachApproach


Strict and inflexible format of service expression and matchingThe majority of OWL-S matchmakers are based on service inputs/outputs impossible to match complex services.

Performance penalty in service search/comparisonOWL-S Matcher takes more than 6 seconds to load the profile for service publication, and it takes around 6 seconds to compare two services.

OWLS-MX takes more than 1 second when the service size is around 400.

RDF Graph Based Service RDF Graph Based Service Description/MatchingDescription/Matching


Flexible in service description

Easy in service managementservice publication, update, query, termination

Fast in service matching

Service description as RDF graph, which is

Service management/query is coordinated by Fuseki SPARQL server

Basic OntologyBasic Ontology


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

Role Based Service DescriptionRole Based Service Description


service:playRole defines the role that a community dwellers plays.service:hasScope defines the scope (service activity) that a role is bond to.

service:playRole

service:hasScope

roleservice content

service content

community dweller

role

InferenceInference


{?C rdfs:subClassOf ?D. ?D rdfs:subClassOf ?E} => {?C rdfs:subClassOf ?E}.

#service category inference rule { ?service service:hasServiceCategory ?serviceCategory. ?serviceCategory rdfs:subClassOf ?serviceCategoryClass. ?serviceCategoryClass log:notEqualTo service:ServiceCategory. } => { ?service service:hasInferredServiceCategory ?serviceCategoryClass. }.

<…/Activity/101> service:hasInferredServiceCategory service:Fitness.

<…/Activity/101> service:hasServiceCategory service:Jogging.

It enables to match services which are syntactically different, but semantically close. It is executed by EYE Reasoning Engine.

infer

Ref: EYE engine: http://eulersharp.sourceforge.net/

ArchitectureArchitecture


SPARQL Endpoint

Rule Engine

Query Generator

Activity Publisher

Web Portal

Repository

Service Lifecycle Management

Link Open Data

WorkflowWorkflow


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?

Nopublish

No

select

bind

select

bindselect

bind

select

bind

publish No

Yes

Yes

Yes Yes

No

Service QueryService Query


prefix service: <http://www.pats.ua.ac.be/AALService#>prefix xsd: <http://www.w3.org/2001/XMLSchema#>

DESCRIBE ?creatorWHERE { ?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)}

It is possible to filter on different properties; the service match process is therefore much more flexible compared with our previous implementation.

Service Publication and Service Publication and TerminationTermination


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

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 }

Service Publication Service Termination

PerformancePerformance


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

A set of sample activity graphs that defines a different number of activities are randomly generated.

Different threads of service queries are tested as well.

……Every new solution breeds new Every new solution breeds new problems…problems… MAC basic assumption: every new service

needs to be matched with known services scalability

Upper bound on community size (heap space exception)

Current solution: breaking down the communities into sub-communities

Fractal organization


ConclusionConclusion

Semantic service description & matching framework for MAC


• Flexibility in service description.

• Ease in service management.

• Speed in service matching.

RDF graph based implementation outperforms our previous OWL-S based implementation in:

Future work: 1) semantic service composition2) automate the workflow3) fractal social organizations

http://www.youtube.com/watch?v=HKU7gOI57e0

Documents

Hong Sun, AGFA Healthcare Vincenzo De Florio, Chris Blondia, University of Antwerp, PATS