IBM®
本文へジャンプ
    Japan [変更]    ご利用条件
 
 
検索範囲検索:    
    ホーム    製品    サービス & ソリューション    サポート & ダウンロード    マイアカウント    
skip to main content

developerWorks Japan  >  XML  >

DITAとSKOSによる主題の分類

正式な主題の管理

developerWorks
ページオプション

JavaScript を要するドキュメントオプションは表示されません

サンプルコード

原文はこちら

原文はこちら


レベル: 中級

Erik Hennum (ehennum@us.ibm.com), Information Architect, IBM
Robert Anderson (robander@us.ibm.com), Developer, Information Development Workbench, IBM
Colin Bird (colinl_bird@uk.ibm.com), Information Architect, IBM

2005年 10月 18日

DITAの特殊化を使用して、ドキュメント・コンテンツの主題を管理しましょう。すなわち、各トピックが何に関するものかに基づいて、コンテンツを識別し処理します。この記事で概説されているアプローチでは、Semantic Webのテクノロジーを活用して、検索、統合、その他の処理を向上させることができます。ただし、ゼロから始めるのではなく、コンテンツのオーサリングと処理のための標準のトピック指向戦略を利用します。

DITAトピックの主題としての正式化

DITAなどのトピック指向アーキテクチャーでは、コンテンツは小さな独立した単位でオーサリングされ、それらが組み合わされ、ヘルプ・システム、書籍、コース、その他の成果物となります。各情報単位は、特定の目的のための単一の質問に答えます。すなわち、各トピックには特定の独立した主題があります。これらの情報単位がトピックと呼ばれるのは、このためです。たとえば、あるトピックではWebサイトのユーザー定義ファイルの形式を記述し、別のトピックではWebサイトのセキュリティー原則を説明し、また別のトピックではWebサイトのログインをセットアップする手順を説明するなどです。

各トピックが特定の意味を持つので、DITAトピックはセマンティック処理に最適です。しかし、現在のセマンティック・プロセッサーは、トピックのテキストを読み取って、それが何を意味するのかを認識することはできません。セマンティック・プロセッサーが理解可能な、トピックの主題の正式な宣言がされていないからです。それは、郵便仕分け係が内容物を適切な宛先に配達できるようにするために封筒に書かれた住所のようなものです。

Simple Knowledge Organization System(SKOS)は、コンテンツの主題を示すための基準を規定しています。SKOSによって、特定の主題領域の主題を定義して(必要な場合は、これらの主題をタクソノミーとして組織化して)、その主題を示す各コンテンツを分類することができます。たとえば、SKOSを使用してconfiguration(構成)とsecurity(セキュリティー)を主題として定義し、それらの主題に関連する3つのサンプル・トピックを分類すると、"configuration"または"security"という単語がテキスト内に実際に現れるかどうかに関係なく、ユーザーが主題をブラウズするとコンテンツを発見できるようになります。

SKOSは、セマンティックWebの基本言語であるResource Description Framework(RDF)で表現されますが、読み取り可能なコンテンツ向けに設計されたより高いレベルの言語を提供します。SKOSは、OWL/RDF、TopicMaps、オントロジー、図書館学の専門家など、幅広い視点から恩恵を享受しています。基準策定の分野では、SKOSはセマンティックWebの従来の索引付けと正式なオントロジーのギャップを埋めるという貢献を果たしています。

このように、SKOSで表現される主題によってDITAトピックを分類して実行時処理するというソリューションにおいて、DITAとSKOSはよくなじみます。

注:SKOSは、正式な主題に対して「概念」ラベルを使用します。しかし、DITAは、本質的に概念的なコンテンツ単位に対して「概念」ラベルを使用します。混乱を避けるために、この記事(および付属の特殊化)では、SKOSと同じ概念のものには「主題」ラベルを使用し、「概念」ラベルはDITAの意味で使用します。

