résumé

Résumé, fiche descriptive

Catégories de logiciels utilisés dans la recherche en chimie

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 22/06/11
  • Correction mineure : 04/01/12
Mots-clés

Catégories de logiciels utilisés dans la recherche en chimie

  • Type de ressource : résumé
  • Auteur(s) ou responsable(s) : Jérôme Kieffer
  • Dessin de molécules en 2D

    • ChemSketch : logiciel Pro en licence académique
    • bkchem
    • chemtool
  • Visualisation de protéines

    • Coot : le visualiseur du CCP4
    • PyMol : visualiseur open-source très avancé (avec scripting)
    • Chimera : visualisation protéines, petites molécules...
  • Éditeur / visualiseur de molécules en 3D

    • Pymol : visualiseur open source pour les (bio-) molécules
    • Avogadro : un des éditeurs 3D open-source les plus aboutis
    • Gabedit : visualiseur de résultats de simulation DFT & ab-initio
    • Jmol : à embarquer dans une page web
    • Mercury : pour les structures cristalines
    • Chimera : visualisation protéines, petites molécules...
  • Modélisation moléculaire (optimisation 3D,calculs ab-initio, DFT, ...)

    • OpenBabel: boite à outils pour logiciels de chimie
    • Molecular Modelling Toolkit : bibliothèque de simulation moléculaire
    • HuLiS : méthode Hückel simple et mésomérie
    • TONTO : boite à outils de chimie computationnelle
    • pDynamo : modélisation moléculaire et simulation des protéines
    • NWChem
    • BigDFT : ondelettes et cartes graphiques
    • MOPAC2009 : licence académique
  • Visualisation / Simulation spectroscopique (RMN, RPE, fluorescence ...)

    • MassXpert: interprétation des données de spectrométrie de masse
    • Gabedit : visualisation des propriétés spectroscopiques calculés ab-initio
    • PyMca : analyse des spectres de fluorescence X
  • Visualisation scientifique (plot 2D / 3D):

    • Qtiplot : tableur et traceur de graphes 2D et 3D
    • VTK : The Visualization ToolKit, visualisation de gros volumes de données 2D ou 3D
    • Grace : graphique 2D pour système X Window
    • ParaView : visualisalisation interactive de gros volumes de données
    • gnuplot : traceur de courbes 2D / 3D
    • mayavi
  • Gestion de stock de produits chimique et gestion de laboratoire

  • Cristallographie:

    • Fox : résolution de structures cristallines sur poudre
    • MoPro : analyse de la structure et densité électronique moléculaire
    • SHELX : résolution et affinement de structures cristallographiques
    • pyFAI : intégration azimuthale pour détecteurs 2D
  • Moteur de workflow d'analyse de données:

    • Taverna : Conception de workflows et moteur d'exécution
    • BioMAJ : moteur de workflows pour la synchronisation des données (en biologie notamment)
    • EDNA : environnement pour réaliser des programmes d'analyses de données en ligne
    • DAWB
    • orange2
    • vistrails
  • Tableaux périodiques

    • Kalzium : pour l'environnement KDE sous linux
    • GPeriodic : pour l'environnement Gnome sous linux

Format SEED (Standard for the Exchange of Earthquake Data)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 06/06/11
  • Correction mineure : 06/06/11
  • Fiches logiciel PLUME connexes : RDMSEED
Mots-clés

Format SEED (Standard for the Exchange of Earthquake Data)

  • Type de ressource : résumé
  • Auteur(s) ou responsable(s) : F. Beauducel (IPGP)
  • Contact pour plus d'informations : beauducel_@_ipgp.fr

SEED (Standard for the Exchange of Earthquake Data) est une norme internationale de format numérique pour l'échange de données sismologiques, conçu et utilisé par la communauté des sismologues principalement pour faciliter les échanges de données brutes entre institutions. C'est un format de données adapté à toutes mesures ponctuelles dans l'espace avec période d'échantillonnage fixe. Le format SEED est constitué de plusieurs en-têtes de métadonnées décrivant la chaîne d'acquisition (Dataless) et les volumes de données (Data Records). Il est aussi possible de stocker uniquement les données dans un volume “Data-only” appelé Mini-SEED ou mseed (voir http://www.iris.edu pour plus d'information).

Matériel OpenSource (OpenHardware) et la recherche

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 12/08/11
  • Correction mineure : 12/08/11
Mots-clés

Matériel OpenSource (OpenHardware) et la recherche

  • Type de ressource : résumé
  • Auteur(s) ou responsable(s) : Jean-François Witz, LaGrotteDubarbu (Olivier Chambon)
  • Contact pour plus d'informations :

    Jean-François Witz :
    IR II CNRS, LML,
    jean-francois.witz@ec-lille.fr

    Jean-Michel Friedt :
    IR, FEMTO-ST,
    jean-michel.friedt@femto-st.fr

Cet article donne une définition du Matériel OpenSource (OSHW - OpenSource Hardware) et indique son intérêt pour la Recherche.

Open Source Hardware (OSHW)

Introduction et philosophie
Le Matériel OpenSource (OSHW - OpenSource Hardware) est un terme qui regroupe des produits tangibles — machines, dispositifs ou toutes choses physiques — dont les plans ont été rendus publics d’une telle façon que quiconque puisse les fabriquer, modifier, distribuer et les utiliser. Le but de cette définition est de donner des lignes directrices pour le développement et l’évaluation de licences pour du Matériel OpenSource.

