XML タグのセマンティクス-XML/RSS チュートリアル-php.cn

[要約] XML 文書型定義は、XML 言語の構文を機械可読形式で記述することができるメカニズムを提供しますが、現在、XML 語彙の特定のセマンティクスを指定する同様のメカニズムはありません。これは、XML タグの意味を説明する方法がなく、XML によって表現される事実と関係を明確かつ包括的かつ規範的に定義できないことを意味します。これは、現実的かつ理論的に重大な影響を及ぼします。良い面としては、XML 構造に任意のセマンティクスを与えることができ、元の設計者が予期しない領域で使用できることです。あまり良い面ではありませんが、コンテンツ開発者とソフトウェアエンジニアは当たり障りのないドキュメントに頼らなければならないか、さらに悪いことにマークアップ言語設計者の意図を推測することに頼らなければなりません。このプロセスは時間と労力がかかり、エラーが発生しやすいため、検証することができません。たとえデザイナーのオリジナルの文書化作業が完璧に行われていたとしても、依然として満足できない状況が発生することはあります。さらに、マークアップの意味論的性質に関する研究が不足しているということは、工学アプリケーションの分野に属するデジタル文書処理には理論がまったく存在しないことも意味します。進行中のいくつかのプロジェクト (XML スキーマ、RDF、セマンティック Web) はある程度の成果を上げていますが、これらのプロジェクトはいずれも XML マークアップセマンティクスの中核問題を直接的かつ包括的に解決するものではありません。この記事では、マークアップの意味の概念の発展の歴史を振り返り、XML の形式的意味論を解釈する動機を明らかにし、意味論に関する科学研究プロジェクトである BECHAMEL マークアップセマンティクスプロジェクトを紹介します。
[キーワード] SGML XML マークアップ意味論的知識表現
1 はじめに

