mw.data.representation could allow easier property definition

[amedranogil]

when adding an objectProteprty or a dataProperty, adding PropertyExpressions is difficult.

The ObjectPropertySetup can not later be retrieved.

all Property Axioms (such as setAssymetric(), or setFunctional() ) return void, thus one cannot easily express more than one (eg: oci.addObjectProperty(PROP).setAssymetric().setFunctional() ).

[cstockloew]

I don't understand what you mean with "later" and the formatting is screwed, so your pull request shows all lines as changed and it's not easy to see what you have changed.

If you mean, after the ontology is registered, maybe even by a different module:

Actually, this was very much intended!
The thing is: the ontology is the model, and is therefore fix. It cannot change at runtime, it can only be extended and refined by additional ontologies. That was the whole purpose of having the Setup-Interfaces, making them available only to the module that registers the ontology, and to lock the setup at the end of the ontology registration. Changing this could cause security issues.
If you want to extend an existing class, use extendExistingOntClassInfo.
I now see that there is an extendExistingDatatypeProperty and extendExistingObjectProperty missing in OntClassInfoSetup and could be added.

If by "later" you mean directly after one method call (e.g. 0.2 sec "later"), you can use

ObjectPropertySetup ops = oci.addObjectProperty(PROP);
ops.setAssymetric();
ops.setFunctional();

However, for convenience, the method definitions can also be changed to return the this-object instead of void to allow for multiple calls in one line, like you said: oci.addObjectProperty(PROP).setAssymetric().setFunctional() .

[amedranogil]

However, for convenience, the method definitions can also be changed to return the this-object instead of void to allow for multiple calls in one line, like you said: oci.addObjectProperty(PROP).setAssymetric().setFunctional() .

This exactly what the pull request imlpements (sorry for the format)

I agree with you in the sense of the model being fixed; and I understand the rationale. However, because in OWL property definitions are at the same level as Class definitions, you can extend also properties in other ontologies, just as you extend classes. This is just a feature of OWL, of course it should not be used, and I do not intend to use it; but I was just wondering how it would mat to uAAL

[cstockloew]

you can extend also properties in other ontologies, just as you extend classes. This is just a feature of OWL, of course it should not be used, and I do not intend to use it; but I was just wondering how it would mat to uAAL

->

I now see that there is an extendExistingDatatypeProperty and extendExistingObjectProperty missing in OntClassInfoSetup and could be added.

The Ontology class has methods for createNewOntClassInfo(..) AND extendExistingOntClassInfo(..). The second method allows to add more semantic info to an existing class. Formally, the only difference between the 2 methods is that the createNewOntClassInfo-methods add the triple
myOntClassName a owl:class;

The same applies to properties; there should also be methods to extendExistingXXProperty; those are currently missing.
But I'm actually not sure if the methods to add/extend props should be OntClassInfoSetup at all; they should actually be in Ontology...