Il est important de noter que le matériel est différent des logiciels, puisque les ressources physiques pour la création des biens physiques doivent être toujours disponibles. En   conséquence, les personnes et entreprises produisant des objets (ou “produits”) sous licence  OSHW se doivent de publier des plans et méthodes permettant de réaliser le produit en utilisant l'état de l'art de l'ingénierie, évitant ainsi de dépendre d'un process qui ne serait maîtrisé que par ceux qui ont conçu le produit.

Ces propos pouvant paraître complexes ils se doivent  d'être illustrés. Le cas de la conception mécanique peut être un bon exemple. Lors de la conception d'un système mécanique le choix  d'une technologie domine la conception, le choix d'une vis d'assemblage par exemple pourra se faire avec le support d'une norme telle que la AFNOR NF-E-25-112 pour les vis à tête  hexagonale. Cette norme permet de se fournir indépendamment d'une marque donnée, et garantie donc la pérennité de la conception. Cette simplicité dans la conception n'est cependant pas toujours possible. Il est aujourd'hui impossible de partir de zéro lors d'une conception, prenons par exemple la conception d'une machine utilisant un moteur. Même si les plans de la partie mécaniques sont disponibles et permettent à un usineur de les réaliser, la partie motorisation est un système qu'il faudra acheter. Ce système imposera, à technologie équivalente, des contraintes bien différentes, il faudra choisir la liaison permettant la communication entre l'ordinateur hôte et le variateur (électronique pilotant le moteur), la paramétrisation de ce variateur se fera au travers d'un logiciel, qui lui même utilisera un protocole au travers d'une liaison, qui elle sera normalisée. Le simple choix d'un moteur pour faire fonctionner un système mécanique peut donc déjà empêcher l'utilisation de logiciels libres dans la conception et l'utilisation du futur système mécanique. Il est donc tout à fait possible de concevoir un produit OSHW, n'autorisant pas l'utilisation de logiciels libres.

Il est donc fondamental d'expliquer en quoi cette approche est inefficace. Les méthodes de conception et de production matérielles traditionnelles conduisent nécessairement à l'obsolescence par péremption, du fait que si un des composants est obsolète et que le produit n'est plus dans la phase de support, alors il est nécessaire de mettre à jour une bien plus grande partie des composants que ce qui est strictement nécessaire. Ces problèmes concernent directement les composants électroniques dont la durée de vie ne peut être prédite, mais aussi le matériel informatique, et plus encore les logiciels, qui lorsqu'ils sont propriétaires sont dépendants d'un système où même d'une version d'un système. Il suffit donc qu'une seule de ces dépendances ne soit pas satisfaite pour que le système complet devienne inopérant. Cette constatation se doit d'avoir une interprétation pragmatique en terme de budgets consacrés aux matériels. Les laboratoires ainsi que les établissements d'enseignement supérieur voient leurs budgets grevés par l'achat de matériels jugés obsolètes mais pourtant opérationnels de part l'unique volonté d'un fournisseur de vendre une nouvelle gamme, par non support de la précédente. A classe de produits équivalents, un produit OSHW pourra aisément subir une mise à jour qu'elle soit relative aux composants, ou relative aux logiciels OpenSource nécessaires au bon fonctionnement. D'un point de vue éthique et philosophique, cela revient à ne pas accepter la notion d'obsolescence programmée.

Les termes de distribution sous la licence de Matériel OpenSource doivent suivre les critères suivants :

1. Documentation

Le matériel doit être distribué avec la documentation incluant les fichiers de conception, en permettant la modification et distribution de ces fichiers de conception. Quand la documentation n’est pas fournie avec le produit physique, il doit exister un moyen suffisamment explicite d’obtenir cette documentation, pour un coût de reproduction raisonnable, de préférence en le téléchargeant via Internet sans contrepartie financière. La documentation doit comporter les fichiers de conception sous la forme préférable par laquelle un développeur de matériel pourrait modifier la conception. Des fichiers délibérément obscurs ou altérés ne sont pas autorisés. Les formes intermédiaires de code, comme un typhon près à imprimer depuis un programme CAD, ne sont pas autorisés (puisque les fichiers originaux et modifiables sont préférés).

2. Logiciels nécessaires

Si le matériel nécessite un logiciel, qu'il soit embarqué ou non, pour opérer proprement et pleinement les fonctions essentielles de ce matériel, alors la documentation nécessaire doit aussi être incluse pour l’une des choses suivantes : le logiciel nécessaire, publié sous licence OpenSource, ou une autre documentation suffisante pour que cela soit raisonnablement considéré comme simple d’écrire un logiciel OpenSource qui permette au matériel d’opérer proprement et pleinement les fonctions essentielles.

3. Travail dérivé

La licence doit permettre les modifications et travaux dérivés, et doit permettre leur distribution sous les mêmes termes que la licence matérielle originelle. La licence doit permettre aux manufacturiers, vendeurs, distributeurs l’utilisation du produit créé depuis le fichier de design ou des dérivés du fichier de design.

4. Redistribution libre

La licence ne doit restreindre aucune partie de vendre ou de donner la documentation du projet comme composant d’une agrégation de designs de différentes sources.
La licence ne doit pas requérir de royalties ou d'autres paiements quelle qu'en soit la forme, pour son utilisation ou celle des produits dérivés.