近年、デジタル出版の発展、World Wide Web アプリケーションの急増、電子商取引の急速な発展により、私たちの日常の社会、ビジネス、文化、彼らは皆、標準汎用マークアップ言語 (SGML) と拡張マークアップ言語 (XML) のテキストマークアップシステムを使用し始めました。 SGML/XML は、記述マークアップ言語を定義する機械可読テクノロジです。特別な処理が必要な一部の部分を除いて、この言語は文書の構造とその根底にある意味を明確に定義します。 SGML/XML は急速に発展しており、このテクノロジを広く使用することで、高パフォーマンスのドキュメントの相互運用性の処理と公開をサポートできます。
この美しい願いは部分的に実現されましたが、SGML/XML の優位性は人々の期待を超えていますが、SGML/XML ドキュメントシステムの機能、相互運用性、多様性、アクセシビリティはまだ改善の必要があります。この機会を捉えなければ、その結果は非常に深刻になります。業界は多額の財政コストを費やし、多くの機会を失いました。また、障害のある人々にとって重要な安全用途において何らかの惨事につながる可能性があり、障害のある人々の平等なアクセスが妨げられます。現代社会の文化的および商業的利益に貢献します。さらに、長年にわたる問題により、現在の最良のデジタルドキュメントモデルにはまだ欠陥があるか、少なくとも不完全であることがわかります。これらの問題の根本は、SGML/XML はドキュメントに意味のある構造を提供できるものの、SGML/XML はドキュメントのコンポーネントとトピックの間の基本的な意味関係を体系的かつ機械で処理可能な方法で表現できないことです。 SGML/XML は機械可読な「文法」の記述をサポートしていますが、特定の文法の意味的意味を説明するメカニズムを提供していないため、SGML/XML 語彙の潜在的な意味を正式に表現する方法はありません。現在の SGML/XML は、文書注釈システムに関する非常に単純な基本的な意味論的事実さえ表現できません。これらの事実は、通常、マークアップ言語の設計者によって事前に設計されていますが、具体的な実装は依然としてマークアップ言語のユーザーとソフトウェアに依存しています。
この表現力の欠如により、SGML/XML ユーザーは、マークアップ言語設計者が考えたが正式には表現しなかった意味関係を推測する必要があります。コンテンツ開発者は、コンテンツがエンコードされるときにデザイナーの意図を推測し、その推論に基づいて作業する必要がありますが、その推論や意図を他の人やエンコードされたコンテンツを処理するアプリケーションに明確に表現することはできません。ソフトウェア設計者は、マークアップ言語設計者の考えられる意図を推測し、この推測をソフトウェアツールやアプリケーションシステムに設計する必要もあります。場合によっては、二次的な推測が必要になることがあります。ソフトウェア設計者は、マークアップ言語設計者の意図をコンテンツ開発者が推測することを推測する必要があります。
明らかに、これらの推測は不完全で、誤りがあり、証明されていません。さらに、作成および実装プロセスには時間と労力がかかり、機能性や相互運用性も貧弱です。一般的な自然言語ドキュメントに SGML/XML 仕様を装備しても、この問題は完全には解決されません。もちろん、通常の自然言語ドキュメントはコンテンツプロバイダーやソフトウェアエンジニアにいくつかのヒントを提供できますが、現時点では SGML/XML ドキュメントに関する一般的なルールはありません。いずれにせよ、通常の自然言語ドキュメントは機械可読形式ではなく、これが SGML/XML マークアップシステムについて話している問題です。
SGML および XML に関連する機械処理可能な意味論的記述のアイデアはまだ形成されておらず、これが工学分野における現在の問題の原因であり、関連する意味論的研究もほとんどありませんが、多くの学者が取り組んでいます。この問題に注目し始めました。 W3CSchema に関する作業はこれに関連していますが、この問題のごく一部 (データ型など) のみをカバーしています。 W3Cの「Semantic Web」プロジェクトもこれに関連するが、一般的なXMLベースの知識表現技術の開発を目的としている。私たちの研究は、実際の文書処理システムに隠されている文書マークアップのセマンティクスに焦点を当てています。セマンティック Web の本質はセマンティックタグの設計にあると言われるかもしれませんが、本稿では、上記の問題を解決するには、タグの本質的な意味についても深く考える必要があると考えます。
次に、この記事では、まず歴史的背景からタグの意味を説明します (マーカーはテキスト処理方法の開発において興味深い役割を果たしました)。次に、どのような要因が正式なセマンティックタグの必要性を生み出すのか、またどのような要因がセマンティックを決定するのかについて詳しく説明します。最後に、複数の機関が参加している研究プロジェクトである BECHAMEL マークアップセマンティクスプロジェクトについて簡単に紹介します。このプロジェクトは、マークの意味論的問題の解決に熱心に取り組んでいます。
2 歴史的背景
文書の「マーク」はおそらく、初期の執筆、コピー、出版、印刷を含むコミュニケーションシステムの一部として数えられるでしょう。しかし、デジタルテキスト処理と植字の発展により、マークの使用は意識的になり、それはシステム開発における重要な革新分野となっています。 1960 年代から 1980 年代は、デジタル写植とテキスト処理の有効性と機能の向上に焦点を当てた、文書マークアップシステムの包括的かつ体系的な開発の時期でした。 1980 年代初頭、人々はまだマーキングとそれを使用して高性能システムの開発をサポートするための理論的フレームワークの開発に取り組んでいました。この分野の結果の一部は公開されていますが、そのほとんどは、さまざまな標準形式で実用的な文書や製品に記録されるだけです。
この段階で浮上した見解は、知的成果としての文書は、一連のオブジェクト (章、段落、数式など) の順序付けられた階層構造モデルとして抽象化する方が適しているというものです。テキスト文字の 1 次元ストリーム。文字ストリームは、フォーマット、デザインレイアウトを記述する構造 (ページ番号、列、印刷行など)、ピクセル値の行列、およびさまざまなドキュメント処理およびストレージシステムにおけるその他の潜在的な表現を定義する多数のエンコーディングと混合されることがよくあります。。順序付けされた階層構造モデルは、2 つの本質的に異なる注釈、つまり、編集テキストオブジェクト (タイトル、章など) を識別する注釈と、レイアウト要件を説明する注釈を要約します。前者の適用により、ある程度の成果が得られました。タイトル、章、段落、方程式、引用などの関連する文書要素は、区切りタグによって明確にマークすることができ、要素は要素タイプにマップされたルールを通じて間接的に処理できます。このコンテンツとフォームの分離により、一般的な組み合わせ経済における基本レベルの間接化と抽象化が可能になります。この形式の分離は、文書処理のあらゆる側面において非常に多様で実用的な価値があり、さらに重要なことに、文書とは正確に何なのかという問題を明らかにするようです。これを行うために使用される記述マークアップは、要素の範囲をマークするだけでなく、ドキュメントモデルが明らかにしたい意味も伝えます (たとえば、このテキストは章です)。
1980 年代初頭、アメリカ国立標準化研究所 (ANSI/ISO) は、影響力のある SGML 文書マークアップメタグラマーをリリースし、マークアップと文書構造に関するこれまでの理論的および分析的研究を整理しました。 SGML は、記述マークアップ言語を定義するための機械可読形式を提供します。メタ文法として、SGML はマークアップ言語を定義しませんが、機械可読マークアップ言語を開発するための技術を詳しく説明します。この定義の中核は、Backus-Naur Form (BNF) に似た形式的な表現メカニズムです。このメカニズムには、型付きプロパティとその値を定義するためのルールだけでなく、さらなる抽象化と間接化のための他の設計も含まれています (Document Type Definitions (DTD) および Backus-Noel A によるパラダイム類似度の要約に関するコメントを参照してください)。構造的には、SGML ドキュメントは、順序付けられた分岐とラベル付けされたノードを持つツリーであり、対応する DTD の正式な成果物です。
長年の分析と実践を経て、SGML の背後にある基本的な考え方はすでによく知られています。メタ構文レベルでの業界レベルの標準と語彙レベルでのローカライズされたイノベーションを利用して、SGML の独自のメカニズム (backus-norr パラダイムのようなメタ構文、型付き属性/属性値のペア、エンティティ参照など) が適用されます。プログラムとツールは効率的に実装されます。 SGML マークアップ言語自体は、ドキュメントシステムの設計、実装、使用のための理想的なワークフローをサポートおよび最適化しながら進化しているようです。 1980 年代半ばから 1990 年代初頭にかけて、多数の SGML ベースのアノテーションシステムが開発されました。
SGML の開発は大きな注目を集めましたが、アイデアは素晴らしく、複数の分野で実装に成功しましたが、最初の 10 年間はほとんど誰もそれを使用しませんでした。この結果には多くの要因がありますが、最も重要なことは、SGML 自体が複雑すぎることです。特に、SGML には多くの複雑なオプション属性が含まれており、対応するソフトウェアがそれらを実装する必要がないため、開発が非常に遅くなる可能性があります。 SGML ソフトウェアの。さらに悪いことに、ドキュメントが DTD で検証されていない場合、それ以上の分析は不可能になります。略語制御とは、文書の構文に関係なく要素の境界を決定できないことを意味します。さらに、SGML には他の属性も含まれているため、既存の構文解析ツールが形式的な文法に適用できなくなり、効率的な構文解析を実行できなくなります。
オンラインパブリッシングとコミュニケーションの観点から、SGML システムは HTML (ハイパーテキストマークアップ言語) に適用できます。 HTML の元のバージョンは大まかに定義されており、正式な構文の指示がありませんでした。その後、HTML の SGMLDTD に関心が集まり、「正しい」慣行となったものに合わせて DTD を設計するのは難しいことが判明しました。さらに重要なのは、元の HTML 仕様では、ベンダーが主要な説明タグ (

など) にプログラムタグ (<center> など) を恣意的に追加したため、開発者とユーザーが説明マークアップと手続き型マークアップの区別を無視する原因となっているためです。 HTML の記述部分はドキュメントの階層構造をあまりよく反映しておらず、仕様では間接化をサポートするスタイルシート言語も提供されていません。最後に、SGML のメカニズムでは、要素セットを拡張したり、置換要素セットを使用したりすることはできません。HTML ドキュメントは、一般的な SGML プロセッサ (DTD の拡張と置換が可能) では処理できず、SGML プロセッサでのみ処理できるようです。プロセッサと連携する特定の HTML フォーマッタ。ハードコードされた書式設定ルールは HTML タグを処理します。 その後の HTML の発展は、元の緩やかな HTML 言語から SGML 言語シーケンスへの変換のプロセスとして見ることができます。この変革は、実証済みのドキュメントシステム設計ルールを適用するのに十分な時間とリソースがあれば達成可能です。しかし、新しく設立された W3C 組織は、新しい要素コレクションを採用し、SGML を Web に適用するという大きなプレッシャーに直面しています。 SGML には欠点があるため、Web 上で SGML と記述マークアップを活用することが困難になります。主な問題は、多数の複数選択機能、複雑な形式文法があり、SGML の要素を決定するために DTD に依存する必要があることです。 HTML およびその他の関連テクノロジーがメタ構文を最大限に活用できるようにするため、ユーザーは新しいドメイン固有の要素をより簡単に開発および共有でき、DTD インデックスを作成せずにドキュメントを要素ツリーに解析でき、SGML ツールとアプリケーションは、開発に際し、W3C は SGML のサブセットを作成し、比較的単純な標準 (選択の必要がない)、比較的単純な構文、および DTD なしで未検証の文書形式を処理する方法を提供することを期待して、XML が誕生しました。 1 年半の開発を経て、XML は 1998 年に W3C の推奨標準として正式に発表されました。 1998 年以来、新しい XML マークアップ言語は爆発的な成長を遂げ、この急速な開発の勢いは今日まで続いています。この爆発的な発展の理由は次のとおりです: (1) 特定の分野における新しいアノテーションシステムの必要性。ネットワーク化された電子出版アプリケーションが科学、医学、ビジネス、法律、工学、およびこれらの大きな分野の特定の分野で成長するにつれて、新しい注釈システムを開発する必要があります。 (2) 新しいツールとそのアプリケーションの開発コストと複雑さを軽減します。 XML の解析は SGML に比べて簡単です。 (3) XML タグは、出版に関連する情報処理と配布プロセス、および出版に関係のないアプリケーションをサポートします。 ありがたいことに、私たちはついに、他の情報管理プログラムと統合する高性能マークアップ言語、デジタル文書、文書処理および出版システムを作成するための、効果的で実装が簡単なテクノロジーを開発しました。特に、文書構造の根底にある意図を深く処理する必要性が、新しいシステム機能の出現を促進し、また、情報の自動処理の必要性、少なくとも、文書を必要としない新たなニーズを高めたことを指摘すべきである。手作業による介入が多い。 3 つの質問 残念ながら、これまでの経験やフィードバックによって、記述マークアップの意味と現在のテクノロジーの理解では期待に応えられないということがはっきりとわかりました。 1980 年代、ドキュメントマークアップの体系化と体系的な作業は主に 3 つの側面に焦点を当てていました。 (1) ユニバーサルドキュメントモデルの概念化。 (2) 文書マークアップ言語に関連する正式仕様、語彙および文法関連技術の開発。このドキュメントマークアップ言語は、特定のドキュメントクラスを定義し、モデルをインスタンス化して提示できます。 (3) マークアップ言語の開発（CALS、AAP、TEI、HTMLなど）。 記述マークアップ言語を使用して文書の論理部分を識別し、注釈を付けると、以前は潜在的な形式でしか存在できなかった「意味」を明確に伝えることができます。少なくとも、手続き型マーカーの意味は明確かつ明確で、機械処理に適したものにすることができます。 多くの人は XML ドキュメントを「自己記述データ」と呼んでいます。初期には反対の声もいくつかありましたが (マムラック、そして最も重要なことに、レイモンドとトンパの見解を参照)、記述的マークアップの開発の初期段階では、文書研究者の熱意は薄れ、ほとんどの研究者が探索する必要を感じていないようでした。さらに手間のかかる文書表現。明確に定義された SGML マークアップ言語は、文書構造の基本的な意味を表現するため、機械処理に完全かつ効果的に使用できます。この記事の著者の 1 人は、かつてこの文章の執筆に参加しました。「競合するマークアップシステムにとって、記述的マークアップは最良の方法であるだけでなく、考え得る最良の方法であることは明らかです。」 1990年代の経験は、この自信がいくぶん盲目であることを示しています。実際的な観点から見ると、今日では状況は大幅に改善されていますが、相互運用性や機能性における度重なる失敗は、SGML/XML が根本的な意味を持つドキュメントとコンピュータ処理可能な形式を提供することに実際には成功していないことを示しています。 SGML/XMLDTD では、要素と属性の精度が他の同様のドキュメントタイプ定義の精度と一致せず、コンテンツの一部が形式的ではなく、推論を行う必要がある単一の明確な答えがありません。しかし、定性的に言えば、人々の文書に対する理解は SGML の出現以前とは異なります。当時、人々の文書構造の意味の理解は、比較的あいまいな手がかりを考察することから来ていました。 DTD の重要な属性は、上記の状況の理由を説明します。DTD は語彙とそれに対応する文法を表示するだけであり、単語間の意味関係を表しません。一般的な意味での「タイトル」要素が<title>で表されるかどうか、<title>が通常言う「タイトル」の概念に類似するかどうかは、DTDでは判断できません。 DTD は、ラベルが文字列「title」である特定の要素が存在することのみを示すことができます。このラベルは、すべて同じ方法で定義されている他の要素とともに使用できます。したがって、マークアップ言語を使用してドキュメントに注釈を付けるコンテンツ開発者やソフトウェア設計者は、テキスト内の「タイトル」に関連付けられた自然言語から <title> タグの意味と、それがコンテキスト内でどのように使用されているかを単純に推測する必要があります。おそらく、元の言語の設計者は、<title> の意味を体系的かつ厳密に定義できませんでした。 もちろん、これは実際の状況を誇張しています。ある意味、各マークの意味は、基本的に、マークアップ言語開発者が提供する純粋に自然言語のドキュメントで明確に表現できます。しかし、産業分野や学術分野で最高の評価を得ている DTD 文書であっても、問題を根本的に解決するわけではありません。 マークアップ言語の意味関係を反映するソフトウェアを設計する場合、言語設計者はドキュメントのさまざまな部分間の関係を明確に表現できなければならず、その後ソフトウェアエンジニアは使用 (検索、検索、開く) できる必要があります。このマークアップ言語ドキュメントとその利点を表現するアプリケーションを設計します。どちらの手順も機械では検証できず、信頼性も保証できません。手動による参加が必要な場合、高性能のネットワーク文書処理および公開システムの開発が妨げられます。したがって、マークアップ言語の設計者が意味論的な関係を詳細かつ形式的に指定でき、アプリケーションによって読み取られて処理でき、いちいち手動で参加することなく自己構成を完了できることを保証するメカニズムが必要です。 具体的な意味関係をいくつか見てみましょう。これらの関係には多かれ少なかれ潜在的な実用的価値がありますが、機械で処理できる標準的な表現がないため、現時点では簡単かつ体系的に利用することはできません。実際、多くの関係は非常に重要であるため、ソフトウェア設計者は特定の方法でドキュメント内での関係の存在を推測し、それらを利用するための特定のシステムを構築します。 クラス関係。 SGML/XML には、要素、特性、特性値におけるクラスの階層構造やクラスメンバーシップを表現するための一般的な構造が含まれていません。クラスは、ソフトウェアエンジニアリングの現在の主流の構造において最も基本的かつ実践的なモジュールです。段落が構造要素である (isa 関係)、またはすべての構造要素が編集可能な要素である (ako 関係) とは言えません。 2 つの基本的な SGML/XML 設計では、属性/値 (具体的には「type」属性と「class」属性を使用) による基本的な分類を実装できる場合があります。この分類技術はまだ十分に成熟しておらず、SGML と XML はその使用を制御および制限するためのより優れたメカニズムを提供できません。実際のアプリケーションでは、多くのドキュメントタイプ設計者がクラスの階層構造を設計に使用します。 XML スキーマはクラス関係を明確に宣言しますが、これらの複合型と他の複合型の違いを意味的に説明することはありません。 継承関係。多くのマークアップ言語 (TEI や HTML4.0 など) では、特定の属性がそれを含む要素によって継承され、場合によっては、含まれるテキストコンテンツもこれらの属性を継承します。たとえば、要素の属性/値の表記が「lang="de"」である場合、これはテキストがドイツ語であることを示しており、その子要素の属性がすべてドイツ語であることを意味します。ただし、DTD は、どの特性を継承できるかを指定するための正式な指示を提供していません。さらに、このような継承関係は固定されたものではなく、含まれる要素の二次定義によって変更される場合があります。継承にはさまざまな方法があり、要素の属性を使用する方法、属性の属性を使用する方法、要素のテキストとコンテンツを使用する方法があります。たとえば、タグが文がドイツ語であることを示している場合、これは (特別な状況を除いて) 文内のすべての単語がドイツ語であることを意味します。同様に、deletion 属性でマークされたすべての語句が削除され、key 属性でマークされた語句が強調されます。コンテンツの一部を段落としてマークすると、コンテンツのこの部分のすべての単語 (または要素) が属することを意味します。この段落へ。 DTD が継承するプロパティやその継承ロジック (ルールエラーを含む) を指定することはできません。ソフトウェア設計者は、多くの場合、特定のマークアップ言語でこれらの関係を推論し、開発するツールやアプリケーションに実装します。 文脈関係と参照関係。多くのマークアップ言語では、要素が固定の意味を持ち、同じ要素タイプをマークするために使用される場合でも、この要素はコンテキストが異なるため、異なる意味を持つ場合があります。たとえば、一部のテキストは「<title>」としてマークされており、その具体的な意味はテキストの構造上の位置によって異なります。「」の下の「<title>」はオブジェクト「<document>」のタイトルを指しますが、「<chapter>」の下の「<title>」はこの章のタイトルを指します。一部。どのようなタイトルであるかを決定する基準はありません。参照に「<title>」要素が含まれており、タイトルが記事の外部にあるエンティティである場合、状況はさらに複雑になります。このような関係は DTD では表現できませんが、ソフトウェア設計者によって推論できます。これはテキストの効率的な自動処理に必要です (それぞれの意味が異なる汎用識別子で表現されている場合、問題のごく一部しか解決できません)これは、属性のバイナリ特性を明確にし、属性が適用されるオブジェクトを見つけるための解析可能な式を提供する必要があるためです)。 意味の本質的な変化。同じオブジェクトに複数の属性があり、それぞれが同じ形式の同じ指示対象を参照するが、その指示対象の曖昧さを確実にするために慎重に解釈する必要がある、同様ではあるがより曖昧な状況が存在します。たとえば、特定の要素インスタンスには、定理であること、ドイツ語で書かれていること、判読できないことの 3 つの特性があります。このような単純かつ直接的な述語記述は同じもの (または要素インスタンス) を表しているのでしょうか?この知識の表現は十分に堅牢ですか? それが実際に意味するのは、これらの抽象的な文章はドイツ語で書かれており、表現される命題は定理であり、その具体的な表現パターンは曖昧であるということです。厳密に言えば、これらの特性をすべて備えた単一のオブジェクトは存在しません。 完全な同義語と部分的な同義語。マークアップ言語の完全または部分的な同義語は非常に重要な意味関係ですが、この同義関係を記述するメカニズムの欠如により、深刻な異質性の問題が生じます。単一のマークアップ言語を使用すると、完全な同義語が排除される可能性がありますが、マークアップ言語の種類が増えるにつれて、完全な同義語と部分的な同義語を表現することは依然として困難ですが、マークアップ言語間の重要な関係は変わりません。現在、要素、属性、および属性値の同義語をさまざまなマークアップ言語で文書化するための、コンピューターで処理可能な適切な正式な方法はありません。構成形式 (以下を参照) では、ほとんどの完全な同義語を記録できますが、部分的な同義語を記録するのは難しく、実際のアプリケーションでは部分的な同義語の方が一般的です。クラス包含関係によって表される部分同義性問題は、異質性問題の解決に依然として大きな役割を果たしています。 4. BECHAMEL プロジェクト BECHAMEL マークアップセマンティクスプロジェクトは 1990 年代後半に始まり、文化科学部、言語情報技術部の Sperberg-Mcqueen (W3C/MIT) およびその他の機関の研究者によって完成されました。、ベルバーゲン大学研究財団、電子出版研究グループ、図書館情報科学大学院、イリノイ大学アーバナシャンペーン校。プロジェクト名は、すべての協力者が所在する都市の略語から形成されています (ノルウェーのベルゲン、イリノイ州シャンペーン、ニューメキシコ州のエスプニョーラ)。 BECHAMELプロジェクトの研究目的は以下の通りです。 (1) 文書マークアップのセマンティクスに密接に関連する表現および推論の問題を定義し、すべてのセマンティクスを意識した文書処理システムが解決または直面する必要がある問題の分類と説明を開発します。 (2) 一般的なマークアップ言語の特性と意味関係を研究し、標準化された知識表現技術 (意味ネットワーク、フレームワーク、ロジック、形式文法、生成ルールなど) の適用可能性を評価します。これらの関係と属性をモデル化するには、知識表現におけるそれらの適切性、優雅さ、単純さ、および計算効率も考慮する必要があります。 (3) マークアップ言語のセマンティクスを表現できる、正式な機械可読表現フレームワークを開発およびテストします。 (4) トランスコーディング、情報検索、アクセシビリティ強化などのサポートなど、意味論的表現テクノロジーの応用形態を探ります。私たちは現在、ドキュメントデータベースインスタンスの意味論的推論をサポートすることに重点を置いています。これが知識表現テクノロジを適用するための最良の焦点であると考えているからです。 (5) 人文科学コンピューティング研究の分野でデジタルライブラリコンテンツコーディングプロジェクトと協力し、ソフトウェアツール開発者を団結させて意味表現ソリューションの大規模テストを実施します。 初期の Prolog 実験ベンチは、構造化文書で事実と推論ルールを表現するための知識表現プロトタイププラットフォームとして完全に開発されました。このシステムを使用すると、アナリストは特定の事実 (ユニバーサル識別子や属性値など) を指定し、それらを意味論的なエンティティや属性に関する推論事実から分離できます。 このシステムは、タグの意味を機械可読で実行可能な形式で明確に表現できる抽象化レイヤーも提供します。これに基づいて、階層的に重複するコンポーネントなどのあいまいな構造を含む文書コンポーネントに基づいて推論を行うことができます。私たちは、ノード階層ナビゲーションのために W3C ドキュメントオブジェクトモデルで使用されるメソッドを模倣し、ドキュメントタイプ定義内のさまざまなプロパティ値と関連情報を取得できる述語のセットを開発しました。これにより、パーサーによって分析された文法情報と、アナリストによって表現された文書セマンティクスとを明確に区別できるようになります。 予備的な研究結果は、意味論的認識の複雑さと文脈の不確実性の理解の複雑さを示しています。このプロトタイプ推論システムは、タグに関する自動推論が実現可能であること、および Prolog のルールが非単調性や状況の曖昧さなどの複雑な状況を処理できることを証明しています。さらなる研究は引用を参照することができます。 5. マークアップのセマンティクスモデリング ドキュメントマークアップのセマンティクスは、マークアップ言語ユーザーが理解できる抽象的な構造、属性、および関係です。マークアップとその構文は、このセマンティクスの手がかりを暗示します。タグのセマンティクスでは、知識表現テクノロジーを使用して、構造、関係、属性を明確にすることで、対応する計算モデルを構築できます。 XML マークアップドキュメントの次の断片を参照してください <img src="https://img.php.cn//upload/image/197/946/771/1488002955228879.jpg" title="1488002955228879.jpg" alt="XML タグのセマンティクス"> 化学マークアップの構造に精通している読者は、ドキュメント要素内のタグ P が段落を表すことを自然に知っているでしょう。そして、title 要素の後の段落コンテンツは text の本文を形成します。これは、header 要素の後に始まり、段落終了タグの前で終わります。タグの意味と使用法はすぐには分からないため、作成者または読者はタグコレクションのドキュメントを参照できます <img src="https://img.php.cn//upload/image/526/100/980/1488002987952563.jpg" title="1488002987952563.jpg" alt="XML タグのセマンティクス"> 明らかなタグは、人間の読者の利便性を考慮して設計されています。これらのタグは、ドキュメントパーサーを使用してデータ構造から抽出することはできません。図 1 に示すように、解析ツリー (スタイルシートプログラマが使用) には、見出し、引用、および引用の前後のテキストが表示されます。これらはそれぞれ段落の個別の子ノードですが、解析ツリーでは、以下の特徴があります: 見出しこれは段落全体の属性であり、テキストは内容構造の 2 つの部分であり、引用はテキスト内に埋め込まれます。 実際、データ構造自体には、段落と引用、またはそれらに関連するものとの区別はありません。データ構造は、「段落」値を持つ汎用識別子のような、単に関連情報のグラフィカル構造です。プログラムは、文書の意味と使用されているタグの間の一貫性を推測し、ツリー構造がある形式から別の形式に変換されるときにこの知識を活用できなければなりません。ただし、この変換 (たとえば、XSLT、DSSSL、または C++ などのプログラミング言語による) は、明示的なエンコーディングではなく意味論的な推論に依存します <img src="https://img.php.cn//upload/image/767/427/454/1488003021428176.jpg" title="1488003021428176.jpg" alt="XML タグのセマンティクス"> 図 2 は、セマンティック知識を活用して構文ツリーを強化および強化する方法を示しています。知識表現技術を利用すると、全体と部分の関係をより高いレベルでコード化することができ、コンピュータ処理に適したものとなります。この図は、従来のセマンティックネットワーク表現方法を示しています。もちろん、フレームワーク表現、ルール表現、形式文法、ロジックベースの表現など、他の方法も開発中です。セマンティック Web プロジェクト (この記事のパート 8) の開発により、マークアップ言語自体に適切な表現方法が提供される可能性もあります。問題の核心は、従来の XML/SGML パーサーではモデル化および強制できない抽象化、関係、および制約の階層を確立することです。 機械可読ファイル (DTD や構文構造など) のエンコーディングの知識を使用して、ドキュメントの意味上の制約を検証し、アプリケーションにより強力なドキュメントモデルを提供できます。これらのより表現力豊かな表現方法は、より優れた文書処理システムの設計と実装を強力にサポートします。 6 アプリケーション 近年、多くの新技術の開発により、従来の構造化アノテーションがますます普及しています。これらのテクノロジーは、情報管理において主に次の側面に重点を置いています。 変換して参加してください。 SGML/XML 開発者にとって、最も一般的な仕事は、あるアプリケーション構文から別のアプリケーション構文に変換するための変換フォームを設計することです。これは、ファイルの新しい表現を作成するため、またはデータベースへの保存を容易にするために行われます。場合によっては、開発者は、それぞれが相互運用不可能なマークアップ言語で表されるデジタルドキュメントの大規模なコレクションを統合または適応させる必要があります。変換のサイズに関係なく、従来の解決策は、解析ツリーに直接作用する変換プログラミング言語を使用することです。ソースファイルの解析で生成された木構造は、ターゲット言語の木構造インスタンスに変換されます。変換されたツリーは、新しいドキュメントインスタンス、グラフィックス、またはオーディオにシリアル化されます。 情報島。この問題は上記の変換問題に非常に似ていますが、目的は、ある形式のドキュメントを別の形式のドキュメントに変換することではなく、ドキュメントまたはドキュメントの断片の分散ストレージを可能にして、共通の透過的なアクセスインターフェイスをシステムユーザーに提供できるようにすることです。ドキュメントをあるマークアップ言語から別のマークアップ言語に逐語的に変換する必要はありませんが、システムは、ドキュメントのエンコーディングが大きく異なる場合でも、ドキュメントのコンテンツがシームレスに融合しているように見えることを保証できなければなりません。 可用性。オーサリングツールでは構造化マークアップがますます採用されており、視覚障害のあるユーザーにとってデジタルドキュメントにアクセスする際の恩恵となっています。宣言型マークアップを使用すると、スクリーンリーダーや点字ディスプレイを使って読むことができ、グラフィカルな手がかりを利用するのではなく、ニーモニックを使って推論することができます。ただし、現在、そのようなアプリケーションは、ユーザー自身の機能やインターフェイスソフトウェア、および独立したタグの内容や文法に基づく構造推論に依存する必要があります。タグセットのドキュメントで説明されているように、タグの構文の制約とタグの意味と使用は、ドキュメントの作成者の信頼性に厳密に依存します。残念ながら、作成者はタグを誤用することがよくあります。最悪の例は、Web ページ上の特定のレイアウトをマークするために「head」タグを使用することです。 安全な取り扱い。より表現力豊かなマークアップスキーマ言語 (W3C の XML スキーマ言語など) の開発の原動力の 1 つは、マークアップエラー、誤用、悪用が、不適切にフォーマットされた出力よりもはるかに深刻な結果をもたらすという認識です。宣言型マークアップは電子商取引だけでなく、医療記録や航空業界などの安全な情報分野でも使用されています。これらの分野の開発者は、デジタルドキュメントの文法構造が標準化されていることを確認するだけでなく、ドキュメントの安全な処理、保存、送信、プレゼンテーションを保証するために特定のセキュリティプロトコルに準拠していることも確認する必要があります。 マークアップセマンティクスの 7 つの利点 BECHAMEL プロジェクトの現在の研究結果は、マークアップセマンティクスが次の方法で上記の問題を解決できることを示しています。 宣言的で機械可読なセマンティック記述。現在の実際の状況に関する限り、構造化マークアップ言語の設計者は自然言語テキストを使用してタグの意味を表現し、タグの適切な使用法を明確にしています。正式なマークアップセマンティックシステムにより、オントロジー間の関係がコンピュータープログラムによって明確に表現され、自動処理が可能になります。 仮説の検証。正式なタグのセットがないドキュメント環境では、タグのセマンティクスを解釈する機能を備えたシステムが、推測をテストし、仮説を検証するための環境を提供します。この環境では、マークアップ言語の非公開ユーザーは、ドキュメントデータベースに一貫して適用されていると信じているプロパティとルールについて推測します。次に、文書処理ソフトウェアは、想定されたルールと互換性がある文書要素または互換性のない文書要素を取得します。 セマンティック制約の強化。妥当性検証をサポートするパーサーは、従来のセマンティックパーサーのように構文検証を完了できるだけでなく、セマンティクスを検出または作成する際に推測を検証することもでき、セマンティック制約を強制することもできます。この操作は仮説検証と一致しますが、この場合、意味論的な制約は既知であり、標準的です。 最適化され、より表現力豊かな API。マークアップセマンティクスは、SGML および XML アプリケーションを使用してデジタルドキュメントを変換または表現するときに使用されます。ただし、より高いレベルのプロパティと関連付けは、プログラムが実行された場合にのみ明らかになります。形式的で機械可読なセマンティクスは、アプリケーションインターフェイスを強化し、マークアップ言語の開発と変更によりソフトウェア設計をスピードアップします。これらのソフトウェアはより便利で安全に保守できるようになります。 8 関連研究 上記の課題や問題に対応して、他にも多くの文書処理技術、標準、研究計画が存在します。次に、これらの問題に対処しようとする既存のアイデアを確認します。 セマンティックウェブ。セマンティック Web とは、マークアップや知識表現テクノロジに関する現在のアイデアのような、相互に関連した多くの研究と標準化の取り組みを指します。中心となるのは W3C リソース記述フレームワークであり、もちろん ISO のテーママップテクノロジなどの他のテクノロジも含まれています。セマンティック Web は広範囲にわたる野心的な目標を掲げており、普遍的な知識表現技術を使用してマークアップ言語を改善し、それによって「人類の知識の包括的な発展を促進する」ことを目指しています。セマンティック Web の研究と標準化は、現在の考え方とは異なります。つまり、特定の分野の意味論的な記述ではなく、すべての分野の知識の意味論的な注釈を実現することを目的としています。現在の研究目標は、「一般的なセマンティックマークアップ」ではなく、「ドキュメントマークアップセマンティクス」に特に焦点を当てています。セマンティック Web テクノロジーの進歩により、セマンティック Web マークアップ言語を使用してタグのセマンティクスをエンコードできるようになります。 W3C のドキュメントオブジェクトモデル。ドキュメントオブジェクトモデルは、XML ドキュメントの分析後に生成される階層データ構造であるアプリケーションプログラミングインターフェイスです。人々は、DOM によって提供されるマークアップ構文関連のフォームと同様に、マークアップセマンティクスのためのさまざまなインターフェイスを提供できるシステムを設計し、最終的には W3C の構文 DOM を補足する「セマンティック DOM」を形成したいと考えています。 W3C スキーマ。 XML スキーマは、従来の DTD を置き換え、XML ドキュメントを制約するために使用できる XML ベースの言語です。この言語の開発は、BECHAMEL プロジェクトで直面した問題と同様の DTD の制限によって推進されました。スキーマを使用すると、ドキュメントクラスの設計者は、高級プログラミング言語と同様に、複雑なデータ型を定義できます。ただし、タグセットのドキュメント内のすべての関係と制約をエンコードするには、現在の XML スキーマよりも強力な表現形式も必要です。ハイパーメディア/時間ベースの構造化言語 (HyTime) のアーキテクチャ形式。適応可能なアーキテクチャ技術は、さまざまなマークアップ言語アプリケーションが、スタイルは異なるが意味的には同等の構造でエンコードされることが多いという認識から生まれています。スキーマフォームを使用すると、ドキュメントクラスの設計者は、独自の特定の要素インスタンスを、異なるアプリケーション間でマッピングしやすい、より一般的なスキーマインスタンスにマッピングできます。これらのマッピングは実際に意味論的知識の制約された形式を表しており、上記の変換と統合の課題を解決するのに役立ちます。 BECHAMEL プロジェクトは、部分的には、建築形式よりも意味論的な関係を表現するモデルを構築することを目的としています。 上記は XML タグのセマンティクスの内容です。さらに関連する内容については、PHP 中国語 Web サイト (www.php.cn) に注目してください。