タクソノミーの一般的なアプローチは、正式な主題定義をコンテンツから切り離しておくことです。しかし、DITAの特殊化を使用すると、主題定義をオーサリング対象のコンテンツとして保持することができます。コンテンツ作成者は、主題定義をコンテンツとして管理することによって、いくつかの利点を実感できます。

  1. 正式な主題は、多くの場合、用語集のトピックや発行済みの情報セット内にすでに存在するその他のトピックによって定義されます。TopicMapsコミュニティーは、以前から、このような権威ある定義リソースを「発行済み主題インジケーター」という名前で認識しています。たとえば、アプリケーション・サーバー製品のドキュメンテーションでは、認証、Webサーバーなどの主題分野の中の重要な主題が定義されます。 発行済みの情報に主題定義を含めなかった場合でも、主題定義のための標準のコンテンツ・ツールを使用することができます。たとえば、XMLエディターで主題定義を作成して、主題定義をコンテンツとともにコンテンツ管理システムやバージョン管理システムに保存して、バージョン管理できます。また、既存の書式化プロセスを使用して、作成者が使用する主題定義のカタログを作ることもできます。すなわち、主題定義のために個別のオーサリング・システムや処理システムを実装する必要がありません。
  2. 主題の分類は、ナビゲーション体系としてのコンテンツの情報アーキテクチャーの一部と言ってよいでしょう。したがって、情報アーキテクトは、後から意味上の精細さを付け加えようとするのではなく、対象となる主題の正式な定義を提供することによって、より良いコンテンツを促し、コンテンツの作成をガイドすることができます。 情報アーキテクトは、既存の情報アーキテクチャーが特に明快な場合、いくつかの主題の分類が、トピック間の既存の編成または関係を単に正式なものにするだけであることに気づくでしょう。
  3. RDFは、オーサリングではなく処理を目的として最適化されています。特に、RDFは、XMLを利用するのではなく、情報をレコードのセットとして表現して、ツリーおよびテーブル構造をわかりやすくします。RDFファンは、洗練されたツールがあれば、ソース・ファイルの形式を見る必要はなくなると示唆することがあります。しかし、HTMLは、そのようなツールが存在するようになった後も、わかりやすいファイル形式としての価値を実証してきました。 特に、主題のタクソノミーは本質的なツリー構造を持ち、特殊化されたDITAマップとしてわかりやすい表現となっています。RDFモデルにはさまざまな変形があり、主題の定義と分類に特化するDITAマップは、SKOSモデルのもう一つの特殊化とみなすこともできます。



上に戻る


主題分類の部品

SKOSによって規定され、DITA特殊化によって実装されている主題分類には、次のような部品があります。


表1. 主題分類の部品
部品識別対象DITA実装
主題定義正式な主題の意味主題のデフォルトのラベルを定義し、主題がカバーするものを説明するDITAトピック。
主題スキーム主題間の関係主題を階層に組織化するDITAマップ。たとえば、Task(タスク)主題はInstalling(インストール)主題とConfiguration(構成)主題の両方を含んでいるかもしれません。マップは、他の方法で関連している主題の関連関係を表現することもできます。
コンテンツ分類リソースの主題正式な主題を定義するトピックと、主題のいくつかの局面を扱うコンテンツ・トピックの間の関係を表現する、もう一つのDITAマップ。同じマップで、コンテンツ・トピックのナビゲーション関係と関連リンクをDITAの標準の方法で定義することができます。

さらに、DITAは、分類されるコンテンツ・トピックとそれらのトピックに関するその他の情報を提供します。たとえば、DITAマップはコンテンツ・トピックを組織化してナビゲーション階層を提供したり、それらのトピックの関連リンクを定義したりできます。

図1は、主題分類の部品を示しています。


図1. 主題分類の部品
図1.主題分類の部品

図1は、次のものを示しています。

  • 正式な主題(青緑色の円)
  • コンテンツ・トピック(青色の円)
  • 主題の関係(黄色の矢印)
  • 分類関係(青色の矢印)
  • ナビゲーション階層や関連リンクなどのトピック・ナビゲーション関係(赤紫色の矢印)

