Make bus models semantic

[cstockloew]

The buses currently use a mixture of owl:classes and rdf:classes. The definition is quite unclear to me, e.g.:

• Context: Event+Pattern are RDF, Provider+ProviderType are OWL
• Service: Service+UserInterfaceService are OWL, but most of the others are RDF, especially the ones from OWL-S which even claims to be an upper ontology
• UI: The complete model for Form(-elements) is only RDF

IMHO, the classes should ALL be owl:classes. Not only can they (at least partly) be considered upper ontologies, there is also the problem when using them inside other Events/Requests. This is currently the case for ont.che which has re-defined the ContextEvent so that it can be used in service request for CHE. But we don't need a second ContextEvent if we would elevate the rdf:classes in the buses to owl:classes.

When we do the change, we probably also have to change ScopedResource to a subclass of ManagedIndividual (maybe rename it to ScopedManagedIndividual). The java package names can stay, although the ui model is currently in org.universAAL.middleware.ui.rdf. This would then be formally not correct (correct would be ..ui.owl or ...ui.model). However, renaming this package name could require some work and incompatibilities.

This issue is somehow related to #4 .

[Alfiva]

I think that's fine, especially concerning the ont.che. Although I wonder what effect it will have on ontology data once stored in CHE (becuase of the inferencing, mayeb it becomes slower...). But don't let this stop the initiative.

[amedranogil]

I think in UI DM there are similar problems.
The change will not affect the current implementation, as some internalmessages have already been "semantizised" (If I remember correctly)

[cstockloew]

@Alfiva : if the structure is the same, just different URIs, then for inferencing it should not make a difference. It is however a problem if you have data in CHE and migrate to a new version if the URIs in ont.che are different from the URIs in context bus. In that case, it might be necessary to provide a converter to update the existing data (maybe it can be done with some sparql queries with tool.sparql-tester).

@amedranogil : if somthing has been "semantizised" internally, then there is probably some data structure duplicated which can be removed. This should make the code more simple and manageable.