Provider: | PUT |
---|---|
Version: | 1.0 |
Depending on the need, for a given not satisfied preference relation between two alternatives: “a is preferred to b”, the module finds one of the two possible types of values. These are the minimal improvement of the performance of alternative a or the minimal missing value of the comprehensive score of this alternative. In the first case, the procedure finds a maximal greater than one value, that multiplied by the performances on chosen criteria allows to attain a truth of mentioned preference relation. In the other case, it finds the minimal value that need to be added to the comprehensive score of this alternative in order to attain the truth of this relation. In both cases it is possible to consider the truth of mentioned relation for both all or at least one value function. Function supports a hierarchical decomposition of the problem.
(For outputs, see below)
A list of all considered criteria. The input value should be a valid XMCDA document whose main tag is criteria.
Tag: criteria
Code:
<criteria>
<criterion id="%1" name="%1"></criterion>
[...]
</criteria>
Optional: yes, enabled by default
A set of ids of the criteria that should be taken into account for modification of the performances. This parameter is used only if the modification of performances is searched.
Tag: criteriaSets
Code:
<criteriaSets>
<criteriaSet>
<element><criterionID>[...]</criterionID></element>
[...]
</criteriaSet>
<criteriaSets>
The list of all considered alternatives. The input value should be a valid XMCDA document whose main tag is alternatives. Each alternative may be described using two attributes: id and name. While the first one denotes a machine readable name, the second represents a human readable name.
Tag: alternatives
Code:
<alternatives>
<alternative id="%1" name="%2" />
[...]
</alternatives>
Description of the hierarchical structure of criteria. Each node of this hierarchy needs to have a unique id attribute. The most nested nodes, should contain a set of criteria. The input value should be provided as a valid XMCDA document whose main tag is hierarchy
Tag: hierarchy
Code:
<hierarchy>
<node id="nodes">
<node id="nodes1">
<criteriaSet>
<element><criterionID>%1</criterionID></element> [...]
</criteriaSet>
</node>
[...]
</node>
[...]
</hierarchy>
Description of evaluation of alternatives on different criteria. It is required to provide the IDs of both criteria and alternatives described previously. The input value should be provided as a valid XMCDA document whose main tag is performanceTable
Tag: performanceTable
Code:
<performanceTable>
<alternativePerformances>
<alternativeID>%1</alternativeID>
<performance>
<criterionID>%2</criterionID>
<value>
<real>%3</real>
</value>
</performance>
[...]
</alternativePerformances>
[...]
</performanceTable>
Optional: yes, enabled by default
A set of values associated with the criteria. This input allows to determine what type of value function should be used for the particular criterion. For each criterion that has an associated greater than one value, a piecewise linear value function is used. In this case, the mentioned value denotes a number of characteristic points of this value function. For the criteria that are not listed in this file, or for these for which the provided values are lower than two uses a general value function. The input value should be provided as a valid XMCDA document whose main tag is criteriaValues. Each element should contain both an id of the criterion, and value tag.
Tag: criteriaValues
Code:
<criteriaValues>
<criterionValue>
<criterionID>%1</criterionID>
<value>
<integer>%2</integer>
</value>
</criterionValue>
[...]
</criteriaValues>
Description of the target to be achieved. it has a form of the weak preference relation. The input value should be provided as a valid XMCDA document whose main tag is alternativesComparisons. It should contain only one pair of alternative ids that distinguish the weak preference relation between two alternatives. It may be interpreted as “The first alternative should be weakly preffered to the second one.
Tag: alternativesComparisons
Code:
<alternativesComparisons>
<pairs>
<pair>
<initial>
<alternativeID>%1</alternativeID>
</initial>
<terminal>
<alternativeID>%2</alternativeID>
</terminal>
</pair>
</pairs>
</alternativesComparisons>
Optional: yes, enabled by default
Set of pairwise comparisons of reference alternatives. For a pair of alternatives three types of comparisons are supported. These are the strict preference, weak preference, and indifference. Values linked to pairs indicate ids of nodes in the hierarchy of criteria tree. If value is not given or if it is equal to 0 pairwise comparison is assumed to concern for the whole set of criteria. Otherwise, the preference relation applies only to a particular node. The input value should be provided as a valid XMCDA document whose main tag is alternativesComparisons. For each type of comparison, a separate alternativesComparisons tag should be used. Within these groups a mentioned types are denoted using a comparisonType tag by respectively strict, weak, and indif label. Comparisons should be provided as pairs of alternatives ids.
Tag: alternativesComparisons
Code:
<alternativesComparisons>
<comparisonType>
%1<!-- type of preference: strong, weak, or indif -->
</comparisonType>
<pairs>
<pair>
<initial>
<alternativeID>%2</alternativeID>
</initial>
<terminal>
<alternativeID>%3</alternativeID>
</terminal>
<value>
<label>%4</label>
</value>
</pair>
[...]
</pairs>
</alternativesComparisons>
Optional: yes, enabled by default
Set of comparisons of intensities of preference. For a pair of preference relations three types of comparisons are supported. These are the strict preference, weak preference, and indifference. Values linked to pairs, determine ids of nodes in the hierarchy of criteria tree. If value is not given or if it is equal to 0 intensity of preference is assumed to concern for the whole set of criteria. Otherwise, the statement applies only to a particular node. The input value should be provided as a valid XMCDA document whose main tag is alternativesComparisons. For each type of comparison, a separate alternativesComparisons tag should be used. Within these groups aforementioned types are denoted using a comparisonType tag by respectively strict, weak, and indif label. Comparisons should be provided as pairs of two elementary sets of alternatives ids. The following form is expected:
Tag: alternativesComparisons
Code:
<alternativesComparisons>
<comparisonType>
%1<!-- type of preference: strong, weak, or indif -->
</comparisonType>
<pairs>
<pair>
<initial>
<alternativesSet>
<element>
<alternativeID>%2</alternativeID>
</element>
<element>
<alternativeID>%3</alternativeID>
</element>
</alternativesSet>
</initial>
<terminal>
<alternativesSet>
<element>
<alternativeID>%4</alternativeID>
</element>
<element>
<alternativeID>%5</alternativeID>
</element>
</alternativesSet>
</terminal>
<value>
<label>%6</label>
</value>
</pair>
</pairs>
</alternativesComparisons>
Optional: yes, enabled by default
Set of rank-related requirements. In other words it is a set of ranges of possible positions in the final ranking for a chosen alternatives. The label values linked to the alternatives, determines an ids of nodes in the hierarchy of criteria tree. If value is not given or if it is equal to 0 rank related requirement is assumed to concern for the whole set of criteria, Otherwise, the preference relation applies only for a particular node. The input value should be provided as a valid XMCDA document whose main tag is alternativesValues. Each requirement should contain both an id of the reffered alternative and pair of values that denote the desired range. This information should be provided within a separate alternativesValue tag.
Tag: alternativesValues
Code:
<alternativesValues>
<alternativeValue>
<alternativeID>%1</alternativeID>
<value>
<interval>
<lowerBound><integer>%2</integer></lowerBound>
<upperBound><integer>%3</integer></upperBound>
</interval>
</value>
<value>
<label>%4</label>
</value>
</alternativeValue>
</alternativesValues>
Name: Use strictly increasing value functions?
Single boolean value. Determines whether to use sctrictly increasing (true) or monotonously increasing (false) value functions.
Name: type of result
Type of searched value
Name: precision of the result
Name: Whether the target should be achieved possibly or necessarily?
One of the two label values (possible or necessary). This parameter determines does target should be satisfied by one (possible) or all(necessary) value functions
Tag: methodParameters
Code:
<methodParameters>
<parameter name="strict">
<value>
<boolean>%1</boolean>
</value>
</parameter>
<parameter name="type_of_result">
<value><label>%2</label></value>
</parameter>
<parameter name="precision">
<value>
<real>%3</real>
</value>
</parameter>
<parameter name="possible_or_necessary">
<value><label>%4</label></value>
</parameter>
</methodParameters>
A set of real values associated with the id of the considered alternative. Depending on the selected option, these values may denote the improvements of performances of the alternative or the missing values of its comprehensive score. The output value should be provided as a valid XMCDA document whose main tag is alternativesValues. Each alternatives values group describes another node of the hierarchy tree. The id attributes denotes the ids of considered nodes.
Tag: alternativesValues
Code:
<alternativesValues id=%1>
<alternativeValue>
<alternativeID>[...]</alternativeID>
<value>
<real>[...]</real>
</value>
</alternativeValue>
</alternativesValues>
A list of messages generated by the algorithm.
For further technical details on the web service underlying this program, have a look at its documentation here.