5. Attribution
La licence peut demander aux créateurs d'œuvres dérivées d'indiquer l’attribution du travail d’origine en distribuant les fichiers de design, produits manufacturés, et/ou autre produit dérivé. La licence peut imposer que les œuvres dérivées portent un nom différent, ainsi qu’un numéro de version différent de l’original.

6. Pas de discrimination envers les personnes ou groupes
La licence ne doit comporter aucune discrimination envers aucune personne ou groupe de personnes.

7. Pas de discrimination envers un type d'utilisateur ou domaine d'utilisation
La licence ne doit pas restreindre quiconque d’utiliser le matériel dans un domaine ou une utilisation spécifique. Par exemple, la licence ne doit pas restreindre l’utilisation du matériel dans une entreprise ou pour la recherche nucléaire.

8. Distribution de la licence
Les droits attachés au matériel doivent s’appliquer aux produits ou documentations qui sont redistribués sans besoin d’une licence additionnelle pour ces parties.

9. La licence ne doit pas être spécifique à un produit
Les droits attachés au matériel ne doivent pas dépendre d’une partie matérielle particulière d’un produit plus large. Si le matériel est extrait de ce produit et utilisé ou distribué sous les termes de la licence matérielle, toutes les parties desquelles le matériel est redistribué doivent avoir les mêmes droits que ceux qui sont accordés en liaison avec la distribution originale.

10. La licence ne doit pas restreindre d’autres matériels ou logiciels

La licence ne doit pas placer de restriction sur d’autres matériels ou logiciels qui pourraient être distribués ou utilisés avec la licence matérielle. Par exemple, la licence ne doit pas insister sur le fait que les autres matériaux vendus en même temps doivent être OpenSource, ou que seul du logiciel OpenSource peut être utilisé en conjonction avec le matériel. Ceci s'applique bien évidement à l'échelle du système conçu et non aux composant du système soumis à la propriété intellectuelle des ayants droits.

11. La licence doit être technologiquement neutre
Aucune disposition de la licence ne peut être fondée sur une technologie ou un style d’interface.

Intérêt pour la recherche et l'enseignement

Pertinence de la démarche :

Dans tous les domaines scientifiques, le développement de solutions permettant de réaliser des développements scientifiques est un enjeu majeur. Il nécessite d'une part des moyens extrêmement importants et d'autre part des développements matériels et logiciels considérables. S'il est vrai que dans la plupart des domaines scientifiques des solutions industrielles sont proposées pour répondre aux problématiques du chercheur dans le cadre d'une politique de R&D, il apparaît que le faible volume de vente que représente le monde de la recherche et de l'enseignement n'incite pas les industriels à développer des solutions suffisamment modulaires pour que le chercheur puisse développer ses idées. De ce fait de nombreux chercheurs et ingénieurs se voient contraints de développer des solutions. Bien que chaque domaine de recherche regroupe des spécificités qui font qu'une solution employée dans un domaine ne sera pas aisément transposable dans un autre domaine, il existe cependant de nombreux points pouvant être mutualisés permettant ainsi de diminuer de manière significative les coûts de développements associés à une nouvelle thématique. La définition qui précède concernant l'OSHW est donc là pour permettre cette mutualisation.

Nécessité des liens industriels :

S'il est possible de développer et de diffuser des schémas permettant de reproduire du matériel couvert par une licence OSHW, il est plus délicat de produire ou même de modifier de telles ressources pour les adapter à une nouvelle problématique. Un laboratoire peut difficilement maîtriser toutes les étapes de la production d'un matériel nécessaire à ses expérimentations, il n'est d'ailleurs pas intéressant pour lui de maîtriser tout ce process. Il existe de plus en plus d'entreprises motivées par la création de matériels OSHW, il devient alors évident qu'il est aussi important de proposer des entreprises sachant construire un matériel OSHW (où des entreprises vendant le matériel) que de mettre à disposition des plans et méthodes de construction. La section OSHW de PLUME, si elle se met en place, ne devra donc pas ignorer cette composante de partenariat et référencement industriel.

Format VOTable : standard d'échange de données (astronomie)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 02/12/10
  • Correction mineure : 18/09/12
Mots-clés

Format VOTable : standard d'échange de données (astronomie)

Acronyme :

VOTable

Nom complet :

Le VO de l'acronyme signifie Virtual Observatory

Description courte :

Le format VOTable est un standard basé sur XML pour l'échange de données tabulaires.
Il a été créé par l'IVOA (International Virtual Observatory Alliance) pour répondre au besoin de partager de très gros volumes de données dans le cadre de l'Observatoire Virtuel (ensemble de catalogues de données en astronomie, souvent distants et hétérogènes, mais devant être interrogeables ou consultables à partir d'un seul point d'entrée unique en utilisant des méthodes et formats standardisés).
Un fichier VOTable est un ensemble de tables et contient des métadonnées (qui décrivent les informations relatives au fichier et la définition de chacun des champs) et des données qui peuvent être stockés sous 3 formats différents : TABLEDATA (XML), BINARY ou FITS.

Extension par convention :

.vot ou .xml

Version actuelle ou version décrite dans la fiche :

1.2

Documents de standardisation :

