Document pddl type definition

[tobiaswjohn]

Document how pddl types can be defined in the ontology. See #20 as a reference.
This part of the ontology is not translated (as the rest of the ontology is), so documentation is necessary as the behavior might be unexpected.

[chcorbato]

Nice job on #20 @tobiaswjohn !
I would like to understand better the implications of this modelling solution, which I briefly discussed with @Rezenders
What do you mean with this part of the ontology not being translated into PDDL? Do I understand it correctly that it is not content to be translated, but rather meta-data on the ontology about HOW to transform?

I agree this is important to document in the paper.

Here are my thoughts:
Ideally, we would like to have an ontology that is independent of any potential use with PDDL planners, it is just a representation of a domain (in this case self-adaptive systems) following an OWL interpretation.
However, due to the practicalities of translating our ontology into PDDL, we need to add additional information on HOW to process the ontology elements in that translation. This is what pddl type addresses, right?
However, adding these types adds elements that do not model the domain the ontology captures.

The question could be:
Are there other ways we could add this meta-data about how to parse the ontology for PDDL planning?

I have seen in other ontologies the use of annotations to capture additional, non-formal information. Despite this recommendation from OWL 2 specification:

OWL 2 provides several built-in annotation properties for ontology annotations. The usage of these annotation properties on entities other than ontologies is discouraged.

Maybe we could use annotations for our purpose.
See how the menu to add them looks like no Protege:

This does not solve the issue of adding extra, non-domain related, modelling elements in our ontology.
We could work around this by creating the annotations in a separate file that imports the original ontology.
By the way, this could also address the problem in your solution too, haha

There may be other approaches, even recommended practices for this, but so far I have not found them. Do you or Einar know, or someone in your department?

[Rezenders]

Document how pddl types can be defined in the ontology. See #20 as a reference.
This part of the ontology is not translated (as the rest of the ontology is), so documentation is necessary as the behavior might be unexpected.

@tobiaswjohn I am trying to use PDDL types now, but I am a bit confused about how it works. I added a type_function and type_function_design to the navigation ontology and used the OWLToPDDL script to generate the PDDL files, but the function and function-design types are not added to the PDDL domain formulation. What should I do to make it work?

[tobiaswjohn]

I suspect, the problem is, that you use different IRIs than the ones that I defined to be used. I.e., you use hasPddlType and all the other IRIs in the correct way, but with the incorrect prefix. You use tomasys:hasPddlType but you should use pddl:hasPddlType with

@prefix pddl: <http://www.metacontrol.org/pddl#> .

I defined this prefix, to keep information about pddl types and information about self-adaptation separately. In order for the types to work correctly, the whole IRI, including the prefix, has to match the one that I specified. An example with the correct prefix is in the following file: suave_types.

[Rezenders]

Ok, thanks. It worked.
To make it easier to reuse it, I added a pddl.owl ontology to the pddl_tomasys repo. I will add all the tomasys types there later