Koncepcja bloga c-rex.net opartego na iiRDS i DITA

DITA jako baza danych

W naszym dziale redakcyjnym polegamy na DITA jako podstawowym standardzie XML. Dla wpisów na blogu stworzyliśmy osobny tematyczny Blogpost. Ten typ tematu implementuje rozszerzenie dla informacji zwiastuna i wykorzystuje nasze standardowe rozszerzenia dla metadanych.

Poprzez DITA subjectScheme, do którego odwołujemy się w DITA-Map, definiujemy kontrolowaną listę wartości dla możliwych metadanych.

Pozwala to na wybór możliwych wartości w formie formularza. Jest to przyjazne dla użytkownika i działa bardzo dobrze w naszym programie do tworzenia oXygen. Ma to również pozytywny wpływ na spójność gromadzonych informacji.

Dokument lub temat

Dokument czy temat? Zastanawialiśmy się, czy blog c-rex.net powinien być wpisem typu iirds:Topic iirds:Document, czy typu .

Obie wywodzą się z klasy bazowej iirds:InformationUnit. Mają te same właściwości z wyjątkiem iirds:has-document-type.

Zgodziliśmy się na iirds:Topic, ponieważ wpis na blogu dotyczy samodzielnego tematu.

Z drugiej strony, dokument może zawierać kilka tematów, dlatego zazwyczaj nie możemy przypisać tutaj wpisu na blogu. Ta definicja odpowiada również specyfikacji w 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.

Niemniej jednak zdecydowaliśmy, że treść pisemna powinna odzwierciedlać iirds:DocumentType. W tym celu zdefiniowaliśmy instancje dla wiadomości, artykułów i projektów klientów i ustanowiliśmy z nimi relację za pośrednictwem iirds:is-applicable-for-document-type w iirds:Topic.

W przyszłości możemy również dodać kategorię serii blogów. Ta seria blogów jest następnie przechwytywana na DITA-Map, która jest klasyfikowana przy użyciu iirds: iirds:Document i iirds:InformationSubject typu 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>

Identyfikacja metadanych

Już w środowisku DITA myśleliśmy o zestawie metadanych. W tym celu po raz pierwszy przyjrzeliśmy się standardowi iiRDS i skupiliśmy się na nim.

Po co ponownie zadawać sobie trud wymyślania czegoś własnego, skoro wielu ekspertów już o tym pomyślało?

Jednak w naszej definicji przyjrzeliśmy się tylko źródłom informacji i tylko marginalnie procesowi wyjściowemu, a zwłaszcza formatowi iiRDS.

Zdefiniowaliśmy następujące kategorie metadanych w DITA, które są dla nas odpowiednie:

• Strony

  W kategorii Strony uwzględniamy wszystkie strony, które są dostępne wraz z wpisem na blogu. Z jednej strony są to autorzy, klienci i tłumacze. Podczas gdy te ostatnie są obecnie systemami tłumaczenia maszynowego, takimi jak DeepL.

• Komponenty

  Wiele naszych wpisów na blogu dotyczy modułów c-rex.net. Dlatego musimy odnieść się do DTS i IDS lub obu.

• Formaty

  Ponadto piszemy kilka rzeczy na temat obsługi danych.

  Dane są przechowywane w formatach lub usługach danych. Dlatego ważne jest również, aby przechwytywać informacje, które ustanawiają związek z cechami naszego produktu.

  Przykładami z tego obszaru mogą być iiRDS, DITA lub Word.

• Przedmioty

  Tematy są używane do kategoryzowania poszczególnych wpisów na blogu i rozróżniania ich. Do tej pory byliśmy w stanie zidentyfikować projekty klientów, artykuły, How-Tos i wiadomości jako kategorie.

• Procesy Td

  W końcu nasze wpisy na blogu dotyczą głównie procesów w dokumentacji technicznej. Począwszy od procesu tworzenia, poprzez proces tłumaczenia, zarządzanie treścią, aż po różne opcje wyjściowe.

Dalsze metadane wynikają ze struktury dokumentu i procesów.

• Data utworzenia i modyfikacji

• Data publikacji

