Conception of the c-rex.net blog based on iiRDS and DITA

The concept behind the c-rex.net blog is based on the DITA and iiRDS standards.

The image shows the word Metadata on a background of connected lines

Two central pillars on which the c-rex.net blog rests are the DITA and iiRDS standards. We present our content strategy in this blog post.

DITA as a database

In our editorial department, we rely on DITA as the underlying XML standard. For the blog posts we have specialized a separate Topictyp Blogpost. This topic type implements an extension for teaser information and uses our standard extensions for metadata.

The graphic shows the definition of a DITA Subject Schemes in the DITA-Map view of oXygen. — Definition of controlled values in a Subject Scheme

Using a DITA subjectScheme that we reference in the DITA-Map, we define a controlled list of values for possible metadata.

This allows the possible values to be selected in a kind of form. This is user-friendly and works very well in our creation program oXygen. It also has the nice effect of making the captured information consistent.

The graphic shows the selection of metadata via a controlled list of values based on a subjectScheme. — Metadata and controlled values based on a Subject Schemes

Document or Topic

Document or Topic? We wondered whether the c-rex.net blog should be a blog post of type iirds:Document or of type iirds:Topic.

Both derive from the base class iirds:InformationUnit. They have the same properties except for iirds:has-document-type.

We agreed on iirds:Topic because a blog post deals with a self-contained topic.

A document, on the other hand, can contain multiple topics, which is why we tend not to assign a blog post here. And this definition then also corresponds to the specification in 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.

Nevertheless, we decided that the written content should reflect an iirds:DocumentType. We have defined the instances for news, articles and customer projects for this purpose and relate them via iirds:is-applicable-for-document-type at iirds:Topic.

We may also add a blog series category in the future. This blog series is then captured in a DITA-Map, which is classified using an iirds:Document and the iirds:InformationSubject 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>

Identify metadata

Already in the DITA environment we thought about the set of metadata. For this purpose, we have taken a first look at the iiRDS standard and oriented ourselves to it.

Why go through the trouble again and come up with something of your own when many experts have already thought about it?

However, in our definition we only cared about the information sources and only marginally considered the output process and specifically the iiRDS format.

We have defined the following metadata categories in DITA that are suitable for us:

Parties
In the category Parties we include all the parties that are available with the blog post. These are, on the one hand, female authors, customers and translators. Whereas the latter are now machine translation systems like DeepL.
Components
A lot of our blog posts revolve around the c-rex.net modules. Therefore, we need to relate to DTS and IDS or both.
Formats
Furthermore, we write a few things about the handling of data.
Data is stored in formats or data services. Therefore, it is also important to capture information that relates to our product features.
Examples from this area would be iiRDS, DITA or Word.
Subjects
We use Subjects to categorize the individual blog posts and thus make them distinguishable. So far, we have been able to identify customer projects, articles, How-Tos and news as categories.
Td Processes
Finally, our blog posts are mostly related to technical documentation processes. Starting with the creation process, through the translation process, content management and various output options.

Further metadata results from the structure of the document and from the processes.

Creation and modification date
Publication date
Translator
As a rule, we translate automatically. The translator therefore results automatically from the selected translation tool. For now, that's DeepL.
Document status
When we publish something to the production system, the content is released by definition. So we do not maintain a manual status of Topics
Topics type
Since we specialize our DITA Topics for the appropriate application purposes, we can derive this information automatically from the structure of the Topic.

So, we start by listing only the metadata for a particular piece of content and classify it from an editorial point of view.

In the next step, we list the metadata related to external resources (such as authors, customers, translators and products). And then we make it very simple and check what thoughts have been thought of in iiRDS and map those to our categorization.

The DITA Subject Scheme as the basis for the Knowledge Graph

We can consider the DITA Subject Scheme as the configuration of our editing environment. There is something similar in the most diverse editorial systems; so-called value lists and cascades, which serve the keywording of modules.

As you can see in the screenshots above, these values are very specific. If we want to publish to iiRDS, we have to store these values as base configuration. We can do this by manually defining the relationships in the form of a Knowledge Graph or by using appropriate tools for this purpose. Or we use existing systems to generate them automatically.

