いろいろ調べごとをしながら記事を書いていると参考文献（参照記事）の逆引きがしたいと思うことがある。
Drupalでの実装案を作成してみた。冒頭の画像は、そのコンテンツタイプをUML表記したものである。記事を起点として、参考文献リストと外部参照リストという形でモデル化してみた。
WikipediaのDrupalのページを見ると「脚注」という形で参考記事があり、そこから、Releases for Drupal coreほかの外部リンクがついている。これで十分と言えなくもないが、もし、WikipediadeでDrupalを参照している記事を探せたら嬉しいと考える人も（私を含めて）いる。
Drupalの調査記事を書けば、モジュールプロジェクトなどを参照することになる。例えば、この記事ではInline Entity Formを使っていて、リンクを張っている。私は良くGroupモジュールを使っているので、何度もそのモジュールプロジェクトページにリンクを張っている。何年も記事を書き続けていれば、かつて書いた記事も忘れてしまうし、そこで問題解決した手順も忘れてしまうから、自分がGroupに関してどんなことを書いたか振り返りたくなるときもある。
とりあえず、Wikipediaの「脚注」に相当する参照文献リストコンテンツ作って、それに検索をかけるということもできるが、サイト内であれば、entity referenceで関連付ければ、正引きも逆引きもViewsで簡単に実装できるから、このモデルで、2段階化すると、External Referenceからの逆引きが可能になる。
実際の値としては、External ReferenceのタイトルにWeb記事のタイトルを記入し、external linkの値にURLを記入しておけば良い。Referenceの方は、記事内の引用タイトルを参照番号付きで書いておき、Eternal Referenceを参照する。魚拓をとって起きたければcaptureフィールドにPDF化したファイルを収めておけば良い。エンティティ化しておけば、最終更新日は自動記録されるから、最終確認日あるいは魚拓取得日にはそれを用いれば良い。Drupalの場合モジュールページはどんどん更新されるから、魚拓をとっておかないと意味が通じないこともある。それでも読者には最新版のリンクを提供したい。
ユーザー（読者）視点では、このモデルは好ましいと思えるのだが、執筆者視点では、コンテンツが3つになると、3つコンテンツを作成することになり執筆体験は低下する。また、Articleをそのまま表示しただけでは、直接モジュールページへのリンクが出てこないことになる。この2つの問題を解決しないと、実用的にならない。
編集体験の向上に有効なのは、Inline Entity Formモジュール。このモジュールを導入すれば、入れ子となるReferenceコンテンツ、External ReferenceコンテンツをArticleから直接編集できることになる。
表示体験の向上に有効なのは、ViewsとLayout Builder（いずれもcoreに同梱）の組み合わせ。
以下、実装案は、当サイトのGroup Membership Requestを使ってみたを例にトライアルサイトで検討した。
編集体験
トライアルは、Inline Entity Formをインストール有効化し、referenceコンテンツタイプの定義、External Referenceのコンテンツタイプの定義、articleへのフィールド追加が済んだところから始める。
まず、articleのManage form displayでreferenceフィールドをinline entityに対応させる。
参照文献(reference)は記事に固有なもの（既存のreferenceを参照する必要はなく常に自分で書くもの）なので、Allow users to add new nodesはオン、Allow users to add existing nodesはオフにする。同様にreferenceコンテンツタイプのManage form displayでSite referenceフィールドをinline entityに対応させる。
こちらの方は、初出の場合は、自分で書くが、2回目以降は既存コンテンツを参照する必要があるので、Allow users to add existing nodesもオンにしておく。
ついで、元記事をコピペで作成する。
一番下の部分にreferenceのAdd new nodeが出てくるので、これをクリックし、一番最初に引用しているGroupを登録。
ついで、Site referenceのAdd new nodeをクリックして、孫コンテンツを作成する。
孫、子の順で、Create nodeをクリックするとコンテンツが仮作成されるが、親記事をSaveするまでは実際のコンテンツは生成されない。
Saveすると、文末にreferenceが表示される。
ちなみに、ノードは孫、子、親の順で作成される（トライアルサイトではnode/10（Group）, node/11(1. Groupモジュール), node/12(Group Membership Requestを使ってみた)の順）。参照先コンテンツが存在しないと、entity referenceフィールドを設定できないから、この順序になるのは納得できる。
再編集して、referencesの追加(Add new node)をクリックし、2つ目の文献も同様に登録する。
問題なく追加できることが確認できる。
表示体験
現在の設定では、Referenceの1. Groupモジュールをクリックし、Site referenceのGroupをクリックし、external linkのGroupをクリックすることで、ようやくGroupモジュールのページに到達できるこれでは困るので、まずはViewsを作成する。
external referenceの中にあるlinkフィールドまで一気に見られるようにしたいので、Relationshipsを2つ定義する。
孫に到達できるようにするためには、子からの関係であることを指定する必要がある。
ついで、Relationを意識しながらフィールドを追加。
internal_referenceのフィールドにはreferenceフィールドの関係、external_referenceのフィールドには、internal_linkフィールドの関係を適用する。
Previewを見ると、captured file列は現在は空だが、Referenceコンテンツで魚拓をアップロードしていればそのリンク、external linkはプロジェクトページ、site referenceは外部参照コンテンツへのリンクとなる。後ほど、このリンクを辿ると、逆引きに到れるようにする。
TitleフィールドをArticleのTitleからReferenceのタイトルに変更する（リンクは不要）。
sort順も変更すると概ね必要な情報（deltaは本来表示不要）が得られるようになる。
最後に、Contextual filtersを設定して特定の記事のみに表示を限定するとともに、表示を調整する。
現在の記事がnode/12なので、Previewのパラメータに12を入れると結果が見られるようになる。
ViewをSaveし、コンテンツタイプのarticleのManage displayを調整する(Layout builderを利用する)。
Manage layoutでViewsブロックを追加し、referenceフィールドを削除する。
レイアウトをSaveして、記事を表示してみる。
レイアウトの微調整は必要だが、記事から必要なリンクに直接アクセスできることが確認できた。
逆引きのViewをarticle referenceとして設定する（委細省略）。
External referenceコンテンツタイプのManage displayでarticle同様にレイアウトビルダーの設定を行って、Group Membership Requestコンテンツを表示すると以下のようになる。
もちろん、Group Membership Requestを参照した記事をリファレンスをつけて作成すれば、この逆引きリストにその記事が出現することになる。
蛇足となるが、当サイトには大したアクセスはないものの、Drupal関連の記事には一定のアクセスが有り、役に立ったというメッセージを受け取ることもある。類似なユースケースを考えている人は意外と多く、それぞれの人がそれぞれの問題意識で書いた記事には意味があるのだ。