| Version: | 0.1.0 |
|---|---|
| Provider: | PUT |
| SOAP service’s name: | |
ElectreConcordanceReinforcedPreference-PUT (see SOAP requests for details) |
|
Computes concordance matrix using procedure which is common to the most methods from the Electre family.
This module is an extended version of ‘ElectreConcordance’ - it brings the concept of ‘reinforced_preference’, which boils down to the new threshold of the same name and a new input file where the ‘reinforcement factors’ are defined (one for each criterion where ‘reinforced_preference’ threshold is present).
Web page: http://github.com/xor-xor/electre_diviz
Reference: Bernard Roy and Roman Słowiński; Handling effects of reinforced preference and counter-veto in credibility of outranking; European Journal of Operational Research 188(1):185–190; 2008; doi:10.1016/j.ejor.2007.04.005
(For outputs, see below)
Criteria to consider, possibly with ‘preference’, ‘indifference’ and ‘reinforced preference’ thresholds (see also ‘reinforcement_factors’ input below). Each criterion must have a preference direction specified (min or max). It is worth mentioning that this module allows to define thresholds as constants as well as linear functions.
The input value should be a valid XMCDA document whose main tag is <criteria>.
Alternatives to consider.
The input value should be a valid XMCDA document whose main tag is <alternatives>.
The performance of alternatives.
The input value should be a valid XMCDA document whose main tag is <performanceTable>.
The performance of profiles (boundary or central).
The input value should be a valid XMCDA document whose main tag is <performanceTable>.
Weights of criteria to consider.
The input value should be a valid XMCDA document whose main tag is <criteriaValues>.
Definitions of so-called ‘reinforcement factors’, one per each criterion for which ‘reinforcement threshold’ has been defined. For more regarding these concepts see the paper from ‘Reference’ section.
Technically, this input is optional, but it doesn’t make much sense to use ‘ElectreConcordanceReinforcedPreference’ without it, since in such scenario it will fall back to ‘ElectreConcordance’.
The input value should be a valid XMCDA document whose main tag is <criteriaValues>.
Definitions of profiles (boundary or central) which should be used for classes (categories) representation.
The input value should be a valid XMCDA document whose main tag is <categoriesProfiles>.
This parameter specifies the type of elements provided for comparison.
Choosing ‘boundary_profiles’ or ‘central_profiles’ requires providing inputs ‘classes_profiles’ and ‘profiles_performance_table’ as well (which are optional by default).
The input value should be a valid XMCDA document whose main tag is <methodParameters>.
It must have the following form:
<methodParameters>
<parameter name="comparison_with">
<value>
<label>%1</label>
</value>
</parameter>
</methodParameters>
where:
%1 is a parameter named “comparison_with”. It can have the following values:
alternatives: alternatives vs alternativesboundary_profiles: alternatives vs boundary profilescentral_profiles: alternatives vs central (characteristic) profilesThe default value is item0.
Concordance matrix computed from the given data. This matrix aggregates partial concordances from all criteria into single concordance index per pair of alternatives or alternatives/profiles.
The returned value is a XMCDA document whose main tag is <alternativesComparisons>.
Messages or errors generated by this module.
The returned value is a XMCDA document whose main tag is <methodMessages>.