Hierarchical Data Format

La recherche d'un format de données scientifiques portable, initialement appelé AEHOO (All Encompassing Hierarchical Object Oriented format), a commencé en 1987 par le Graphics Foundations Task Force (GFTF) au National Center for Supercomputing Applications (NCSA). Les subventions NSF reçues en 1990 et 1992 étaient importantes pour le projet. À cette époque, la NASA a étudié 15 formats de fichiers différents à utiliser dans le cadre du projet EOS (Earth Observing System). Après un processus d'examen de deux ans, HDF a été sélectionné comme système standard de données et d'information.

HDF4 est l'ancienne version du format, bien qu'il soit toujours activement pris en charge par The HDF Group. Il prend en charge une prolifération de modèles de données différents, notamment des tableaux multidimensionnels, d'images matricielles et des tableaux. Chacun définit un type de données agrégées spécifique et fournit une API pour lire, écrire et organiser les données et les métadonnées. De nouveaux modèles de données peuvent être ajoutés par les développeurs ou les utilisateurs HDF.

HDF est auto-descriptif, permettant à une application d'interpréter la structure et le contenu d'un fichier sans aucune information extérieure. Un fichier HDF peut contenir un mélange d'objets associés accessibles en groupe ou en tant qu'objets individuels. Les utilisateurs peuvent créer leurs propres structures de regroupement appelées «vgroups».

Le format HDF4 a de nombreuses limitations. Il manque un modèle d'objet clair, ce qui rend difficile le soutien et l'amélioration continus. La prise en charge de nombreux styles d'interface différents (images, tableaux multidimensionnels, tableaux) conduit à une API complexe. La prise en charge des métadonnées dépend de l'interface utilisée. Les objets SD (Scientific Dataset) prennent en charge des attributs nommés arbitraires, tandis que d'autres types ne prennent en charge que les métadonnées prédéfinies. Peut-être plus important encore, l'utilisation d'entiers signés 32 bits pour l'adressage limite les fichiers HDF4 à un maximum de 2 Go, ce qui est inacceptable dans de nombreuses applications scientifiques modernes.

Le HDF5 améliore le HDF4. Il simplifie la structure des fichiers pour proposer seulement deux types d'objets :

• les ensembles de données (datasets), qui sont des tableaux multidimensionnels contenant des données d'un même type (prédéfini ou dérivé) ;
• les groupes (groups), qui contiennent, ou regroupent, des ensembles de données et d'autres groupes.

L'utilisateur peut aussi définir une structure d'attribut pour ajouter des informations (des meta-données) sur chaque objet.

Cette structuration en ensembles de données et groupes donne aux fichiers HDF5 une structure hiérarchique (en l'occurrence arborescente), un peu comme un système de fichiers. Cette analogie avec un système de fichiers est aussi présente dans les conventions de nommage des objets du fichiers : le nom complet d'un objet du fichier HDF5 est construit comme un chemin dans un système de fichiers (/chemin/vers/le/fichier).

La critique de HDF5 découle de sa conception monolithique et de ses longues spécifications.

• HDF5 n'impose pas l'utilisation de UTF-8, donc les applications clientes peuvent attendre ASCII dans la plupart des endroits.
• Les données de l'ensemble de données ne peuvent pas être libérées dans un fichier sans générer une copie de fichier à l'aide d'un outil externe (h5repack).

Il existe des interfaces de programmation pour manipuler des fichiers HDF via un langage de programmation ou un logiciel[2].