Remove class 'Service'

[cstockloew]

The class 'Service' and its sub classes make it very difficult to implement automatic service composition. It is a concept that is defined only in universAAL; no other ontology provides it.

This class (and the classs hierarchy) should be removed. Investigate possibilities to formulate service requests and perform the matchmaking without this class.

[amedranogil]

I am baffled by this proposition. Other than the technical implications I wonder if it is such a good idea.
Since some time back I was thinking about a hierarchy of services looking at universAAL from a platform perspective, stating some "essential" services that could then be implemented by 3rd parties, the idea was to cover "traditional" services like contact management, calendar management, application management, etc.. As you see these would be more UI oriented in other to give the user some sort of completeness.
Removing the Service class does not jeopardize this proposition, it can still be ontologically modelled, but I still see some hierarchy of services (at least in the sense I describe above, which of course does not cover all services).

[cstockloew]

see uaal issues S1:

Class 'Service' prevents automatic service (de-)composition
One of the nice potential feature of having a semantic service description is an automatic service (de-)composition (I guess it depends on the definition whether you call it composition or de-composition) that is done by the bus. For example, you have services getAllLamps() and turnOff(lampID), then you can create a new service turnOffAllLamps() automatically on the fly by first calling getAllLamps and then call turnOff for each lamp. However, this only works if the Service class is the same.
Now suppose you have turnOff(lampID) and getLocationOfPhThing(y) and you want to automatically realize a service turnOffAtLocation(y). This is not possible because the bus cannot know which Service class to use (e.g. SpaceConfigurationService).
If we completely remove the class Service, we may end up with a much easier service description having something like "get property x of thing y" that is also more intuitive to use.
BTW 1: in the current ontologies, most Service classes just have a property like "manages" or "controls". If we mostly only have one property (and mostly with the same name), then the need of this class should be re-thought.
BTW 2: NO other ontology defines this class, it's a uaal-specific thing. OWL-S has something like a service category, but this is more like meta-data.
However, there may be problems when using OWL-Conditions (what we have as "filter") without a Service class; this must be investigated.
Additionally, there is the question about service (de-)composition with different effects (not only services without effects that just have an output). If you have a request with 2 or more effects and this could be realized with 2 or more services, but one of those service calls fails – what should you do then? I think this is a uaal-specific problem as most other existing frameworks have the service discovery independent from invocation. When receiving the requested service (which may be atomic or composite), then it's up to the client to execute the call or the execute the composite service..

[cstockloew]

There can still be a "hierarchy", or classification, of services that is based on the ontologies (because there is a hierachy of ontologies) and of the actual service profile (it's effects, return values..).

[Alfiva]

From a "hands-on" practical point of view of the people that I know have made services for uAAL, they mostly do not need the Service ontology class toher than because it is needed.
I agree with getting rid of it in the sense that it would make thing simpler: e.g. devs don't need to go look into the ontology lists which particular service ontology to use. That would seem to contradict what we sell about not having to be explicit in your calls.
For solving technical problems, perhaps we can find a compromise and just use the generic Service class, and not the subclasses (e.g. DeviceService, AgendaService), like some sort of container.
For scenarios where it is useful to actually have that hierarchy, perhaps some "optional" "metadata" approach is useful.