La première recommandation (version 0.1) a été publiée le 18 novembre 2001.

La version la plus récente (version 1.2), publiée le 30 novembre 2009, est décrite dans :
http://www.ivoa.net/Documents/VOTable/20091130/REC-VOTable-1.2.pdf

Avantages :

  • Basé sur un standard (XML)
  • Interopérabilité

Utilisations recommandées :

Ce format est très utilisé par la communauté scientifique en astronomie dans le cadre des systèmes d'Observatoires Virtuels.

Logiciels de traitement :

La liste des outils permettant de créer ou manipuler des fichiers VOTable est disponible ici :
VOTable Software

On y trouve notamment :

- des librairies écrites dans différents langages (Java, C++, Perl, PHP et Python) ;

- des applications qui acceptent ce format en entrée ou en sortie (Aladin, TOPCAT,...).

Formats connexes :

XML 1.0

Structure du fichier VOTable :

Un fichier VOTable est une ressource (RESOURCE) composée d'une ou plusieurs tables (TABLE). Chaque table contient une description de la table (PARAM, DESCRIPTION), la définition de chacun des champs de la table (FIELD) et les données (DATA).
Les données peuvent être stockées de trois façons :
- TABLEDATA : les données sont au format XML (avec balises TR et TD), donc la table est lisible mais très verbeuse ;
- BINARY : les données sont sous format binaire ;
- FITS : les données sont contenues dans un fichier FITS.

Cette dernière possibilité vient du fait que le format VOTable a, dès le départ, été conçu pour rester compatible avec le format FITS, très utilisé en astronomie (accès au contenu des tables FITS sans réécriture des données).

A noter aussi qu'un fichier VOTable peut être composé de plusieurs ressources, chacune pouvant contenir des tables de données de structure différente.

