Use Case OLD Core Decision Model

From Decision XG
Revision as of 14:40, 13 September 2010 by Eblomqvi (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Core decision representation for LOD use case

For the use case we need components such as:

  • The decision itself
  • The options
  • The criteria
  • Weights of criteria

Considering the LOD use case description:

Context

An organization or individual wants to use the open government data for making decisions.


Story: Open Linked Data Supports Decision-Making

The user would like to select applicable data sets in the form of RDF data stores (so that they can be easily combined), then select certain data components as options (e.g. cities) and select other data components as criteria for filtering and ordering of the options (e.g. number of earthquakes, amount of federal disaster relief, etc.). The user would then like to form a SPARQL query which could perform the query, filtering and ordering across the data sets to essentially assess and rank order the options based on the criteria. The rank ordering represents the assessment based on the weighted criteria. The user would then make the selection from the rank ordered list representing the final decision. In short, the user would like to use open linked data for decision-making.


We can derive the following CQs related to the core format of the decision:

  * What are the options of this decision?
  * What are criteria of this decision?
  * What is the weight of this criteria?
  * What is the selected option based on the ranked options?

Possibly we could also add that a decision obviously has some question that needs to be answered:

  * What is the question underlying this decision?


Issues:

  * What is a decision really? I suppose it is the collection of the things above, 
   and one necessary criteria is that it has a selected option, before that it is 
   not a decision. But if options are data items from a data set, and the selection 
   option is one data item, what is the decision? For example: if the question is 
   "where should I move?", and we want to move where there has been the least earthquakes. 
   Then if the options are the earthquake data, and the selected option is the smallest 
   earthquake, is this the decision? The real 
   decision would be "I will move to city x because there was the smallest/fewest 
   earthquakes", and the smallest earthquake is only the thing that supports that 
   decision, i.e., something like the fact that finally convinced me, but not the 
   decision itself. How to distinguish between this? How do we record the actual 
   decision vs. the "supporting fact"? It seems we need some "high-level" decisions 
   and some lower level sub-decision which for instance select the data for us. But 
   we probably need to incorporate all these levels if we want a flexible model.

Draft Solution

Two patterns/ontologies have been developed based on the above CQs (and revised after the decision incubator meeting discussion on September 2nd, the previous versions of the modules can still be accessed if you add "_old" before ".owl" to the filename):

  • A core decision module (Decision.owl) including only decisions, their options, question and the selected option.
  • An extended decision module (DecisionCriteria.owl) importing the basic decision model but adding the notion of criteria and weights.

Additionally there is an example with some instances illustrating the usage of the modules.

Issues discussed on the 2nd of September:

  • Does the information realization pattern really correctly describe an option and a set of data describing it? Most likely not - it is more like a "description" of the option rather than a realization.
  • We need to apply this pattern and describe different types of data to determine if there are more flaws and if this can fit to situations of differing complexity.

Some issues raised by Piotr Novara in an e-mail (in addition to the above):

  • There are different ways to model the criteria, and the parameter pattern makes the model complex. Why not have the criteria as a situation?
  • Why is the "concept"-class needed? - Raises the issue of importing OWL model of pattern rather than just being inspired by the pattern solution. Eventually, we need to decide on a policy.
  • Issue indirectly raised: naming is incorrect, singular should be "Criterion" (current version is plural, which is usually bad naming - sorry, not yet updated in the latest version).

Additional issues/points of discussion that came up when producing the revised version:

  • What about the simplest representation of an option or a question, i.e. just a text string describing it in natural language, should we represent this as an instance of OptionDescription with a datatype property for the string? Or, as it is done now, as a datatype property directly related to the Option? Perhaps we should modularize the Decision.owl even further, so that the question and option descriptions are put in a separate module, so that that is already an extension to the most basic module, i.e. with only string properties to describe the option/question.
  • What is no called a criteria, is actually a kind of situation (thanks to Piotr for pointing this out!), so should it be moved from the Concept class to the Situation class? And in that case, do we need the concept class at all? Should we remove the parameter-pattern all together?

A walk-through of the example in DecisionCriteriaExample.owl:

(to be added...)