Questions

Factor

id et name ne sont ils pas redondants ?

Il s'agit tous les deux d'attributs de type identifiant. "Name" permet de donner au facteur, pour le plan d'expériences, un nom qui pourait être différent du nom utilisé dans le modèle de simulation. ID correspond au nom du facteur utilisé dans le modèle de simulation. Ceci permet de faciliter le mapping entre les noms des facteurs utilisés dans le modèle de simulation et ceux utilisés dans le logiciel de génération des plan d'expériences.

feature a quoi ca sert ?
feature a été introduit afin de rendre la définition du facteur plus souple et plus simple. Les propriétés 'évidentes' d'un facteur telles que son nom, son domaine de définition etc sont définies dans les attributs ou éléments explicites associés aux facteurs. "feature" permet d'apporter des informations supplémentaires pour mieux spécifier les facteurs quand une méthode le nécessite. Par exemple: a) pour les facteurs continus, nous avons introduit un "feature" nommé 'nlevels' qui permet de préciser que seuls 'nlevels' niveaux du facteur devraient être pris en compte dans le plan d'expérience généré: c'est un besoin assez particulier rencontré avec les plans factoriels classiques. b) pour préciser le type lexical des niveaux du facteur, on a introduit un feature nommé 'type' qui peut prendre comme valeur: string, integer, float, double, etc. Ceci facilitera les traitements des facteurs avec les programmes informatiques. c) pour les facteurs structurés en groupe, nous avons introduit un feature 'group'  qui permet d'expliciter les facteurs appartenant à un groupe spécifique, etc. 
 

level,préciser un peu (est-ce un niveau de facteur discret sans distribution)

Cet attribut a été introduit afin de déclarer explicitement les différents niveaux du facteur discret ordonné ou non-ordonné comme vous l'avez deviné dans vos messages.

Comme Nicolas l'a dit: ceci permet d'apporter des informations sémantiques aux facteurs, en l'occurence l'unité de mesure de leurs niveaux. Cela peut être utile lors de la restitution de résultats, par exemple dans des graphiques.

quel est l'intérêt de l'unité ?

dans process a quoi sert type ?

workflow a quoi sert name? type? et n'est ce pas redondant avec call

N'ayant pas participé à la spécification de cette partie du schéma, on laisse les autres y répondre ou ajouter des commentaires.

 

 

Remarque

Problème avec le workflow : call supporte déjà les paramètres normalement . il faut avoir une discussion autour du call pour les paramètres

Pour l'évaluation est-ce un run de chaque scenario ou de l'ensemble des scenarii en même temps?

 

Modifications a faire

factor

sur chaque factor il faudrait avoir une variable qui permette de préciser le type du facteur (discret - peut-être même distinguer numérique,non numérique- continu)

Dans la version du schéma proposée, ceci pourrait être résolu par l'utilisation de distributions "conventionnées Mexico", complétant les noms classiques de distributions.

Par exemple:

"categorical" → facteur discret non ordonnée

"discrete" → discret ordonné

"continuous uniform" → distribution uniforme sur un intervalle continu, etc.

 

Pendant la réunion de juillet, nous avons en effet beaucoup discuté de la typologie des distributions, sans réussir à converger. L'idée de la proposition est donc de ne pas avoir une distinction explicite des natures de facteurs dans le schéma XML, mais  d'en avoir une implicite à l'aide des noms de distribution (dont la signification exacte serait explicitée dans le manuel d'utilisation du schéma et gérée à l'étape de parsing ou d'appel d'une méthode). Cette approche apporte une meilleure extensibilité au schéma. En ce qui concerne la distinction "numérique", "non numérique", "continu", cela peut être géré de la même façon implicite: si une distribution est normale, elle est donc numérique et continue, si une distribution est "categorical", elle est donc discrète, etc. Ce type de distinction pourrait aussi, éventuellement, être géré par un "feature", mais cela ne nous parait pas forcément nécessaire.

 

il manque target dans factor

Est-ce que l'attribut 'ID' tel qu'il est défini auparavant permet de jouer le rôle du target?

domain

il faut que Nominalvalue soit un élément et non un type, car sinon difficile de mettre des matrices ou des équations.

Voir la partie 'Question" pour la prise en compte des facteurs matrice.

il faut modifier la syntaxe des matrices pour avoir plus de 2 dimensions possibles (reprendre la représentation du outputData.xsd)

 

distributionParameter

il faut que value soit un élément pour permettre de mettre une matrice

level

il faut que value soit un élément pour permettre de mettre une matrice. Il faut quelque chose pour permettre d'avoir en value de level de quoi passer un nom et des paramètres (il faut aussi permettre de mettre des listes)

list

dans les listes il faut pouvoir mettre des <call> (besoin pour les Rules) .

worflow

Dans le workflow il faut pouvoir référencer le XML du scenario qui sera exécuter

Nos questions et commentaires

1) Dans la proposition de Stéphanie, il y a un facteur nommé 'Nephrops Capturability' dont la définition nécessite la manipulation de matrices de dimension 10x3.

Avec le schéma actuel, une solution consiste à considérer que ce facteur se décompose en 10x3=30 facteurs, groupés en 10+3=13 groupes dans lesquels chaque ligne de la matrice forme un groupe (L1,..., L10) et chaque colonne forme aussi un groupe (C1, ..., C3). Ainsi, par exemple, l'élément  à la position de la matrice (1,1) peut être considéré comme un facteur structuré appartenant à la fois au groupe L1 et C1.

Une autre solution consiste à décomposer le facteur "matriciel" en 10x3=30 sous-facteurs et à introduire un nouveau "feature" nommé "matrix" en précisant explicitement la position du sous-facteurs dans la matrice par des features "row" et "column". *

2) On a du mal à saisir la subtilité du facteur "Rule Configuration". Est-ce que vous pouvez donner une brève déscription de ce facteur afin qu'on puisse regarder si avec le schéma actuel, on peut le définir convenablement ou quelles modifications à apporter si nécessaire?

3) On a intéret à soigner les choix du type des éléments et des attributs du schéma. Par exemple, préciser que l'attribut "author" est du type "string" au lieu de "anySimpleType", l'attribut 'date" est du type 'date' au lieu de 'anySimpleType', etc.

4) On a besoin plus de précision pour la spécification du workflow: quels sont les processus à inclure et comment les définir et comment traduire les paramètres spécifiés dans le schéma XML en appel des applications et comment enchaîner les processus?