Lorsqu'un concepteur de base de données se lance dans la création d'un schéma de données, il va réfléchir sur les informations et leur place logique avant de faire une mise en contexte technique. De même, en ingénierie documentaire, il est important de se représenter la structure globale du modèle avant de passer à la conception dans SCENARIbuilder.
La conception de modèles de documents est transverse à plusieurs métiers et contextes d’usages. Elle demande à la fois une bonne connaissance de la modélisation documentaire mais avant tout une connaissance du contexte d’utilisation de ce futur modèle. Plusieurs méthodes d’approches peuvent être envisagées, nous vous proposons ici un exemple d’une approche qui n’est à considérer ni comme exhaustive ni comme représentative des méthodes de conceptions.
Domaine exemple utilisé pour ce tutoriel : les planètes.
Nous voulons décrire l’univers et ses planètes.
Documentez vous sur le thème de votre modèle. Vous devez devenir un expert des planètes et de tout ce qui se trouve dans l'univers pour pouvoir être à l'aise avec les choix de modélisation de ces données. Soyez attentif aux informations de ces documents à modéliser : y a-t-il souvent des parties de textes qui ont le même type de contenu pour toutes les planètes ? Devant une masse très volumineuse d'informations, lesquelles doivent être présentes sur vos documents et lesquelles ne vous intéressent pas ?
Partir de documents existants est une source d'inspiration très précieuse, ci-dessous des liens vers des documents pour votre modèle "helloUniverse":
À partir de votre étude, identifiez les "objets" à utiliser, la structure générale de vos données. Soyez raisonnable et n'hésitez pas à simplifier quand vous le pouvez.
Posez vous des questions :
Dans notre cas, nous avons différents types de corps célestes mais avons-nous besoin de les distinguer par 2 types d'objets différents ?
Lors de la rédaction, l'auteur a-t'il besoin d'avoir des types de parties très différentes dans le cas d'une étoile ou dans le cas d'une planète ?
Doit-on créer un type d'item spécifique pour les "planètes naines" ?
Nous allons choisir la solution la plus simple : le même type d'item est utilisé par l'auteur pour les étoiles, les planètes et les planètes naines : la structure sera la même mais à l'intérieur du contenu, rien ne nous empêche de prévoir un moyen pour l'auteur de spécifier le type de l'astre. Il n'y a pas de bonne réponse ou de mauvaise, c'est vraiment en fonction des besoins.
Autre question à se poser : doit-on créer des objets comme les galaxies ou les systèmes ?
Raisonnablement, nos auteurs n'ont pas trop de connaissances à capitaliser pour des planètes en dehors du système solaire, donc nous allons nous limiter à celui-ci dans un premier temps et nous n'avons pas besoin de représenter ces éléments. Si nous avions à placer d'autres étoiles, il serait intéressant de séparer les astres du système solaire des autres, donc d'adopter une structure en galaxie / systèmes.
Souhaitons nous regrouper les informations des planètes ?
Nous décrivons plusieurs planètes et il leur faut impérativement un conteneur, nous allons les placer dans une racine univers.
Quelques exemples de structures possibles, nous choisissons la première qui offrira largement assez de complexité à cet exemple.
Lors de la conception technique, vous pourrez être amené à découper ces objets en plusieurs .model SCENARIbuilder mais vous avez déjà préparé cela par l'étape abstraite du travail.
Il est important de se poser des questions sur le contexte du projet, son but, les futurs auteurs et les futurs lecteurs.
Formaliser ces points vous permettra d’y voir plus clair dans le projet et de vous aider dans vos choix de modélisation ou de publications.
Définir le contenu des objets
L'univers contient des planètes, nous ne lui associerons pas d'autres données.
Chaque astre est associé à une série d'informations précises :
Ajouter du contenu textuel riche : sous forme de paragraphe pour décrire les planètes. Question à se poser sur les paragraphes : peut-on les pré-définir (forcer un titre ? un ordre ?) ou est-ce à l'auteur de les écrire librement.
Liberté total de l'auteur sur les paragraphes : on laisse choisir à l'auteur le rôle de chaque paragraphe et leur nombre sans lui proposer des parties spécifiques.
Sans ordre précis, parties libres et éventuellement parties prédéfinies : l'auteur crée des parties comme bon lui semble, mais il peut utiliser certaines parties avec un rôle prédéfini.
Parties prédéfinies en ordre fixe + parties libres : on spécifie d'avance les rôles de 4 paragraphes et l'auteur peut en ajouter librement à la fin.
Restriction total des parties : nous créons et choisissons d'avance les rôles de 4 paragraphes (avec un titre par défaut ou même un titre fixe).
Identifier des structures récurrentes :
Essayant d'identifier les besoins de nos auteurs, nous allons identifier 4 parties qui reviennent couramment : introduction, atmosphère, surface, noyau.
Mais chaque planète a des particularités que l'auteur peut souhaiter décrire dans des paragraphes qu'il crée lui même et dont on ne peut pas forcément anticiper le rôle. Nous retenons donc la solution « Parties prédéfinies en ordre fixe + parties libres ».
Nous allons au fil de ce tutoriel construire un réseau de fichiers .model respectant ce schéma (en plus des autres items ici masqués par soucis de simplification). Nous avons vu que l'on pouvait décomposer notre domaine en objets, mais aussi identifier des types de parties répétés à l'intérieur d'un modèle ou les re-décomposer, ce qui explique ce niveau supplémentaire en dessous de astreobj.model.
