タクソノミ

タクソノミは、関連概念の階層グループです。 Oracle Content Managementでは、タクソノミはコンテンツ作成者およびクライアント・アプリケーションでコンテンツを明確に定義されたカテゴリに分類するのに役立ちます。

例として車両のタクソノミを取得することで、詳細を確認します。

headless_taxonomies-example.pngの説明は以下のとおりです

この例では、車両タクソノミには2つの最上位カテゴリ(CarsおよびTrucks)があり、これらのカテゴリにはさらにいくつかの子があります。当然、これらの子カテゴリは、それぞれ独自の子カテゴリを持つことができます。そのような論理エンティティの構造は、基本的にはカテゴリの階層セットを表します。

次のトピックでは、Oracle Content Managementタクソノミについて説明します:

管理パースペクティブからのタクソノミ

タクソノミおよびカテゴリを定義すると、コンテンツの作成者はコンテンツをそのタクソノミのカテゴリに分類できます。

たとえば、Ford Fiestaと呼ばれるアセットは/Vehicles/Cars/Sedanに分類されます。任意の種類のアセットをカテゴリに分類できます。カテゴリは、特定のコンセプトに属するコンテンツの論理プレースホルダーにすぎません。

カテゴリへのアセットの追加は簡単です: カテゴリに追加するアセットを選択し、カテゴリを選択して追加します。

headless_taxonomies-categories.pngの説明は以下のとおりです

「図headless_taxonomies-categories.pngの説明」

アセットがカテゴリに追加されると、Oracle Content Management webインタフェースによって、直感的なツリー形式のナビゲーション構造で表示されます。コンテンツ作成者は、特定のカテゴリを選択して、そのコンテンツを表示または管理できます。これにより、コンテンツ管理のための組織ツールとしてタクソノミを使用できます。

headless_taxonomies-organization.pngの説明は以下のとおりです

「図headless_taxonomies-organization.pngの説明」

Oracle Content Managementインスタンスには、必要な数のタクソノミを設定できます。 1つのリポジトリに複数のタクソノミを含めることができ、同じタクソノミを複数のリポジトリで有効にすることができます。さらに、管理コンテキストのアセットは、複数のタクソノミに属することができます。 many-to-manyのタクソノミ、リポジトリおよびアセット間の関係により、コンテンツ設計者は高度なコンテンツ分類モデルを設計して使用することが容易になります。

headless_taxonomies-relationships.pngの説明は以下のとおりです

「図headless_taxonomies-relationships.pngの説明」

タクソノミ自体は時間の経過とともに変化することがあります。タクソノミが変更されると、アセットの分類も結果として変更されます(自動再分類)。ある親カテゴリから別の親カテゴリへカテゴリが移動されたとします。その場合、移動したカテゴリ(カテゴリの子)に属するアセットは、引き続き同じ親に属しますが、新しい祖父母を取得します。ただし、カテゴリが削除されると、そのカテゴリに属するアセットは、予想どおりに親カテゴリに昇格されます。

この意味で、カテゴリはアセットのコンテナではありません。かわりに、カテゴリ化について適切な方法が関係の観点です。カテゴリによりアセットはカテゴリに関連付けられます。

タクソノミ・ライフ・サイクル

タクソノミ自体を変更すると、カテゴリ分けの性質上、その影響を受ける可能性があります。そのようなタクソノミの変更は、多数のユーザー、および場合によっては複数のグループまたはチームを含む、マルチステップのプロセスである可能性があります。

そのため、Oracle Content Managementは、タクソノミ変更にオーケストレーションされたライフ・サイクルを使用します:

タクソノミは常にdraft状態で作成されます。これらは最初は構造定義の処理中とみなされ、アセットをそのカテゴリに追加することはできません。
タクソノミの構造を満足した後、タクソノミの作成者は「プロモート済」状態に卒業します。これは、リポジトリに対してタクソノミを有効化できる状態で、コンテンツ作成者がコンテンツの分類を開始できるようにします。ただし、この状態では、タクソノミ構造自体の変更は許可されません。
アセットが分類された後でタクソノミの構造を変更する必要がある場合、そのタクソノミをバージョン管理し、ドラフト・モードに戻す必要があります。ただし、ユーザーはコンテンツの分類を、プロモートされたバージョンのタクソノミに継続できます。その後、ドラフト・タクソノミをプロモートできます。これにより、(前のテキストで説明した一般的なルールを使用して)アセットの自動再分類がタクソノミの新しい構造に移入されます。
タクソノミ自体は、他のアセットと同様にチャネルに公開できます。公開されると、タクソノミおよびカテゴリ化情報が配信APIで使用可能になります。これにより、クライアントは、タクソノミ(製品リスト、ファセット・ナビゲーション、一部のタイプのメニューなど)に基づいてコンテンツを表示できます。

headless_taxonomies-lifecycles.pngの説明は以下のとおりです

「図headless_taxonomies-lifecycles.pngの説明」

搬送パースペクティブからのタクソノミ

タクソノミは、アセットと同様に公開されます。タクソノミを公開すると、配信APIで使用できるようになります。

配信APIのタクソノミ情報の表面には、次の2つの場所があります:

タクソノミの構造の確認

カテゴリ一覧によってタクソノミまたはカテゴリの構造を移動するのに役立つ多くのAPIがあります。

タクソノミのすべてのカテゴリ情報を取得する簡単な方法の1つは、この形式のAPIを使用することです:

GET http://.../content/published/api/v1.1/taxonomies/52446BF67CE74F229AF9F178448BCB80/
categories?fields=ancestors&channelToken=c240e6a4209946549a9eef53c8ed3ab0

アセットのカテゴリ分けの検出

標準的なアセット・リスト上のリソースは、特定のカテゴリ(またはカテゴリ)に分類されるアセットもリストできます。

これは、次の簡単な形式のAPIで行われます:

GET http://.../published/api/v1.1/items?q=(taxonomies.categories.id eq 
"77BD937EFCA54051905DD6D525E37E58")&channelToken=c240e6a4209946549a9eef53c8ed3ab0

この場合、次のようなレスポンスが生成されます:

{
  "items": [
    {
      "name": "Ford Fiesta",
      "description": "",
      "links": [],
      "id": "CORE23B05BB961AE4EE3AE4ED9962A0440ED",
      "type": "Vehicles"
    },
    {
      "name": "Ford Fiesta 2019 Launch",
      "description": "",
      "links": [],
      "id": "COREC6C72D74EAA0477AAE966CF154CB16C7",
      "type": "Marketing-Blog"
    }
  ],
  "links": []
}

このタイプのリクエストを行うには、カテゴリのIDを知っておく必要があります。ただし、簡易ID (スラグまたはAPI名)を使用してカテゴリのアセットを検出するもう1つの方法もあります。各カテゴリには、一意のハンドルを使用できます。このハンドルは、人間が判読可能であり、IDとしてアドレス可能な文字列です。カテゴリのAPI名は、作成時またはそれ以降のいつでもカテゴリに追加できます。 API名自体は、カテゴリIDのかわりに使用できます。また、カテゴリのAPI名(IDなど)はタクソノミ間で一意である必要があります。

CarsカテゴリのAPI名がall-carsで、Cars/Sedanカテゴリに対してall-cars.sedansがあるとします。この場合、前述のAPIコールを次のように記述することもできます:

GET http://.../content/published/api/v1.1/items?q=(taxonomies.categories.apiName eq 
"all-cars.sedans")&channelToken=c240e6a4209946549a9eef53c8ed3ab0

これにより、クライアント・アプリケーションはIDを渡すかわりに、意味のあるURLを提示できます。

さらに学ぶ...