Exemple (extrait du fichier VOTable en TABLEDATA d'une étoile observée par le télescope spatial CoRoT) :

<?xml version='1.0'?>
<VOTABLE version="1.1"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.1 http://www.ivoa.net/xml/VOTable/v1.1"
 xmlns="http://www.ivoa.net/xml/VOTable/v1.1">
<!--
 !  VOTable written by STIL version 2.8 (uk.ac.starlink.votable.VOTableWriter)
 !  at 2010-11-05T12:36:23
 !-->
    <RESOURCE>
        <TABLE name="EN2_STAR_CHR_0102708694_20071023T223035_20080303T093502.fits" nrows="348670">
         <PARAM arraysize="*" datatype="char" name="EXTNAME" value="BINTABLE">
            <DESCRIPTION>name of the extension</DESCRIPTION>
         </PARAM>
         <FIELD arraysize="23" datatype="char" name="DATE" unit="yyyy-mm-jjThh:mi:ss"/>
         <FIELD datatype="double" name="DATEJD" unit="COROT JULIAN DAY"/>
         <FIELD datatype="double" name="DATEHEL" unit="COROT JULIAN DAY"/>
         <FIELD datatype="int" name="STATUS"/>
         <FIELD datatype="float" name="REDFLUX" unit="ELECTRONS"/>
         <FIELD datatype="float" name="REDFLUXDEV" unit="ELECTRONS"/>
         <FIELD datatype="float" name="GREENFLUX" unit="ELECTRONS"/>
         <FIELD datatype="float" name="GREENFLUXDEV" unit="ELECTRONS"/>
         <FIELD datatype="float" name="BLUEFLUX" unit="ELECTRONS"/>
         <FIELD datatype="float" name="BLUEFLUXDEV" unit="ELECTRONS"/>
         <FIELD datatype="float" name="WHITEFLUX" unit="ELECTRONS PER PIXEL"/>
         <FIELD datatype="float" name="JCFW" unit="ELECTRONS"/>
<FIELD datatype="float" name="BG" unit="ELECTRONS"/>
         <FIELD datatype="float" name="CORREC_RED" unit="ELECTRONS"/>
         <FIELD datatype="float" name="CORREC_GREEN"/>
         <FIELD datatype="float" name="CORREC_BLUE"/>
         <DATA>
             <TABLEDATA>
                <TR>
<TD>2007-10-23T22:30:35.000</TD>
<TD>2852.4376628083655</TD>
<TD>2852.4392856502645</TD>
<TD>1</TD>
<TD>931972.75</TD>
<TD>21487.277</TD>
<TD>148447.31</TD>
<TD>7812.389</TD>
<TD>218506.67</TD>
<TD>13792.4795</TD>
<TD>1298926.8</TD>
<TD>0.0</TD>
<TD>448.1599</TD>
<TD>0.0</TD>
<TD>0.0</TD>
<TD>0.0</TD>
</TR>
                  ...(348670 lignes de données <TR>)...
                </TABLEDATA>
            </DATA>
        </TABLE>
    </RESOURCE>
</VOTABLE>

A noter que depuis la version 1.1, chaque champ de la table (TABLEDATA) peut être défini avec sa propre balise (pour remplacer la simple balise TD). Cela permet de lever une limitation initiale du format VOTable et d'exploiter les outils de requêtes propres à XML comme xPath ou xQuery.
Pour cela, il faut utiliser la balise <XMLDATA> et rajouter un ID dans la définition des champs. Pour reprendre l'exemple ci-dessus avec uniquement les 3 premiers champs, cela donnerait :

         <FIELD arraysize="23" datatype="char" name="DATE" ID="DATE" unit="yyyy-mm-jjThh:mi:ss"/>
<FIELD datatype="double" name="DATEJD" ID="DATEJD" unit="COROT JULIAN DAY"/>
<FIELD datatype="double" name="DATEHEL" ID="DATEHEL" unit="COROT JULIAN DAY"/>
...
<DATA>
  <TABLEDATA><XMLDATA>
    <TR>
<DATE>2007-10-23T22:30:35.000</DATE>
<DATEJD>2852.4376628083655</DATEJD>
<DATEHEL>2852.4392856502645</DATEHEL>
...

Commentaires :

Grâce au standard XML utilisé, un fichier VOTable peut facilement être mis en forme à l'aide d'une feuille de style XSLT et manipulé par des outils standards. Aussi, et même s'il est moins performant que le format BINARY, le stockage des données sous le format TABLEDATA reste le plus utilisé car lisible par n'importe quel éditeur ou tableur classique.
Dans ce contexte d'utilisation, ce format peut permettre, par exemple, d'effectuer des fouilles systématiques sur un catalogue complet de données astronomiques (ce que l'on appelle aussi le data mining).

URL pour plus d'informations :

Working Group IVOA VOTable

Accessibilité Web : choix des contrastes, couleurs et typographie

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 25/11/10
  • Correction mineure : 30/11/10
Mots-clés

Accessibilité Web : choix des contrastes, couleurs et typographie

Le choix de la conformité d'un site Web

Pour que toute personne puisse consulter un site web confortablement, le consortium W3C/WAI a rédigé plusieurs directives dont l'une est destinée à spécifier l'accessibilité des contenus Web pour tous ;  la WCAG 2.0. S'adressant en particulier aux concepteurs web, cette directive prend en compte les difficultés de perception visuelle des internautes, en caractérisant les contrastes colorimétriques associés à une taille minimum de caractères. Cependant, comment un concepteur web peut-il respecter ces critères de conformité et quelle méthode adopter pour répondre aux différentes déficiences visuelles des internautes ?

Les outils de conception

Choix du contraste

Pour aider les concepteurs graphiques à élaborer une charte graphique web conforme aux directives, le web fournit de nombreux outils très visuels. Pour mesurer les rapports de contrastes théoriques entre une couleur de police et un arrière plan, le concepteur peut recourir au site Colour Contrast Check. Ce site propose 3 palettes ; la 1ère fixe une couleur de texte, la 2ème fixe la couleur d'arrière plan, une 3ème palette de contrôle permet de vérifier le niveau de luminosité, de contraste et le niveau d'accessibilité WCAG.
En complément, le site Color contrast verification tool permet de mesurer le niveau de contraste pour une taille de caractères donnée.
RQ : Si un contraste élevé facilite la perception, un contraste trop élevé fatigue aussi l'œil, ces outils facilitent  le dosage en fonction des critères objectifs et subjectifs.

Ex : Pour prétendre au niveau AAA d'accessibilité, la directive WCAG impose un rapport de contraste de 7:1 pour des caractères inférieurs à 18 points.

Choix colorimétrique, pour un site bien vu

Pour concevoir sa charte graphique, le concepteur web peut s'appuyer sur le site colorschemedesigner.
A partir d'une roue de couleurs, il choisit une ou plusieurs teintes majoritaires pour son site. Puis ajuste la luminosité, la saturation et le contraste pour obtenir sa palette de couleurs en valeurs hexadécimales. Des outils de simulation permettent de visualiser instantanément le résultat d'une page web sur fond blanc ou noir. D'autres outils simulent des déficiences visuelles incitant le concepteur à revoir éventuellement ses choix pour une meilleure perception des nuances. Après validation des choix, le concepteur peut mémoriser la palette couleurs en différents formats.

Choix typographique

Pour effectuer des choix typographiques sur une page web, le concepteur peut s'appuyer sur le site typetester. Ce site propose 3 colonnes comparatives pour effectuer des choix de polices, de tailles de caractères, de couleurs et de mise en page. Le résultat s'affiche en-dessous où se déclinent toutes les formes d'affichage de la police choisie.
Rq : Avant de valider ses préférences typographiques, le concepteur web doit aussi prévoir dans les feuilles de styles (CSS) des polices alternatives installées systématiquement dans les navigateurs.

Fiches Plume connexes

  • Web Accessibility Initiative (WAI),
    - Groupe d'experts travaillant à l'élaboration des directives concernant l'accessibilité web, en savoir + En savoir plus
  • Référentiel Général d'Accessibilité pour les Administrations (RGAA),
    - La législation française a élaboré un référentiel d'accessibilité pour les administrations, en savoir + En savoir plus

Autre ressources

  • Guide accessibilité web :
    - Ce guide propose une méthode pour prendre en compte tous les critères d'accessibilité en vue d'obtenir une certification, en savoir + En savoir plus
  • Yellowpipe Internet Services :
    - Site facilitant la conversion des couleurs hexadécimales en RVB et vice versa, en savoir + En savoir plus
  • Améliorer l'accessibilité web par la typographie :
    - Site destiné aux concepteurs web pour les aider à faire des choix typographiques, en savoir + En savoir plus
  • Visionner le choix typographie avec différents navigateurs, en savoir + En savoir plus

RDF (Resource Description Framework) : cadre de description de ressource (Web)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 25/11/10
  • Correction mineure : 30/11/10
Mots-clés

RDF (Resource Description Framework) : cadre de description de ressource (Web)

Description

L'accroissement des informations transitant sur le Web complexifie les modalités de recherches des moteurs. Face à ce phénomène, les membres du W3C/RDF ont élaboré une syntaxe Resource Description Framework (RDF/XML) facilitant la description, l'agencement et le partage des données constituant une page Web. La syntaxe RDF normalise les descriptions pour permettre aux machines de trier et d'échanger plus efficacement les métadonnées propres à chaque ressource numérique (article, tableau, graphique, livre numérique, photo, animation, fichier sonore, vidéo, logiciel...).

Pour une introduction à RDF, consulter RDF Primer ou sa traduction en français : Initiation à RDF.

RDF dans les attributs d'une page XHTML

RDFa permet d'inscrire au sein d'une page XHTML 1.1 des métadonnées en affectant des attributs aux balises HTML. Ces attributs caractérisent les informations vues par l'internaute pour les rendre interprétables par les machines.

Liens utiles

Format fastq : format pour représenter les séquences et leurs scores de qualité

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 03/11/10
  • Correction mineure : 09/10/13
Mots-clés

Format fastq : format pour représenter les séquences et leurs scores de qualité

Version : pas de version

Extension : .fq, .fastq, _sequence.txt (Illumina)

Type de document : Fichier texte

Document de standardisation :

Un article (dans N.A.R.) décrivant le format
Page descriptive sur le site de Wikipedia
Description sur le site MAQ

Description courte :
Format qui permet de représenter un ou plusieurs séquences avec leurs scores de qualités par base. Une séquence est représentée par 4 lignes:
La première ligne commence par le symbol '@' suivi d'un identifiant de séquence.
La seconde ligne correspond à la séquence
La troisième ligne commence par '+' suivi d'éventuelles autres infos
La quatrième ligne correspond à la séquence qualité de la 2e ligne.
Exemple :

@HWI-QMN273:4:1:2:779#0/1
ANCAAAATCTGCATTACCTCCTCGGCTGGGACAACTTTATTC
+HWI-QMN273:4:1:2:779#0/1
\D[aaaab_aaaabba__a^Za^aaZa`]a__a_Z_aaaa`\ 

Avantages :

  • Est un format simple pour partager des séquences et le score de qualité
  • Beaucoup de logiciels reconnaissent et exploitent ce format
  • Ce format peut contenir plus ou moins d'informations (en les ajoutant sur la ligne commencant par '@').

Inconvénients :

  • Il n'y a pas un standard rigoureux et Illumina en a fait des variants
  • Le score de qualité n'est pas encodé de la même façon selon l'éditeur du fichier
  • Le fichier est volumineux

Logiciels de traitement les plus connus :

Format connexe :

Format SAM : Sequence Alignment/Map (biologie)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 17/01/12
  • Correction mineure : 19/04/13
Mots-clés

Format SAM : Sequence Alignment/Map (biologie)

  • http://samtools.sourceforge.net/
  • Type de ressource : résumé
  • Date de publication du document ou de l'événement : Juin 2009
  • Auteur(s) ou responsable(s) : Li H, Handsaker B, Wysoker A, Fennell T, Ruan J, Homer N, Marth G, Abecasis G, Durbin R; 1000 Genome Project Data Processing Subgroup
  • Contact pour plus d'informations : Pour se tenir au courant des développement et contacter la communauté : les mailing lists.
    Et un forum (anglophone) très dynamique : communauté seqanswers.com

Acronyme :

SAM

Nom complet :

Sequence Alignment/Map

Description courte :

Format, utilisé en biologie, d'alignement générique pour stocker les alignements de séquence sur des séquences de référence

Extension par convention :

sam (bam pour la version binarisée, c'est-à-dire compressée)

Version actuelle ou version décrite dans la fiche :

1.4 décrite dans les spécifications Version v1.4-r985, du 7 septembre 2011

Types de documents concernés :

Fichiers de séquences alignées (produits d'assemblage, d'aligneur de séquences)

Documents de standardisation :

SAM a été créé à l'initiative de, et utilisé par, le projet 1000 Génomes.
Description complète du format. Specifications sur le site officiel.

Avantages :

Le format SAM (Sequence Alignment/Map) est un format d'alignement générique pour stocker les alignements de lectures (reads, sequences) sur des séquences de référence. Ce format supporte les lectures courtes et longues (jusqu'à 128 Megabases) produites par plusieurs plate-formes de séquençage.

SAM tend à être capable de :

  • Être assez flexible pour stocker toutes les informations d'alignements produits par divers programmes d'alignement
  • Être assez simple pour être facilement généré par des programmes d'alignement ou converti depuis un autre format d'alignement
  • Être compact en taille
  • Permettre la plupart des opérations sur un alignement tout en travaillant dans un flux sans avoir à charger tout l'alignement en mémoire
  • Permettre le fichier d'être indexé par position génomique afin de récupérer efficacement toutes les lectures alignées sur un locus

Inconvénients :

La qualité est sensée être encodée en base ASCII+33, ce qui peut éventuellement poser des problèmes quand on a affaire à des anciennes données Illumina/Solexa (ASCII+64), voir la page wikipedia rédigée par la communauté sur l'encodage de la qualité (similaire à celle du format Fastq).

Utilisations recommandées :

SAM est un format d'échange de données d'alignements, en vogue dans les traitements de données de nouvelles technologies de séquençage.

Logiciels de traitement :

Formats connexes :

tsv (Fichier texte tabulé).

Formats concurrents :

ACE (propriété de Roche), BED, Stockholm...

Bonnes pratiques

  1. Section en-tête

    1. La ligne @HD doit être présente, avec l'étiquette "SO" spécifiée.
    2. Les lignes @SQ doivent être présentes s'il y a des lectures qui sont alignées.
    3. Quand une étiquette "RG" apparaît dans la section alignement, alors il doit y avoir la ligne @RG correspondante (même valeur de "ID") dans l'en-tête.
    4. Quand une étiquette "PG" apparaît dans la section alignement, alors il doit y avoir la ligne @PG correspondante (même valeur de "ID") dans l'en-tête.
  2. Les opérations CIGAR adjacentes doivent être différentes (sinon les regrouper)
  3. Aucun alignement ne devrait recevoir la "mapping quality" à 255 (maximum 254, pour signifier qu'on ne peut la donner).
  4. Lectures non alignées
    1. Pour une lecture non alignée, en "paired-end" ou en "mate-pair" dont le partenaire est aligné, ce read non aligné devrait avoir un "RNAME" et une "POS" identique à son partenaire aligné.
    2. Si tous les segments d'un patron ("template") sont non-alignés, leur "RNAME"devrait être mis à "*" et leur "POS" à "0".
    3. Si "POS", ajouté de la somme des longueurs des opérations CIGAR M/=/X/D/N, dépasse la longueur spécifiée dans "LN" de la ligne @SQ (de l'en-tête, si elle existe) avec un "SN" égale au "RNAME", la lecture devrait être non alignée.
  5. Alignement multiple
    1. Quand un segment est présent dans plusieurs enregistrements, un seul de ces enregistrements devrait avoir (pour l'alignement secondaire) la valeur de "flag" (0x100) désactivée. "RNEXT" et "PNEXT" pointent vers l'alignement primaire du segment suivant.
    2. "SEQ" et "QUAL" de l'alignement secondaire devraient être mis à "*" pour réduire la taille.
  6. Etiquettes optionnelles :
    1. Si un patron a plus de 2 segments, l'étiquette "TC" devrait être présente.
    2. L'étiquette "NM" devrait être présente.

Commentaires :

Les spécifications ne sont plus en draft !
Planification de la 2.0 : mediawiki

URL pour plus d'informations :

http://samtools.sourceforge.net/

Fichier attachéTaille
SAM1.pdf159.26 Ko
sam1_v14.pdf356.29 Ko

Communiqué de presse PLUME - Novembre 2010

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 28/10/10
  • Correction mineure : 28/10/10
Mots-clés

Communiqué de presse PLUME - Novembre 2010

Des centaines de logiciels libres validés par la communauté de l'Enseignement Supérieur et de la Recherche publiés sur la plate-forme "PLUME"

Depuis trois ans chercheurs, enseignants, ingénieurs et techniciens des universités et des laboratoires de recherche disposent d'une plate-forme accessible par le web qui leur permet de trouver la description de logiciels libres, validés par des utilisateurs experts. Initié au sein du CNRS et ouvert à l'ensemble des acteurs de la recherche et de l'enseignement supérieur, PLUME dresse son bilan après 800 publications.

Lancé en 2007, le projet PLUME est animé par un double objectif; mutualiser les compétences sur les logiciels en référençant des logiciels libres, orientés métiers, utilisés dans les laboratoires de recherche et les universités et faire connaître, promouvoir, valoriser les développements réalisés dans cette communauté. Hébergé par la plate-forme PLUME, le référencement des logiciels et de ressources centrées sur le développement des logiciels repose sur le principe des contributions multiples bénévoles.

A ce jour, 650 contributeurs ont collaboré pour publier près de 600 fiches descriptives de logiciels, mises à jour régulièrement, auxquelles s'ajoutent 200 fiches ressources, toutes organisées selon douze thématiques (maths, biologie, réseaux...). Désireux de partager leur expérience dans l'utilisation ou le développement des logiciels métier, les contributeurs sont toujours plus nombreux, +67% en un an. Parallèlement, l'intérêt des internautes pour la plate-forme PLUME est en constante augmentation depuis son lancement. Dans les neuf premiers mois de l'année 2010, 1 800 000 pages ont été consultées par 28 000 internautes par mois en moyenne.

Grâce aux collaborations dans lesquelles ils sont engagés, les membres de l'équipe PLUME ont tissé un réseau de partenaires, universités, laboratoires, organismes de recherche qui apportent leur compétence métier. Les plus impliqués dans le développement de logiciels libres ont intégré le comité stratégique. Sensibilisés par les économies réalisées dans la recherche ou le développement de logiciels fiables, ces partenaires sollicitent fréquemment l'équipe PLUME pour présenter PLUME lors de conférences ou de journées de formation.

En parallèle, les responsables thématiques de l'équipe PLUME organisent deux à trois journées thématiques de formation par an réunissant plus d'une centaine de chercheurs, enseignants ou ingénieurs. Ces journées retransmises sur le web sont une source d'information et d'échanges pour tous.

A l'horizon 2011-2012, PLUME a pour ambition de couvrir l'ensemble des métiers et domaines scientifiques pour devenir progressivement la plate-forme de référence des logiciels de qualité, principalement libres, utilisés ou développés dans les laboratoires de recherche et les universités. Dans cette optique, l'équipe PLUME souhaite étendre ses partenariats avec les acteurs publics ou privés de la communauté scientifique et universitaire et stimuler les contributions. L'étendue des compétences réunies et le caractère novateur des logiciels décrits permettront de conforter l'audience de PLUME et de diffuser plus largement les connaissances de la recherche scientifique au niveau national voir international.

Informations :

Les services web de type REST

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 22/10/10
  • Correction mineure : 01/12/11
Mots-clés

Les services web de type REST

  • Type de ressource : résumé
  • Date de publication du document ou de l'événement : Oct 2010
  • Auteur(s) ou responsable(s) : P. Gambarotto (INPT/Enseeiht)

REST (REpresentational State Transfer) est un style d’architecture pour concevoir un service web, utilisant au maximum les possibilités de HTTP. Ses principales caractéristiques sont les suivantes :

  • application client/serveur : le transport sur le réseau est assuré par HTTP (essence même d’un web service)
  • interface uniforme : tout élément offert à la manipulation par l’application est nommé ressource et est identifié de manière unique par les Identifiants de Ressource Uniforme (URI ci-après) suivant le schéma :

    http_URL = “http:” “//” host [”:” port]

    Deux types de schéma d’URI sont distingués :

    • URI member qui désigne une seule ressource.
    • URI collection qui désigne une liste de ressources de même type.
  • la sémantique des messages du client au serveur est celle de HTTP :

    • GET URI : récupérer la représentation d’une ressource (URI member), ou d’une liste de ressources (URI collection)
    • POST URI (collection) : rajouter une ressource à une liste de ressources existantes, donc création de ressource.
    • PUT URI (member) : modifier une ressource existante ou créer une nouvelle ressource.
    • DELETE URI : destruction d’une (URI member) ou plusieurs (URI collection) ressources.
  • les réponses du serveur aux clients utilisent également les messages HTTP, en particulier les codes d’erreur suivants :

    • 200 Ok
    • 404 Ressource non trouvée sur le serveur
  • représentation des ressources : le format avec lequel une ressource est représentée est obtenu par négociation grâce aux entêtes HTTP. Le client indique ce qu’il souhaite comme format de représentation avec l’entête ”Accept”, le client et le serveur utilisent l’entête ”Content-type” pour décrire le format de représentation de la ressource incluse dans le message. Les formats les plus fréquemment rencontrés sont XML et JSON.

API REST : exemple détaillé

Pour illustrer les principes de création d'une API s'appuyant sur les principes REST, je vais décrire une gestion d'utilisateurs très générale, telle qu'on la retrouve souvent dès qu'une application a besoin de gérer une authentification de ses utilisateurs. Les utilisateurs sont identifiés en tant que ressources par un schéma d'URI du type :

http://server/user/id

où id est une clef permettant d'identifier de manière unique la ressource, par exemple le login pour un utilisateur. L'ensemble des utilisateurs est référencé par le schéma d'URI

http://server/users

(notez bien le pluriel). Les différentes actions possibles sur ces deux types de ressource sont :

GET http: // server / users
Récupère la liste de tous les utilisateurs (Réponse : 200 OK)
POST http: // server / user / id_user
Création d'un nouvel utilisateur (Réponse : 201 Created)
GET http: // server / user / id_user
Récupère la représentation de l'utilisateur identifié par id_user (Réponse : 200 OK ou 404 resource not found)
PUT http: // server / user / id_user
Modifie un utilisateur (Réponse : 200 OK ou 404 resource not found)
DELETE http: // server / user / id_user
Efface un utilisateur (Réponse : 200 OK ou 404 resource not found)

Les deux premiers schémas de requêtes adressent la collection entière des utilisateurs, tandis que les suivants visent un membre particulier de la collection. Ce sont deux types de ressources différents, c'est donc normal que le schéma d'URI soit spécifique à chacun.

Dans une API REST on retrouve presque systématiquement cette dualité collection/membre. Notez que http: // server / user (au singulier) aurait pu être l'URI identifiant la collection. C'est à la partie serveur de réaliser l'analyse des requêtes pour déterminer quelles sont les ressources visées par une requête particulière.

Représentation des ressources

JSON est utilisé pour représenter les deux types de ressources, utilisateur et liste d'utilisateurs.

  • Utilisateur :
{user:{login: id_user, password: secret }}
  • Liste :
[{user:{login: id1, password: secret1}}, {user:{login:id2, password:secret2}}]

Un utilisateur est donc ici représenté par un login et un password.

Bibliographie

  1. Fielding, Roy Thomas, Architectural Styles and the Design of Network-based Software Architectures, 2000
  2. Fielding and al, Hypertext Transfer Protocol -- HTTP/1.1, 1999
  3. J. Gregorio, B. de hOra, The Atom Publishing Protocol, 2007
  4. D. Crockford, The application/json Media Type for JavaScript Object Notation (JSON), 2006
  5. Leonard Richardson, Sam Ruby, RESTful Web Services, 2007
Syndiquer le contenu