• Tłumacz

  Z reguły tłumaczymy automatycznie. W związku z tym tłumacz automatycznie korzysta z wybranego narzędzia tłumaczeniowego. Na razie jest to DeepL.

• Status dokumentu

  Kiedy publikujemy coś w systemie produkcyjnym, zawartość jest z definicji udostępniana. W związku z tym nie utrzymujemy ręcznego statusu Topics.

• Typ Topics

  Ponieważ specjalizujemy nasze DITA Topics do odpowiednich celów aplikacji, możemy uzyskać te informacje automatycznie ze struktury Topic.

Po pierwsze, wymieniamy wyłącznie metadane dla konkretnej treści i klasyfikujemy je z redakcyjnego punktu widzenia.

W następnym kroku wymieniamy metadane związane z zasobami zewnętrznymi (takimi jak autorzy, klienci, tłumacze i produkty). Następnie ułatwiamy sobie zadanie i sprawdzamy, jakie myśli zostały podane w iiRDS i mapujemy je na naszą kategoryzację.

DITA Subject Scheme jako podstawa Knowledge Graph

Możemy uznać DITA Subject Scheme za konfigurację naszego środowiska edycyjnego. Coś podobnego istnieje w najróżniejszych systemach redakcyjnych; tak zwane listy wartości i kaskady, które służą do modułów słów kluczowych.

Jak widać na powyższych zrzutach ekranu, wartości te są bardzo specyficzne. Jeśli chcemy publikować do iiRDS, musimy przechowywać te wartości jako konfigurację bazową. Możemy to zrobić, ręcznie definiując relacje w formie Knowledge Graph lub korzystając z odpowiednich narzędzi do tego celu. Lub wykorzystujemy istniejące systemy do ich automatycznego generowania.

W naszym prostszym przypadku użycia, DITA Subject Scheme. Używamy go do generowania przynajmniej informacji o tułowiu odpowiednich osób. Przyjrzyjmy się, jak to działa na przykładzie autorzy, procesów dokumentacji technicznej, a także przypisywania właściwości naszego produktu.

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

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

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

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

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

Łączenie jednostek informacyjnych

Teraz, gdy zdefiniowaliśmy podstawowe relacje i punkty końcowe niezbędne dla naszego przypadku użycia, staje się to znacznie łatwiejsze, przynajmniej z perspektywy systemu.

Teraz wygenerujemy metadane dla wpisu na blogu i ustanowimy relacje z innymi obiektami.

Oczywiście wymaga to dyscypliny redakcyjnej. Podczas tworzenia treści należy już zebrać odpowiednie informacje na dany temat, których nie można (jeszcze) uzyskać automatycznie.

W przypadku wpisu na blogu Nigdy więcej problemów z danymi w niewłaściwym formacie generujemy metadane dla naszego DITA Topic i ustalamy relacje z podstawową konfiguracją zdefiniowaną wcześniej.

Dzięki temu możemy zaimplementować dowolne zapytania w naszym systemie opartym na c-rex.net IDS, aby szybko i za pomocą kilku kliknięć poprowadzić naszych użytkownicy do istotnych dla nich informacji.

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

Wnioski

W tym wpisie na blogu pokazaliśmy podejście na drodze digitalizacja w do możliwych do zarządzania ramach.

Pierwszym krokiem jest zidentyfikowanie odpowiednich metadanych i relacji dla konkretnego Usecase. W bardzo ograniczonym stopniu przyglądamy się reszcie świata i temu, co jeszcze może być istotne.

Niemniej jednak ważne jest, aby zawsze pamiętać o szerszej perspektywie. I właśnie w tym pomaga nam standard iiRDS, który jest zdefiniowany daleko poza konkretnym przypadkiem użycia.

Możemy więc zacząć, tak jak zrobiliśmy to już w HOMAG dla zupełnie innej aplikacji. Również w tym przypadku zaczęliśmy od małych rozwiązań, wiedząc, że wdrożony system można rozbudować i rozszerzyć w dowolnym momencie o kolejne przypadki użycia, takie jak Predictive Maintenance.

Jeśli jesteś obecnie zaangażowany w tematy związane z dostarczaniem treści, Przemysłem 4.0 i IoT, a także łączeniem modułowej dokumentacji technicznej, zacznij: Think big and start small.