In our simpler use case, the DITA Subject Scheme. We use it to generate at least the trunk information of the corresponding subjects. Let's take a look at how this works using the example of authors, the technical documentation processes, and the assignment of our product properties.

Authors definition

In the DITA Subject Scheme we define the value list for authors and a 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>

Using an XSLT we can generate the iirds:Party metadata from it.

<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>

Based on the structure of the DITA Subject Scheme we know that Markus Wiedenmaier is an author and can directly assign the role iirds:has-party-role in addition to the label of the party.

In addition, we can also generate the body of the VCard and assign a photo based on rules.

As soon as the interface to our CRM system is implemented, we can also automatically fill the VCard from this data. Particularly exciting when we look at the blog posts about our client projects.

Definition of the processes

When it comes to process descriptions, iiRDS offers the specialized iirds:InformationSubjectiirds:Process. An instance of this class GenericProcess is defined in the standard.

However, we are much more specific here and now define our own instances based on the defined value lists.

<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>

Definition of product properties

We also set our own values for 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>

Is this already a Knowledge Graph now?

We proceed analogously with the other metadata to generate the base configuration of our iiRDS environment.

We now have a Knowledge Graph that looks at some relationships primarily from a documentation perspective and looks somewhat outward. For our currently still manageable use case blog, we map the necessary information accordingly in a graph.

For a Knowledge Graph that also resolves our product structures and relationships outside of technical documentation, however, there is still a lot missing.

Especially in more complex environments, where use cases in the Industrie 4.0 and IoT environment are addressed, this information is essential.

But these extensions, which will also become relevant in our company in the future, and some of which already are, follow the same principle.

Here's what's important to us:

We use information from our existing systems.
We derive the Knowledge Graph from this automatically if somehow possible.
In doing so, we can reproducibly update the basis of the system at any time.

A lot of information is available in central systems of a company (ERP, PIM, CRM, PLM, ...).

If information is missing, it should also be stored and maintained there in the source, because it is also relevant outside of the provision of information in a horizontal organizational structure.

External modeling can therefore only be a temporary stopgap, which should gradually be dropped and generated from the inventory.

In our case, for example, we need to establish a relationship between our products and product features and functions.

This information is not available to us in the technical documentation, or only to a very limited extent. This is because they are maintained in external systems and possibly also by other departments.

For example, if we can tap information from a PIM system, we can automatically correlate the relationship of our product c-rex.net DTS with its features and functions:

<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>

Metadata and relationships are thus extracted from the PIM system and linked to our hull structure. Via the predicate rdfs:seeAlso, iiRDS has so-called Extension Points to attach external ontologies to the classes iirds:ProductVariant, iirds:Component and iirds:ProductProperty.

If all this is defined accordingly and, if possible, generated automatically from inventory data, you have a Knowledge Graph that maps the product and plant structures and creates an image of reality for concrete use cases. So that would give us the essential part of a digital twin.

Linking the information units

Now that we have defined the base relationships and endpoints necessary for our use case, things get much easier, at least from a system perspective.

We now generate the metadata for a blog post and establish relationships with other objects.

Of course, this requires editorial discipline. During content creation, relevant information on a topic must already be collected, which cannot (yet) be derived automatically.

For the blog post Never again problems with data in the wrong format we generate the metadata for our DITA Topic and establish relationships to the base configuration defined in advance.

This allows us to implement any query in our system based on c-rex.net IDS to guide our users quickly and with just a few clicks to the information relevant to them.

<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

With this blog post, we've laid out the approach to digitalization in a manageable framework.

The first step is to identify the relevant metadata and relationships for a specific Usecase. We only take a very limited look at the rest of the world and what else might be relevant.

Nevertheless, it is important to always keep the big picture in mind. And we are helped in this by the iiRDS standard, which is defined far beyond a specific use case.

So we can get started, just as we have already done at HOMAG for a completely different application. Here, too, we started small, knowing full well that the implemented system is expandable and can be extended at any time to include further use cases such as Predictive Maintenance.

If you are currently involved in the topics of content delivery, Industry 4.0 and IoT, and the linking of modularized technical documentation, get started: Think big and start small.