パブリッシングの視点から見て、主題分類は索引付けと用語集の両方に似ています。この概念は新しいものではありません。用語集と索引付けがセマンティックの表明になるという認識は、TopicMapsの開発に寄与しました。索引語が複数の意味を持つ場合、各主題は用語集の1つの意味と同じ精度を持ちます。意味に基づいたコンテンツの管理を可能にするのは、この精度です。




上に戻る


主題の定義

主題を定義するには、コンテンツの主題の1つの局面を識別するDITAトピック(一般には概念トピック)を作成します(図2参照)。


図2. 定義された主題
図2.定義された主題

DITAトピックは、次のような種類の情報を含む特殊化されたセクション要素で主題を指定します。

  • デフォルトのラベル。同義語と表示イメージを含みます。
  • 主題の定義と適用範囲に関するメモ。

リスト1は、Configuring(構成)主題の定義例を示しています。


リスト1.Configuring(構成)主題の定義
                
<concept id="configuring">
    <title>Configuring</title>
    <shortdesc>You configure components to set up or refine your solution.</shortdesc>
    <conbody>
        <p>You don't have to get the best configuration the first time....</p>
        <subjectDetail>
            <subjectLabels>
                <altLabel>Setting up</altLabel>
            </subjectLabels>
            <scopeNote>Administrative tasks performed after installation...</scopeNote>
        </subjectDetail>
    </conbody>
</concept>

この特殊化セクションは、セクション要素を許可する任意のトピック・タイプで使用することができます。具体的には、主題を正式に定義する既存の用語集、概念、または参照トピックを正式化するには、特殊化セクションを追加します。正式なトピックの意味は用途に応じて変化すべきではないので、これらのフィールドはトピックの一部でなければなりません。




上に戻る


主題の組織化

スキームの一部として、特殊化されたDITAマップ要素は、シソーラスまたはタクソノミー階層を定義する関係を指定します(図3参照)。


図3. 主題間の階層・関連関係
図3.主題間の階層・関連関係

階層は主題見出しを含むことができます。その意味は、主題見出しに含まれる主題の和集合に等しくなります。特殊化されたトピック・グループと関係表は、主題階層を横断する関連関係を指定します。

リスト2は、Installing(インストール)とConfiguring(構成)をTask(タスク)主題として、またResource utilization(リソース利用)とSecurity(セキュリティー)をConcerns(懸案事項)として識別する主題スキームの例です。


リスト2.主題スキームの例
                
<subjectScheme title="Sampletaxonomy" id="taxonomyScheme">
    <subjectdef href="task.dita" navtitle="Task">
        <subjectdef href="installing.dita" navtitle="Installing"/>
        <subjectdef href="configuring.dita" navtitle="Configuring"/>
        ...
    <subjectdef href="concern.dita" navtitle="Concern">
        <subjectdef href="utilization.dita" navtitle="Resource utilization"/>
        <subjectdef href="security.dita" navtitle="Security"/>
        ...

同じ主題について複数のスキームを使用することができます。たとえば、オーディエンスが異なれば、同じタクソノミーの異なるサブセットに興味を持つかもしれません。

このように主題に代替の組織構造を与えるというアプローチは、コンテンツからコンテキストを切り離すためのDITAマップの標準的な用途によく合致し、同じコンテンツに対して異なる組織を与えることができます。すなわち、スキームは主題定義トピックの特別な種類のコンテキストとみなすことができます。

スキームではDITA以外の主題定義(公に定義されたSKOS、OWL、またはTopicMaps主題など)を使用することができます。subjectdef要素で主題のパブリック識別子を引用して、format属性で主題定義形式を識別します。これによって、公に定義された主題をスキームに組み込んだり、会社の正式なオントロジーと個人のコンテンツに固有の概念を統合したりできます。

最後に、主題を階層的タクソノミーに組織化したり、主題間の関係をその他の方法で表現したりしない場合は、スキームを作成する必要はありません。スキームがなくても、コンテンツ・トピックを分類することはできます。たとえば、このアプローチを採用して、制御された索引や制御されたタグソノミー(tagsonomy)をサポートすることができます。この場合、トピックはタグによって分類されますが、正確な定義を持つ主題トピックを作成することによって、それぞれのタグを定義する必要があります。




