search

universAAL / middleware

The core software that uses semantic matchmaking for brokering messages among participants of an open distributed system.
10 stars 3 forks source link

Type restriction for ConfigurationParameter.PROP_VALUE #494

Open saiedt opened 6 years ago

saiedt commented 6 years ago

In org.universAAL.middleware.managers.configuration.core.owl.ConfigurationOntology there are the following type restrictions for ConfigurationParameter.PROP_VALUE:

oci_ConfigurationParameter
    .addObjectProperty(ConfigurationParameter.PROP_VALUE)
        .setFunctional();
oci_ConfigurationParameter.addRestriction(
        MergedRestriction.getCardinalityRestriction(
                ConfigurationParameter.PROP_VALUE, 1, 1));

There are several issues here:

  1. ConfigurationParameter.PROP_VALUE has been added as an owl:ObjectProperty. Does that mean that no conf paramers may have a literal value? I can live with that but maybe there are cases where a conf param has a literal value....
  2. Both of setFunctional() and the cardinality restriction are limiting the max cardinality to 1, but this does not make sense as a general restriction because at least in my case, all of my conf params accept a list of individuals as value.

My suggestion is

  1. to have two different properties ConfigurationParameter.PROP_OBJECT_VALUE and ConfigurationParameter.PROP_DATATYPE_VALUE to resolve the first issue,
  2. not to call setFunctional() on them, and
  3. to define the cardinality restriction with -1 for max cardinality to allow arbitrary number of values.

If this is done in this way, then please take into account that ConfigurationParameter#setValue(Object) must decide to set which of the two props, depending on the type of the parameter (which maybe a single literal value, a single individual, a list of literal values or a list of individuals) and ConfigurationParameter#getValue() must check which of the two props has been set before and return that one. In any case, the return value may again be a list.

amedranogil commented 6 years ago

for problem 1. this is not the first time we have seen this problem in universAAL ontologies. Particularly in very abstract ontologies where the property is very open. is there a way to define a property just at RDF level, and not add the property type. The problem with adding an additional property for the value is that the code will need to be changed thoroughly; where the current code should be agnostic on the property type.

As for the setFunctional, and cardinalities, this is indeed residues from using the ontology modelling tool; and therefore can be (mostly) removed. I would have to check the code to see if it is agnositc enough to treat multivalue properties adequately.

saiedt commented 6 years ago

Suggested changes in code have been submitted to Alejandro for double check and possibly commit in both 3.4.1-SNAPSHOT and 3.4.2-SNAPSHOT.

cstockloew commented 6 years ago

We have the same problem in the device ont (hasValue) as discussed here: https://github.com/universAAL/ontology/issues/7

@saiedt : Can the fix be applied there as well?