Profiling Server

Table of Contents Description Features Artifacts Installation Configuration Provided services Code samples Context events User interaction

Description

The artifact is basically an interface between the context store in which user profiles are stored and the service bus. To manage ontological profile data it provides services for creating, updating, getting and deleting a user profile, with all its "branch" parameters. Other helper services allow getting the list of all registered users, and retrieving specific sets of parameters from a profile instead of the full profile.

Features

This module covers the implementation of the following features:

Query & Modify User Parameters
- Get user-specific parameters
- Set user-specific parameters

Artifacts

The following Maven artifact from the Context repository is related to the Profiling Server module.

org.universAAL.context/ctxt.prof.server: The core of the Profiling Server.

Installation

To get the Profiling server working currently you need to include the CHE first, and make sure you included the Profiling ontology (and their dependencies). The Profiling server and the CHE use data serialization so you will have to include it in the middleware. That would be:

...Middleware bundles (with mw.data.serialization)...
(Ont) org.universAAL.ontology/ont.profile/x.y.z
(Ont) org.universAAL.ontology/ont.che/x.y.z
(CHE) org.openrdf.sesame/sesame-runtime-osgi/2.6.0
(CHE) org.universAAL.context/ctxt.che/x.y.z
org.universAAL.context/ctxt.prof.server/x.y.z

The version of uAAL bundles is not shown, as this changes with every release. Another way to include the Profiling Server is to use its composite bundle (scan-composite:mvn:org.universAAL.context/ctxt.prof.server/x.y.0/composite) or the Profiling Server Karaf feature (uAAL-ctxt.Profiling.Server) from the Context features.

Configuration

The Profiling server does not require any configuration at the time being. However, for all services to be available and properly working, the preload of ontologies must be activated in the Context History Entrepot, with the parameter STORE.PRELOAD=true.

Provided services

The Profiling server implements service profiles over the ProfilingService ontology given by ont.profile. This is a service ontology which has a handle over the concept Profilable. From there, the Profiling server provides a handful of services for handling users, profiles and related stuff. It provides the typical editor services: GET, ADD, CHANGE and REMOVE, over the 3 levels of "profilability" in the profiling ontology: Profilable entities, Profiles and Subprofiles. Thus all combinations of the following are provided:

GET ADD CHANGE REMOVE	-	PFOFILABLE PROFILE SUBPROFILE

Since the meaning of the typical editor services may be a bit imprecise in some aspects, here is an explanation:

GET: Takes a parameter (PROFILABLE, PROFILE or SUBPROFILE) as input, but it is only interested in its URI. It returns the same parameter (the Resource with he same URI) but with all its information that was stored into the context store. This is meant to be used when you only know the URI of such a Resource but want all its information. For instance, you have a User with URI :user1 and you want to get its UserProfile.
ADD: Plain simple, it adds the parameter to the context store. Take into account that it will store all the information it carries along. That is, if you just pass a User with its URI, only that will be stored. But if you set its UserProfile before sending it, it will also be stored (as long as the serialization type allows it!).
CHANGE: This could have several meanings. What the server currently does is removing the information about the Resource with the same URI as the passed one, and then add it as it is passed. It´s like a concatenation of REMOVE and then ADD, with the difference of keeping "third party" information (all references to the parameter made by already stored information are kept).
REMOVE: It cleanses the store from any reference to the passed parameter. Take into account however that its properties will remain: e.g. If you remove a User that had a UserProfile, the UserProfile will remain. Notice as well that this may affect other stored information that had references to the removed Resource.

The Profiling server also includes other helpful services to get the information you want faster:

GET USERS: It does not take any input. It just returns all stored User resources in the store. Take into account that these Users only contain their URI, and no other additional property. Each returned resource may be of different User type (User, AP, Caregiver). Make sure you use check its type before casting.

There are many other services that are built as a GET and ADD of a Resource for a given upper-level "owner" Resource:

GET ADD	-	a PROFILE a SUBPROFILE	-	to a PFOFILABLE to a PROFILE

So you can for instance get all subprofiles of a user profile, or add a specific subprofile to a user.

Code samples

Service request for GET a Resource (Profilable, Profile or SubProfile)

 ServiceRequest req = new ServiceRequest(new ProfilingService(null),null);
 req.addValueFilter(new String[] { <PATH> }, <INSTANCE>);
 req.addRequiredOutput(ARG_OUT, new String[] { <PATH> });

Service request for ADD a Resource (Profilable, Profile or SubProfile)

 ServiceRequest req = new ServiceRequest(new ProfilingService(null),null);
 req.addAddEffect(new String[] { <PATH> }, <INSTANCE>);

Service request for CHANGE a Resource (Profilable, Profile or SubProfile)

 ServiceRequest req = new ServiceRequest(new ProfilingService(null),null);
 req.addChangeEffect(new String[] { <PATH> },<INSTANCE>);

Service request for REMOVE a Resource (Profilable, Profile or SubProfile)

 ServiceRequest req = new ServiceRequest(new ProfilingService(null),null);
 MergedRestriction r1 = MergedRestriction.getFixedValueRestriction(<PATHLAST>, <INSTANCE>);
 req.getRequestedService().addInstanceLevelRestriction(r1,new String[] { <PATH> });
 req.addRemoveEffect(new String[] { <PATH> });

Service request for GET USERS

 ServiceRequest req = new ServiceRequest(new ProfilingService(null),null);
 req.addRequiredOutput(ARG_OUT, new String[] { ProfilingService.PROP_CONTROLS });

Service request for GET a Resource (Profile or SubProfile) that is "owned" by an above Resource (Profilable or Profile)

 ServiceRequest req = new ServiceRequest(new ProfilingService(null),null);
 req.addValueFilter(new String[] { <PATH-owner> }, <INSTANCE-owner>);
 req.addRequiredOutput(ARG_OUT, new String[] { <PATH-owned> });

Service request for ADD a Resource (Profile or SubProfile) that is "owned" by an above Resource (Profilable or Profile)

 ServiceRequest req = new ServiceRequest(new ProfilingService(null),null);
 req.addValueFilter(new String[] { <PATH-owner> }, <INSTANCE-owner>);
 req.addAddEffect(new String[] { <PATH-owned> }, <INSTANCE-owned>);

Where represents the instance of the Resource (Profilable, Profile or SubProfile) you want to pass as parameter.

represents the path from the service root to the parameter:

For Profilable: ProfilingService.PROP_CONTROLS

For Profile: ProfilingService.PROP_CONTROLS, Profilable.PROP_HAS_PROFILE

For Subprofile: ProfilingService.PROP_CONTROLS, Profilable.PROP_HAS_PROFILE, Profile.PROP_HAS_SUB_PROFILE

And is the last comma-separated value of the used.