上に戻る


コンテンツの分類

コンテンツを分類するには、さらにマップを特殊化することによって、正式な主題をトピックに関連付けます(図4参照)。


図4. 主題によって分類されたコンテンツ・トピック
図4.主題によって分類されたコンテンツ・トピック

分類されたコンテンツを参照し、その参照を含むtopicref要素の中で、topicsubject要素をネストして、コンテンツの主題を指定します。1次主題はtopicsubject要素のhref属性で識別することができ、topicsubject要素に2次主題のsubjectref要素を含めることができます。1次主題がない場合、topicsubject要素はhref属性のないコンテナでなければなりません。

リスト3は、コンテンツ分類の例です。


リスト3.コンテンツ分類
                
<topicref href="websecure.dita">
    <topicsubject>
        <subjectref href="webserver.dita"/>
        <subjectref href="security.dita"/>
    </topicsubject>
    <topicref href="https_protocol.dita"/>
    ... other subordinate content topics ...
</topicref>
<topicref href="loginsetup.dita" collection-type="sequence">
    <topicsubject>
        <subjectref href="configuring.dita"/>
        <subjectref href="webserver.dita"/>
        <subjectref href="security.dita"/>
    </topicsubject>
    <topicref href="editinguserdef.dita"/>
     ... other subordinate content topics ...
</topicref>

主題スキームがDITA以外のパブリックな主題を引用できるのと同じように、subjectref要素でパブリックURI識別子を引用し、format属性を設定することによって、SKOS、OWL、またはTopicMaps主題でDITAコンテンツを分類することができます。topicref要素でファイルを参照し、format属性でコンテンツ形式を識別することによって、HTMLやPDFファイルなどの非DITAコンテンツを分類することもできます。

主題は特殊なトピックによって定義されるので、主題定義をコンテンツに含め、それを分類に使用することができます。たとえば、Securityの主題トピックは、セキュリティーに関するコンテンツを分類できると同時に、Webサイトやヘルプ・システムのコンテンツ内でセキュリティーを記述することもできます。図5は、このシナリオを示しています。


図5. 分類されたコンテンツ・トピックでもある主題トピック
図5.分類されたコンテンツ・トピックでもある主題トピック

中央の円は、概念トピック(Securityなど)を表し、次のとおりとなっています。

  • スキーム内の主題(おそらくSystem Concerns(システムの懸案事項))と、より広い関係を持っています。
  • 他の2つの主題(おそらくBackground type(背景のタイプ)とNovice User role(初心者ユーザー・ロール))によって分類されます。
  • 1つのトピック(Web Securityなど)の分類に貢献します。
  • ナビゲーション・シーケンスにおいて2番目の位置を占めます(おそらく、Glossary heading(用語集見出し)の下)。



上に戻る


断片の関連付けと処理

分類マップはスキーム・マップとは別なので、分類に変更を加えなくても、同じ分類に複数のスキームを適用することができます。成果物のスキーム・マップと分類マップを結合するには、DITAマップ参照を使用して、上位レベルのマップで両方のマップを参照します(図6参照)。


図6. スキーム・マップとコンテンツ・マップから成果物を組み立てる
図6.スキーム・マップとコンテンツ・マップから成果物を組み立てる

1つのマップを処理して、コンテンツのHTML表現と主題および分類のSKOS表現の両方を生成することもできます。




上に戻る


処理のためのSKOSの生成

正式な主題を定義し、それらを階層スキームに組織化し、コンテンツを分類した後、変換を実行してDITA主題分類をSKOSに変換して、SKOSツールで処理することができます。実験するには、DITA Open Toolkit(「参考文献」を参照)をインストールして、この記事に付随しているデモ(x-dita10_thesaurus.zip)をダウンロードしてください。このデモは、demoディレクトリーをthesaurusサブディレクトリーで更新します。このサブディレクトリーには、サンプル・コンテンツを構築するための参考資料と説明書へのリンクを含んだreadme.htmlファイルがあります。

