Conception du blog c-rex.net sur la base d'iiRDS et de DITA
DITA comme base de données
Dans notre rédaction, nous utilisons DITA comme norme XML sous-jacente. Pour les articles de blog, nous avons spécialisé un type de topic Blogpost
. Ce type de topic met en œuvre une extension pour les informations de teaser et utilise nos extensions standard pour les métadonnées.
Grâce à un DITA subjectScheme que nous référençons dans la DITA-Map, nous définissons une liste de valeurs contrôlées pour les métadonnées possibles.
Il est ainsi possible de sélectionner les valeurs possibles dans une sorte de formulaire. C'est convivial et cela fonctionne très bien dans notre programme de création oXygen. De plus, cela a le bel effet d'assurer la cohérence des informations saisies.
Document ou topic
Document ou topic ? Nous nous sommes demandé si le blog de c-rex.net devait être un blog post de type iirds:Document ou de type iirds:Topic.
Les deux dérivent de la classe de base iirds:InformationUnit. Ils ont les mêmes propriétés, à l'exception de iirds:has-document-type.
Nous nous sommes mis d'accord sur iirds:Topic, parce qu'un article de blog traite d'un sujet qui se suffit à lui-même.
En revanche, un document peut contenir plusieurs thèmes, raison pour laquelle nous avons tendance à ne pas classer un article de blog ici. Et cette définition correspond alors également à la spécification dans l iiRDS:
iirds:Document is a collection
of information for an audience and a specific purpose.iirds:Topic is a self-contained
piece of information which deals with a single subject. The reader understands a
topic without any additional information.Néanmoins, nous avons décidé que le contenu écrit refléterait un iirds:DocumentType. Nous avons défini à cet effet les instances pour les nouvelles, les articles et les projets clients et établissons une relation via iirds:is-applicable-for-document-type sur iirds:Topic.
Il est possible que nous ajoutions à l'avenir une catégorie "série de blogs". Cette série de blogs est ensuite saisie dans une DITA-Map, qui est classée au moyen d'un iirds:Document et d'un iirds:InformationSubject de type iirds:Collection.
<iirds:Document rdf:about="https://www.c-rex.net/ns/iirds/td/cms#MyBlogSeries">
<iirds:has-subject rdf:resource="https://www.c-rex.net/ns/iirds/td/collections#BlogPostCollection"/>
</iirds:Document>
<iirds:Collection rdf:about="https://www.c-rex.net/ns/iirds/td/collections#BlogPostCollection">
<rdfs:label xml:lang="de">Blogserie</rdfs:label>
<rdfs:label xml:lang="en">Blog series</rdfs:label>
<iirds:description xml:lang="en"></iirds:description>
<rdfs:comment xml:lang="en">Indicates that the content represents a collection of information assembled from different blog posts.</rdfs:comment>
</iirds:Collection>Identifier les métadonnées
Déjà dans l'environnement DITA, nous avons réfléchi à l'ensemble des métadonnées. Pour ce faire, nous avons jeté un premier coup d'œil à la norme iiRDS et nous nous en sommes inspirés.
Pourquoi se donner encore une fois la peine d'inventer quelque chose de son cru alors que de nombreux experts ont déjà réfléchi à la question ?
Toutefois, dans notre définition, nous ne nous sommes occupés que des sources d'information et n'avons considéré que marginalement le processus de sortie et plus particulièrement le format iiRDS.
Fêtes
Dans la catégorie Fêtes, nous incluons toutes les personnes impliquées qui sont disponibles avec le blog post. Il s'agit d'une part écrivainsécrivainesécrivains et écrivainesécrivain·e·s, des clientsclientesclients et clientesclient·e·s et traducteurstraductricestraducteurs et traductricestraducteur·rice·s. Ces derniers étant devenus des systèmes de traduction automatique tels que DeepL.
Composants
Dans nos articles de blog, beaucoup de choses tournent autour des modules c-rex.net. C'est pourquoi nous devons établir une relation avec DTS et IDS, ou avec les deux.
Formats
En outre, nous écrivons quelques lignes sur le traitement des données.
Les données sont stockées dans des formats ou des services de données. C'est pourquoi il s'agit ici aussi de collecter des informations qui établissent un lien avec les caractéristiques de nos produits.
Des exemples dans ce domaine seraient par exemple iiRDS, DITA ou Word.
Sujets
Nous utilisons les Subjects pour catégoriser les différents articles de blog et les rendre ainsi distincts. Jusqu'à présent, nous avons pu identifier comme catégories les projets clients, les articles, les How-Tos et les news.
Processus Td
Après tout, nos articles de blog sont généralement liés aux processus de la documentation technique. En commençant par le processus de création, en passant par le processus de traduction, la gestion des contenus et les différentes possibilités de sortie.
Nous avons défini dans DITA les catégories de métadonnées suivantes qui nous conviennent :
Date de création et de modification
Date de publication
Traducteur
En règle générale, nous traduisons de manière automatisée. Le traducteur résulte donc automatiquement de l'outil de traduction sélectionné. Pour l'instant, c'est DeepL
Statut du document
Lorsque nous publions quelque chose dans le système de production, le contenu est par définition validé. Nous ne gérons donc pas le statut manuel des Topics.
Type de Topics
Comme nous spécialisons nos DITA Topics pour les applications correspondantes, nous pouvons déduire cette information de manière automatisée à partir de la structure du Topic.
D'autres métadonnées découlent de la structure du document et des processus.
Nous commençons donc par répertorier exclusivement les métadonnées d'un contenu donné et nous les classons du point de vue de la rédaction.
L'étape suivante consiste à lister les métadonnées liées aux ressources externes (comme écrivainsécrivainesécrivains et écrivainesécrivain·e·s, clientsclientesclients et clientesclient·e·s, les traducteurstraductricestraducteurs et traductricestraducteur·rice·s et les produits). Et ensuite, nous faisons très simple et vérifions les réflexions qui ont été faites dans l'iiRDS et nous les mappons sur notre catégorisation.
Le DITA Subject Scheme comme base pour le Knowledge Graph
Nous pouvons considérer le DITA Subject Scheme comme la configuration de notre environnement éditorial. On trouve des choses similaires dans les systèmes de rédaction les plus divers ; ce qu'on appelle la liste de valeurs et les cascades, qui servent à l'indexation des modules.
Comme on peut le voir dans les captures d'écran ci-dessus, ces valeurs sont très spécifiques. Si nous voulons publier selon iiRDS, nous devons enregistrer ces valeurs comme configuration de base. Nous pouvons le faire en définissant manuellement les relations sous la forme d'un Knowledge Graph ou en utilisant des outils appropriés à cet effet. Ou nous utilisons des systèmes existants pour les générer automatiquement.
Dans notre cas d'application plus simple, il s'agit de DITA Subject Scheme. Nous l'utilisons pour générer au moins les informations tronquées des sujets correspondants. Voyons comment cela fonctionne avec l'exemple des écrivainsécrivainesécrivains et écrivainesécrivain·e·s, les processus de documentation technique ainsi que l'attribution des caractéristiques de nos produits.
Définition des auteurs
Dans le DITA Subject Scheme, nous définissons la liste de valeurs pour les auteurs et un label.
<subjectdef keys="authors">
<topicmeta>
<navtitle>c-rex.net Authors</navtitle>
</topicmeta>
<subjectdef keys="parties.c-rex-maw">
<topicmeta>
<navtitle>Markus Wiedenmaier</navtitle>
</topicmeta>
</subjectdef>
</subjectdef>Grâce à un XSLT, nous pouvons générer les métadonnées iirds:Party à partir de ces données.
<iirds:Party rdf:about="https://www.c-rex.net/ns/iirds/td/parties#parties-c-rex-maw">
<rdfs:label>Markus Wiedenmaier</rdfs:label>
<iirds:has-party-role rdf:resource="http://iirds.tekom.de/iirds#Author"/>
<iirds:relates-to-vcard rdf:resource="https://www.c-rex.net/ns/iirds/td/vcards#parties-c-rex-maw"/>
</iirds:Party>
<vcard:Individual rdf:about="https://www.c-rex.net/ns/iirds/td/vcards#parties-c-rex-maw">
<vcard:fn>Markus Wiedenmaier</vcard:fn>
<vcard:hasPhoto rdf:resource="content/globalimages/parties-c-rex-maw.png"/>
</vcard:Individual>Grâce à la structure du DITA Subject Scheme, nous savons que Markus Wiedenmaier est un auteur et pouvons attribuer directement le rôle iirds:has-party-role en plus du label de la fête.
En outre, nous pouvons également générer le corps de la VCard et lui attribuer une photo sur la base de règles.
Dès que l'interface avec notre système CRM sera implémentée, nous pourrons également remplir automatiquement la VCard à partir de ces données. C'est particulièrement passionnant quand on regarde les articles de blog sur les projets de nos clients.
Définition des processus
Lorsqu'il s'agit de décrire des processus, iiRDS propose la version spécialisée iirds:InformationSubjectiirds:Process. Une instance de cette classe GenericProcess est définie dans le standard.
Mais nous sommes ici nettement plus spécialisés et définissons désormais nos propres instances sur la base des listes de valeurs définies.
<iirds:Process rdf:about="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-publication">
<rdfs:label xml:lang="en">Publication</rdfs:label>
</iirds:Process>
<iirds:Process rdf:about="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-translation" >
<rdfs:label xml:lang="en">Translation</rdfs:label>
</iirds:Process>
<iirds:Process rdf:about="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-publication-industry40" >
<rdfs:label xml:lang="en">Industry 4.0</rdfs:label>
</iirds:Process>Définition des caractéristiques du produit
Nous définissons également nos propres valeurs pour iirds:ProductProperty.
<iirds:ProductProperty rdf:about="https://www.c-rex.net/ns/iirds/td/formats#formats-tekom-iirds">
<rdfs:label xml:lang="en">iiRDS</rdfs:label>
</iirds:ProductProperty>
<iirds:ProductProperty rdf:about="https://www.c-rex.net/ns/iirds/td/formats#formats-xliff">
<rdfs:label xml:lang="en">XLIFF</rdfs:label>
</iirds:ProductProperty>Est-ce que c'est déjà un Knowledge Graph?
Nous procédons de la même manière avec les autres métadonnées et générons ainsi la configuration de base de notre environnement iiRDS.
Nous avons maintenant un Knowledge Graph qui considère certaines relations principalement du point de vue de la documentation et qui regarde un peu vers l'extérieur. Pour notre cas d'application blog, qui est pour l'instant encore gérable, nous représentons les informations nécessaires en conséquence dans un graphique.
Mais pour un Knowledge Graph qui résout aussi nos structures de produits et nos relations en dehors de la documentation technique, il manque encore pas mal de choses.
Ces informations sont essentielles, en particulier dans les environnements plus complexes où les cas d'application sont adressés dans l'environnement industriel 4.0 et IoT.
Mais ces extensions, qui seront aussi pertinentes chez nous à l'avenir et qui le sont déjà en partie, suivent le même principe.
Nous utilisons les informations de nos systèmes existants.
Nous en déduisons automatiquement le Knowledge Graph lorsque cela est possible.
Nous pouvons ainsi actualiser la base du système à tout moment et de manière reproductible.
Ce qui suit est important pour nous :
De nombreuses informations sont disponibles dans les systèmes centraux d'une entreprise (ERP, PIM, CRM, PLM, ...).
Si des informations manquent, elles devraient également être déposées et gérées à cet endroit dans la source, car elles sont également pertinentes en dehors de la mise à disposition d'informations dans un organigramme horizontal.
La modélisation externe ne peut donc être qu'une solution provisoire qui devrait être progressivement abandonnée et générée à partir de l'existant.
Dans notre cas, nous devons par exemple établir une relation entre nos produits et leurs caractéristiques et fonctions.
Nous ne disposons pas de ces informations dans la documentation technique, ou seulement de manière très limitée. En effet, elles sont gérées dans des systèmes externes et, le cas échéant, par d'autres services.
Par exemple, si nous pouvons puiser des informations dans un système PIM, nous pouvons mettre automatiquement en relation la relation de notre produit c-rex.net DTS avec ses caractéristiques et ses fonctions :
<iirds:ProductVariant rdf:about="https://www.c-rex.net/ns/iirds/td/products#c-rex-net-services-c-rex-net-dts">
<rdfs:label xml:lang="en">c-rex.net DTS</rdfs:label>
<iirds:has-identity>
<iirds:Identity>
<iirds:identifier>CREXDTS-0001</iirds:identifier>
<iirds:has-identity-domain rdf:resource="https://www.c-rex.net/ns/iirds/pim/product
</iirds:Identity>
</iirds:has-identity>
<iirds:relates-to-party rdf:resource="https://www.c-rex.net/ns/iirds/td/parties#parties-c-rex-net-gmbh"/>
<rdfs:seeAlso rdf:resource="https://www.c-rex.net/ns/iirds/pim/products-external#c-rex-net-services-c-rex-net-dts"/>
</iirds:ProductVariant>
<iirds:ProductProperty rdf:about="https://www.c-rex.net/ns/iirds/td/formats#formats-tekom-iirds">
<rdfs:label xml:lang="en">iiRDS</rdfs:label>
<rdfs:seeAlso rdf:resource="https://www.c-rex.net/ns/iirds/pim/products-external#formats-tekom-iirds"/>
</iirds:ProductProperty>Des métadonnées et des relations sont ainsi extraites du système PIM et reliées à notre structure de base. Par le biais du prédicat rdfs:seeAlso, iiRDS dispose de ce que l'on appelle Extension
Points pour lier des ontologies externes aux classes iirds:ProductVariant, iirds:Component et iirds:ProductProperty.
Si tout cela est défini en conséquence et, si possible, généré de manière automatisée à partir de données existantes, on dispose d'un Knowledge Graph qui reproduit les structures des produits et des installations et qui crée une image de la réalité pour des cas d'application concrets. Nous avons donc là la partie essentielle d'un jumeau numérique.
Lien entre les unités d'information
Maintenant que nous avons défini les relations de base et les points de terminaison nécessaires pour notre cas d'application, les choses deviennent nettement plus simples, du moins du point de vue du système.
Nous générons maintenant les métadonnées pour un blog post et établissons des relations avec d'autres objets.
Cela suppose bien sûr une discipline rédactionnelle. Lors de la création du contenu, il faut déjà saisir les informations correspondantes à un topic, qui ne peuvent pas (encore) être déduites automatiquement.
Pour l'article de blog Plus jamais de problèmes avec des données au mauvais format, nous générons les métadonnées pour notre DITA Topic et établissons des relations avec la configuration de base définie au préalable.
Nous pouvons ainsi implémenter dans notre système basé sur c-rex.net IDS les requêtes de notre choix afin de guider nos utilisateursutilisateuresutilisateurs et utilisateuresutilisateur·e·s rapidement et en quelques clics vers les informations qui les intéressent.
<iirds:Topic rdf:about="https://www.c-rex.net/ns/iirds/td/cms/c-rex-dts_001_de-DE">
<iirds:has-topic-type rdf:resource="https://www.c-rex.net/iirds/td#Blogpost"/>
<iirds:is-part-of-package rdf:resource="urn:uuid:17f7aa78-bb05-4b8a-b9de-0323e8f32657"/>
<iirds:title xml:lang="de-DE">Nie wieder Probleme mit Daten im falschen Format</iirds:title>
<iirds:has-abstract xml:lang="de-DE">Nie wieder Probleme mit Formatvielfalt, .....</iirds:has-abstract>
<iirds:language>de-DE</iirds:language>
<iirds:revision>001</iirds:revision>
<iirds:dateOfCreation>2021-10-05</iirds:dateOfCreation>
<iirds:dateOfLastModification>2021-10-05</iirds:dateOfLastModification>
<iirds:is-version-of>
<iirds:InformationObject rdf:about="https://www.c-rex.net/ns/iirds/td/cms#c-rex-dts"/>
</iirds:is-version-of>
<iirds:has-content-lifecycle-status>
<iirds:ContentLifeCycleStatus>
<iirds:dateOfStatus>2021-10-23T19:08:08.569+02:00</iirds:dateOfStatus>
<iirds:has-content-lifecycle-status-value rdf:resource="https://www.c-rex.net/ns/iirds/td/status#Published"/>
</iirds:ContentLifeCycleStatus>
</iirds:has-content-lifecycle-status>
<iirds:is-applicable-for-document-type rdf:resource="https://www.c-rex.net/ns/iirds/td/subjects#subjects-article"/>
<iirds:relates-to-component rdf:resource="https://www.c-rex.net/ns/iirds/td/components#c-rex-net-services-c-rex-net-dts"/>
<iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-microsoft-word"/>
<iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-custom-xml"/>
<iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-ditaxml"/>
<iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-xliff"/>
<iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-tekom-iirds"/>
<iirds:has-subject rdf:resource="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-creation"/>
<iirds:has-subject rdf:resource="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-translation"/>
<iirds:has-subject rdf:resource="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-publication"/>
<iirds:relates-to-party rdf:resource="https://www.c-rex.net/ns/iirds/td/parties#parties-c-rex-net-gmbh"/>
<iirds:relates-to-party rdf:resource="https://www.c-rex.net/ns/iirds/td/parties#parties-c-rex-rc"/>
<iirds:has-rendition>
<iirds:Rendition>
<iirds:format>application/xhtml+xml</iirds:format>
<iirds:source>content/html5/de-DE/posts/c-rex_dts.xhtml</iirds:source>
</iirds:Rendition>
</iirds:has-rendition>
</iirds:Topic>Conclusion
Avec cet article de blog, nous avons montré, dans un cadre clair, la procédure à suivre sur le chemin de la digitalisation.
Dans un premier temps, il s'agit d'identifier les métadonnées et les relations pertinentes pour un Usecase concret. Nous ne considérons que de manière très limitée le reste du monde et tout ce qui pourrait être pertinent par ailleurs.
Il est néanmoins important de toujours avoir une vue d'ensemble. Et la norme iiRDS, définie bien au-delà d'un cas d'application concret, nous y aide.
Nous pouvons donc nous lancer, comme nous l'avons déjà fait chez HOMAG pour un tout autre cas d'application. Ici aussi, nous avons commencé modestement, tout en sachant que le système mis en place est évolutif et qu'il peut être étendu à tout moment à d'autres cas d'application comme la Predictive Maintenance.
Si vous vous intéressez actuellement aux thèmes de la livraison de contenu, de l'industrie 4.0 et de l'IoT ainsi qu'au lien entre la documentation technique modularisée, mettez-vous au travail : Think big and start small.