Ci-dessous un texte rédigé à la suite de notre réunion début juillet, qui peut éclairer certains choix proposés dans le schéma XML.
Proposition sur la définition des facteurs pour le schéma expDesign XML de la BaO Mexico
HM, le 4/7/09
Introduction
Suite à la réunion des 2 et 3 juillet 2009 à Paris, l'un des éléments à finir de préciser concernait la façon de décrire les facteurs du plan d'expériences. Ci-dessous une proposition qui vise à simplifier et à favoriser la généricité, en tenant compte des différents échanges au cours de la réunion. Le lien avec la description des facteurs sous R est également discuté. La redondance de certaines informations dans le schéma XML est évitée, me semble-t-il, ainsi que la complication qui résulterait de vouloir traiter trop de cas particuliers dans la structure même du schéma.
Proposition pour le schéma XML
Principe
Un facteur est décrit par:
-- un nombre restreint d'attributs (3 ou 4 vraiment essentiels, par exemple 'name', 'id', 'unit');
-- un élément DOMAINE;
-- une liste ouverte d'éléments FEATURE (sans vouloir forcément imposer ce terme).
Le DOMAINE est décrit systématiquement sous la forme d'une distribution de probabilité, c'est-à-dire par:
-- les attributs 'distributionName' (obligatoire) et 'nominalValue' (facultatif)
-- une liste ouverte d'éléments 'distributionParameter', d'attributs 'name' et 'value', qui précisent la distribution choisie;
-- lorsque le facteur est catégoriel, la liste de ses niveaux, par une liste ouverte d'éléments 'level', d'attributs 'value' et 'weight')
[voir plus bas pour les différentes façons de simplifier cette déclaration de niveaux].
Les FEATURE ont un attribut 'name' et un attribut 'value'. Ils permettent de préciser les caractéristiques des facteurs nécessaires pour certaines méthodes. Par rapport aux discussions du 3 juillet, certaines caractéristiques des facteurs mises dans les attributs seraient plutôt gérées comme des features, par exemple:
-- 'nlevels' (un nombre, nécessaire pour les facteurs continus quand on utilise certains plans factoriels),
-- 'ordered' (TRUE/FALSE, nécessaire pour les facteurs discrets dans les méthodes qui exploitent cette distinction),
-- 'group' (un nombre ou une chaine de caractères, nécessaire pour les méthodes qui regroupent certains indices par groupes de facteurs),
-- 'type' (pour distinguer variable de décision, paramètre incertain, et variable d'entrée du modèle code),
-- etc.
Exemples (désolé si ma syntaxe n'est pas très claire)
<FACTEUR name="A" id="tauxCroissance" unit="g/jour">
-> <DOMAINE distributionName="uniforme" nominalValue=18>
-> <distributionParameter name="min" value=12>
-> <distributionParameter name="max" value=24>
-> <feature name="group" value="croissance">
-> <feature name="type" value="modelParameter">
-> <feature name="nlevels" value=5>
<FACTEUR name="B" id="departement">
-> <DOMAINE distributionName="categorical" nominalValue="Morbihan">
-> <level name="Morbihan" weight=2>
-> <level name="Charente" weight=1>
-> <level name="Finistère" weight=1>
-> <feature name="group" value="origine">
-> <feature name="type" value="inputVariable">
<FACTEUR name="C" id="age" unit="mois">
-> <DOMAINE distributionName="sequence" nominalValue=3>
-> <distributionParameter name="min" value=1>
-> <distributionParameter name="max" value=5>
-> <distributionParameter name="step" value=2>
-> <feature name="group" value="croissance">
-> <feature name="type" value="inputVariable">
Commentaires
*** Sur les features:
Beaucoup d'autres possibilités de features peuvent apparaitre lorsque les méthodes se développeront, c'est pouquoi il est important de laisser la liste ouverte. Bien entendu, certains des features sont appelés à être appelés fréquemment et il faudra choisir soigneusement comment les
définir. Mais cela relèvera des méthodes plutôt que de la définition de la structure XML proprement dite.
*** Sur les distributions:
On abandonne, avec cette proposition, la distinction explicite entre facteurs continus, discrets ordonnés et discrets non ordonnés. L'utilisation d'une telle typologie sera gérée directement par
les méthodes ou par un parser en amont des méthodes. L'idée est que distribName contient déjà l'information sur la nature (continue, discrète, ordonnée) du facteur, donc pas besoin d'en rajouter. Et s'il le faut pour une application, on pourra toujours passer par une feature.
Pour les termes à employer, l'idée est d'utiliser au maximum la terminologie de R pour le nom des distributions et le nom des paramètres. Cela couvrira beaucoup de cas, dont le cas standard de la
distribution uniforme sur un intervalle défini par un min et un max. Pour le cas des facteurs discrets, il faudra définir un ou deux noms de distribution propres à la BaO pour gérer les différents cas de
figure. Par exemple:
-- distribName='categorical' pour les facteurs discrets non ordonnés dont on donne explicitement la liste des niveaux et (éventuellement) des pondérations
-- distribName='sequence' pour les facteurs discrets (ordonnés ou non), dont les niveaux sont décrits selon la syntaxe de la commande 'seq()' de R.