一般的なアプローチでは、SKOSツールは、ユーザーが閲覧できるようにシソーラスまたはタクソノミーを表示します。ユーザーは、1つ以上の主題を選択することによって、該当する分類済みコンテンツに移動します。たとえば、SecurityおよびWeb Server主題を選択すると、サンプル・トピックを表示することができます。このようなインターフェースの例は、Semantic Web Environmental Directory(SWED)サイトで見ることができます(「参考文献」を参照)。このフレームワークでは、主題分類にSKOSを使用しています。より高度な主題分類の使用も可能です。




上に戻る


まとめ

この記事では、コンテンツを分類するための基本を簡単に述べたにすぎません。DITA特殊化には、主題間の関連関係や表形式の分類など、他にもさまざまな機能があります。ただし、すでに述べたように、分類を操作するには個別の実行時ツールが必要です。また、主題を定義して、それらをタクソノミーに編成するという作業には、独自の戦略とベスト・プラクティスがあります。

さらに、このDITA特殊化を使用する場合、SKOS自体はまだ標準として受け入れられるには至っていないことを覚えておく必要があります。結果として、SKOS互換のDITA特殊化は、まだ発展途上と言えるでしょう。

しかし、DITA特殊化は、タクソノミーと分類をコンテンツの一部として保持するという価値をすでに実証しています。このアプローチを採用することによって、コンテンツ作成者は、セマンティックWebのテクノロジーを使用して、コンテンツの意味に基づき処理することが可能になります。





上に戻る


ダウンロード

内容ファイル名サイズダウンロード形式
Download for thesaurus specializationx-dita10_thesaurus.zip259 KB  FTP
ダウンロード形式について


参考文献

学ぶために

製品や技術を入手するために
  • DITAを処理するためのオープンソースのツールキット、DITA Open Toolkitをダウンロードしてください。


議論するために
  • dita-usersでは、DITAを採用している他の人達と議論することができます。


著者について

Erik Hennum氏は、IBM Storage Systems GroupのUser Assistanceを設計および実装する業務に携わっています。以前の職責でこれまでに貢献した業務には、生の実例を注釈付きのソース・コードと同期させるWebベース・システムの設計と開発があります。彼は、ハーバード大学で英国文学の学士号を取得したことを思い出したようです。連絡先はehennum@us.ibm.com です。


Photo of Robert Anderson

Robert D. Andersonは、1999年からIBMのInternal Information Development Workbenchに取り組んできました。SGML (IBMIDDoc) 用とXML (DITA) 用の両方の移行ツールを書いてきており、また維持管理も行ってきました。2001年からは主に、DITA用の変換ツールと、(OASISに移る前は)汎用のDITA設計に取り組んできています。連絡先はrobander@us.ibm.comです。


Photo of Colin Bird

Colin Birdは、IBM HursleyにあるUser Technologies Departmentの情報アーキテクトです。以前は、IBM UKのScientific Centreで、画像操作や視覚化アプリケーションを開発してきました。この仕事が幾つかの情報検索プロジェクト、特にコンテンツ・ベースの画像検索に関する検索プロジェクトに発展し、これが元でサザンプトン大学(Southampton University)のIntelligence, Agents, Multimedia Groupに一時留学することになりました。現在の地位は、サザンプトン大学における客員シニア特別研究員です。彼はこの研究をする中で、原則に基づく検索と情報の適応的提供の両方に利用できるようにするための、メタデータ捕捉に強い興味を持つようになりました。




記事の評価


サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。



 


 


不充分・不完全である大変素晴らしい
 


この記事を共有する

del.icio.us del.icio.us newsing newsing FC2ブックマーク FC2ブックマーク
Choix! Choix! ニフティクリップ ニフティクリップ Yahoo!ブックマーク Yahoo!ブックマーク
MM/memo MM/memo CZブックマーク CZブックマーク livedoorクリップ livedoorクリップ
はてなブックマーク はてなブックマーク Buzzurl(バザール) Buzzurl(バザール)




上に戻る


    日本IBMについて プライバシー お問い合わせ