This wiki has been archived and is now read-only.

Final Report Issues & Challenges

From Decision XG
Jump to: navigation, search

Issues & Challenges

  • Issue: we need to build a format that can be useful both for simple use-cases as well as more complex ones (e.g. involving reasoning)
    • Proposal: we build a highly modular ontology, where you can reuse different components depending on your needs and requirements on complexity and detail. For example, I have built a set of very small and simple ontologies that illustrate the idea, see below.
      • First you have an ontology about people. It is very simple, just the class Person and a few datatype properties (name and age).
      • Then you have an ontology about animals. It is equally simple, defining the class Animal and a few datatype properties (name and age).
      • I can use each of the ontologies independently of each other. If I just want to talk about people I use one, if I just need to say something about an animal I use the other. But what if I want to say something about both, e.g. that a person can have a pet which is an animal? Let's make another ontology about pets, import the two previous ontologies and then add an object property "hasPet".
      • Well, but what if my use-case is more complex? I want to also reason on the people in a knowledge base, and define a class called "animal lover" which is defined as the people who has some pet so that I can classify my instances? Simple, I just create a new ontology, import my pet ontology and define a new class for the animal lovers that are the people who have some pet (all the other classes and properties I need are already defined in the imported ontologies, so I just add one class and one restriction).
      • Finally, I may have the use-case that I want to add some data, but I don't want to distribute the data with the ontology of course. Simple, I just make an RDF file that reuses the vocabulary of my ontology (in this case the pet ontology and its imports). Then the complete knowledge base, can be combined in another file if needed.
      • If we take the same approach for decision representation, we can create a "family" of small vocabularies, where some are very simple and some are much more complex, but they all build on one another to support different use-cases. As long as we give good documentation for each one it should be easy to choose the right "level of complexity" when somebody wants to reuse the format, they don't have to care about the complex stuff if they don't want to.
      • Are there downsides? The only one I can think of now is that these small modules will have different namespaces, so the more complex an ontology you wan tot reuse, the more namespaces you have to keep track of.