UnicodeのSmall Kana Extensionに関する文書

Small Kana Extension - Wikipedia に記載のない文書も追加。

• L2/10-468R2/N3987 Lunde, Ken (2011-02-09), Proposal to add two kana characters
• L2/16-334 Sim, Cheon Hyeong (2016-11-04), Hiragana and Katakana (Small Letters)
• L2/16-354 Yamaguchi, Ryusei (2016-11-07), Proposal to add Kana small letters
• L2/16-358R/N4803 Lunde, Ken (2016-11-22), L2/16-334 & L2/16-354 Feedback (small kana)
• L2/16-325 Moore, Lisa (2016-11-18), "C.14 Kana", UTC #149 Minutes
• L2/16-381 Suignard, Michel (2016-12-08), Additional repertoire for ISO/IEC 10646:2016 (5th ed.) Amendment 1.2
• L2/17-016 Moore, Lisa (2017-02-08), "Consensus 150-C18", UTC #150 Minutes
• N4523 The Japan National Body (2017-04-01), Japanese National Body Contribution on Small Kana Characters
• N4953 "M66.07i", Unconfirmed minutes of WG 2 meeting 66, 2018-03-23
• L2/17-353 Anderson, Deborah; Whistler, Ken (2017-10-02), "N.1. Small Kana Extension code block and code point changes", WG2 Consent Docket
• L2/17-362 Moore, Lisa (2018-02-02), "Consensus 153-C13", UTC #153 Minutes

UnicodeのSmall Kana Extensionに関する文書

Small Kana Extension - Wikipedia に記載のない文書も追加 - L2/10-468R2/N3987 Lunde, Ken (2011-02-09), Proposal to add two kana characters - L2/16-334 Sim, Cheon Hyeong (2016-11-04), Hiragana and Katakana (Small Letters) - L2/16-354 Yamaguchi, Ryusei (2016-11-07), Proposal to add Kana small letters - L2/16-358R/N4803 Lunde, Ken (2016-11-22), L2/16-334 & L2/16-354 Feedback (small kana) - L2/16-325 Moore, Lisa (2016-11-18), "C.14 Kana", UTC #149 Minutes - L2/16-381 Suignard, Michel (2016-12-08), Additional repertoire for ISO/IEC 10646:2016 (5th ed.) Amendment 1.2 - L2/17-016 Moore, Lisa (2017-02-08), "Consensus 150-C18", UTC #150 Minutes - N4523 The Japan National Body (2017-04-01), Japanese National Body Contribution on Small Kana Characters - N4953 "M66.07i", Unconfirmed minutes of WG 2 meeting 66, 2018-03-23 - L2/17-353 Anderson, Deborah; Whistler, Ken (2017-10-02), "N.1. Small Kana Extension code block and code point changes", WG2 Consent Docket - L2/17-362 Moore, Lisa (2018-02-02), "Consensus 153-C13", UTC #153 Minutes

キー番号と調号の決定に関するメモ

MIDIのノート番号は音のピッチ（音高）を表現している。ノート番号0はC_-1の音を表していて、番号が1増えると、音高は半音上がる。

このような、ピッチを使った音の表記は、しかし、キーを表現することができないという問題がある。ノート番号はピッチを表現しているため、異名同音のD♯、E♭、F𝄫を区別することはできない。

そこで、ここではピッチではなく、キーに対して番号を振る方法を考えてみる。五度圏を考えると、キーは次のように並んでいる：

... A𝄫 E𝄫 B𝄫 F♭ C♭ G♭ D♭ A♭ E♭ B♭ F C G D A E B F♯ C♯ G♯ D♯ A♯ E♯ B♯ F𝄪 C𝄪 G𝄪 ...

そこで、五度圏に並んだ順で、音名Cのキー番号を0とし、そこから完全5度上昇するごとに番号を1ずつ増やしたものを、キー番号とする。

ノート番号とキー番号の関係

オクターブの差や異名同音を無視して考えると、キー番号が1増えれば、音高は完全五度上昇、すなわち、7半音上昇する。逆に、音高が半音上昇すれば、キー番号は7増える。そして、ノート番号もキー番号も、12増えた場合は同音になる。

C_-1 のノート番号・キー番号がそれぞれ0となるように定めたので、ある音のノート番号とキー番号の間には

の関係があることになる。

調号の決定

五度圏を使ってキー番号を定義したことからも分かるが、キー番号は調号と直接的に対応している。長調においては、主音のキー番号が、そのまま調号におけるシャープ記号の数となる。（負数の場合は、フラット記号を付ける。）また、Aのキー番号が3であることから、短調では主音のキー番号から3を引けばシャープ記号の数になることがわかる。

調号の変化記号（シャープ記号またはフラット記号）の数は最大で7個なので、長調においては主音のキー番号をとなるように定める必要がある。同様に、短調においては主音のキー番号をの範囲で定める必要がある。従って、の場合（主音がC♭, G♭, D♭の場合）は長調に対して同主短調が記法上存在せず、の場合（主音がG♯, D♯, A♯の場合）は短調に対して同主長調が記法上存在しない。

このことから、同主調を必要とするならば、キー番号はの範囲にある12個（A♭, E♭, B♭, F, C, G, D, A, E, B, F♯, C♯）に決めるべきだとわかる。C♭ major, G♭ major, D♭ majorはそれぞれB major, F♯ major, C♯ majorが同主短調の存在する異名同音調となる。また、G♯ minor, D♯ minor, A♯ minorはそれぞれE♭ minor, B♭ minor, F minorが同主長調の存在する異名同音調となる。

調の主音のノート番号がとして、

と定めることで、調のキー番号をの範囲で決定できる。

2種類の悉曇文字ryaとUnicodeに関するメモ

悉曇文字のデータ化に関する諸問題 —大蔵経テキストデータベース化に伴う悉曇文字作成をめぐって—によれば、悉曇文字のryaは、大蔵経中に2種類の字体が使われている。一つは、raの切継上半体にyaを継いだもの、もう一つはraの切継上半体にyaの切継下半体を継いだものだ。しかし、Unicodeの規格上、ryaの字体をどのように実装するかということは明記されていない。これは、Unicodeの悉曇文字フォントを実装する上で問題になる。

このryaの字体の曖昧性は、悉曇文字だけの問題ではなく、デーヴァナーガリーやベンガル文字、カンナダ文字といった他のインド系文字にも存在しており、The Unicode Standard にも Alternative Forms of Cluster-Initial RA という題で言及されている。

Alternative Forms of Cluster-Initial RA. In addition to reph (rule R2) and eyelash (rule R5a), a cluster-initial RA may also take its nominal form while the following consonant takes a reduced form. This behavior is required by languages that make a morphological distinction between “reph on YA” and “RA with reduced YA”, such as Braj Bhasha. To trigger this behavior, a ZWJ is placed immediately before the virama to request a reduced form of the following consonant, while preventing the formation of reph, as shown in the third example below.

Similar, special rendering behavior of cluster-initial RA is noted in other scripts of India. See, for example, “Interaction of Repha and Ya-phalaa” in Section 12.2, Bengali (Bangla), “Reph” in Section 12.7, Telugu, and “Consonant Clusters Involving RA” in Section 12.8, Kannada.

https://www.unicode.org/versions/Unicode14.0.0/ch12.pdf#page=19&zoom=auto,-40,350

悉曇文字にも他のインド系文字の規則を応用すれば、raの切継上半体にyaを継いだもの（“reph on YA” に相当する）は ra + virama + ZWJ + ya、raの切継上半体にyaの切継下半体を継いだものは（“RA with reduced YA” に相当する）は ra + ZWJ + virama + ya として表現されるべきものであるように思われるが、悉曇文字に関しては、そのような挙動は明示的に記述されていないし、それを実装しているフォントもなさそうだ。

また、ZWJを使わない ra + virama + ya をどちらで表示するかという問題もある。

• ra + virama + ZWJ + ya <U+115A8 U+115BF U+200D U+115A7> 𑖨𑖿‍𑖧
• ra + ZWJ + virama + ya <U+115A8 U+200D U+115BF U+115A7> 𑖨‍𑖿𑖧
• ra + virama + ya <U+115A8 U+115BF U+115A7> 𑖨𑖿𑖧

TypeScriptでESNextを使う場合のSequelizeの書き方

TypeScriptでSequelizeを使おうとして、マニュアル（Manual | Sequelize）にある通りに、null assertionを使ってモデルのフィールドを定義してやると、うまく動かなかった。

import { DATEONLY, INTEGER, STRING, Model, Sequelize } from "sequelize";

export const sequelize = new Sequelize("sqlite::memory:");

export class User extends Model {
    id!: number;
    name!: string;
    birth!: string;
}

User.init({
    id: {
        type: INTEGER,
        primaryKey: true,
        autoIncrement: true,
    },
    name: {
        type: STRING,
        allowNull: false,
    },
    birth: {
        type: DATEONLY,
        allowNull: false,
    }
},
    { sequelize }
);

export async function main() {
    await sequelize.sync({ force: true });
    const user = await User.create({
        name: "Albert Einstein",
        birth: "1879-03-14"
    });
    console.log(user.name, user.birth);
}

main();

コンパイラオプションのターゲットがESNextに設定されている場合、上のコードを実行すると undefined undefined と出力される。これは、最新版のTypeScriptが TC39 Stage 3 提案のクラスフィールド に対応しており、ターゲットがESNextになっている場合は、useDefineForClassFieldsコンパイラオプションが有効になって、現行の意味論である「定義」意味論が使われるからだ。（「定義」意味論については、Babelプラグインの順序とallowDeclareFieldsの妙を参照してほしい。）

この問題は、以下のいずれかで解決する:

• useDefineForClassFieldsオプションをfalseに設定する。
• null assertion の代わりに declare プロパティ修飾子を使う。

export class User extends Model {
    declare id: number;
    declare name: string;
    declare birth: string;
}

新規のコードを書くときは declare 修飾子を使うようにした方がいいだろう。

参考文献

• The useDefineForClassFields Flag and The declare Property Modifier
• Babelプラグインの順序とallowDeclareFieldsの妙

IDSデータベースリスト

• CHISE-IDS Database
  • URL: https://gitlab.chise.org/CHISE/ids
• 漢字データベースプロジェクト IDS data
  • URL: https://github.com/cjkvi/cjkvi-ids
• hfhchan/ids
  • URL: https://github.com/hfhchan/ids
• Yet another IDS (Ideographic Description Sequences) lists with MIT license
  • URL: https://github.com/yi-bai/ids
• BabelStone Ideographic Description Sequences (IDS) for CJK Unified Ideographs
  • URL: https://babelstone.co.uk/CJK/index.html
  • Mirrored to: https://github.com/mandel59/babelstone-ids

macOS Big Sur では梵字が表示できる

support.apple.com

macOS Big Sur に組み込まれているフォント一覧を見ると、Noto Sans Siddhamがあることが分かる。これは悉曇文字、つまり寺院などで目にする梵字を収録したフォントだ。Font Bookやアプリのフォント一覧には表示されず、フォントフォールバック機能を介して使うことが前提になっているみたいだ。

フォントが入っていない人は https://github.com/googlefonts/noto-fonts/tree/main/hinted/ttf/NotoSansSiddham からフォントを入手できる。（NotoフォントはSIL Open Font Licenseの条件下で公開されている）

試しに、この記事にもいくつか梵字を載せておこう。（他にも 种子字 - 维基百科，自由的百科全书 にたくさん載っている。）

𑖭𑖾 saḥ

この字は東スポで記事になってた。（馬というか、勢至菩薩の種字で、午年の守り本尊なんだってさ） www.tokyo-sports.co.jp

𑖂 i

𑗘 i

𑗙 i

𑖮𑖳𑖽 hūṃ

𑖮𑗝𑖽 hūṃ

𑖏 kha

𑖭𑖿𑖝𑖿𑖪𑖽 stvaṃ

𑖮𑖿𑖨𑖱𑖾 hrīḥ

𑖮𑖿𑖮𑖳𑖼 hhūṃ

𑖮𑖿𑖦𑖿𑖦𑖯𑖼 hmmāṃ

梵字をよく知らないので、残念ながら書体のクオリティについてはコメントできない。

電子発行された生命保険料控除証明書を読む

皆さんは確定申告は済みましたか？ 私はまだです。2月中旬にやろうとしたけど、年末の携帯電話料金の引き落としの決済が完了していなかったんですよね……それで今日着手したんですけど、生命保険料控除証明書が必要になりました。10月ごろに郵送されて届いているらしい？ けど覚えていません。でも、電子発行も可能なみたいで、大丈夫そうでした。

で、電子発行したんですけど、ファイルの形式がXML。会計ソフトに金額を入力しなきゃいけないから読みたいと思ったんですけど、テキストエディタで開いて中をみてもタグ名がWCE00370みたいな識別子で、さっぱり項目が分かりません。

じゃあ、どうすれば読めるのか。方法を2つ見つけました。

方法その1 ＱＲコード付証明書等作成システムを使う

www.e-tax.nta.go.jp

ＱＲコード付証明書等作成システムに、生命保険料控除証明書のXMLファイルをアップロードすれば、PDFに変換されて、人間が読めるようになります。専門知識が要らないので、これが楽です。自分の環境はMacでFirefoxの推奨環境外ですけど、ふつうに使えました。

ただ、使うのはあまり難しくないにしても、リモートのサービスに依存しないと書類が読めないというのはちょっと不満があります。システムをオープンソースにしてほしい。

方法その2 XMLをウェブブラウザーで開く

XMLの基幹的な技術のひとつに、スタイルシートというものがあります。これは、XMLファイルを、人間が読める形に変換してくれる技術です。スタイルシートとしてはCSSが有名ですが、XMLのスタイルシートとしてはXSLというものが使われることが多いです。いまどきのWeb界隈はXMLを扱わないんでしょうが、ウェブブラウザーはXSLにもちゃんと対応しているので、開けるはずです。早速ブラウザーで開いてみましょう。

XMLファイルを開いた結果

……ひどいですね。これはFirefoxで表示されたエラー画面ですけど、Google Chromeではエラーさえ表示されず、真っ白な画面が表示されます。開発ツールのウェブコンソールを確認すると、セキュリティ関係のエラーが出ています。（ローカルに保存したXMLファイルが、リモートにあるスタイルシートを参照しているので、エラーになっています。）

このエラーを回避する手順は:

1. http://xml.e-tax.nta.go.jp/xsl/1.0/CMTEG800-001.xsl からスタイルシートをダウンロードする。
2. XMLファイル中のスタイルシートのパスを、ダウンロードしてきたスタイルシートを指すように書き換える。
3. 開発用ウェブサーバーを立ち上げ、XMLとスタイルシートをサーバーで提供する。
4. ウェブブラウザーから開発用ウェブサーバーにアクセスしてXMLファイルを開く。

たいへんですね。専門知識がないとできません。こんなハックじみた方法じゃないと開けないのでは、スタイルシートの意義がないんじゃないでしょうか。 ウェブを取り巻く環境が変わって、セキュリティの仕組みがウェブブラウザーに入ってきたことに、対応できていないんですね。

むすび

いかがでしたか？ この記事で皆さんもXMLに興味が湧いてきたんじゃないでしょうか。

ここには書いてない読み方として、XMLスキーマをダウンロードしてきて自力で解読するという方法も思いつきましたが、試そうとしたところ国税庁ホームページがメンテナンスに入ってしまったんで試せませんでした。あとで誰か試してみてください。

個人的には、そもそもスタイルシートがなくても読めるようにしておくべきなのでは？という点が不満に感じました。人間に読めることを考えないんだったらJSONでいいじゃんって思うし、だからみんなJSONを使うようになっちゃったんでしょうね。どうあるのが理想なんでしょうか。

小ネタ

XSLで変換された後のDOM

oncontextmenu="return false" はやめてください

■

mandel59.hateblo.jp

異体字セレクタを使うと「禰󠄀」の字を出せるよって話を前に書いたけど、アニメ公式の人物情報では「煉󠄁獄杏寿郎」の「煉󠄁」の字、「鬼舞辻󠄀無惨」の「辻󠄀」の字では異体字セレクタを使っていることがわかった。なんで禰󠄀の字だけフォントの変更で対応していたのかな？

MIDIデータを可視化するやつを作った

音楽でどういう音が鳴っているのかを知りたいと思ったので、MIDIデータを可視化するやつ、Midivisを作りました。

https://midivis.ryusei.dev/

Web MIDI APIが動くブラウザー（Google ChromeかMicrosoft Edge）で使うことができます。Mozilla FirefoxはWeb MIDI APIをサポートしていないので動きません。（プラグインを使えば動かせるかもしれませんが、確認していません。）

ノートは、横方向は半音、縦方向は完全4度の音程で並んでいます。ノートは横に12列並んでいるので、これだと同じ音が重複して表示されることになりますが、このように表示することで、コードのパターンが分かりやすくなります。たとえば、次の動画ではカノン進行 D-A-Bm-F♯m-G-D-G-A を演奏していますが、D→AやBm→F♯m、G→Dのような4度下行のパターンは下に、D→Gのような4度上行は上に、A→BmやF♯m→G、G→Aといった2度の上行は右に動いて感じるかと思います。そうすると、カノン進行全体ではパターンはどんどん右に動いていきますが、循環コードなので最後には元の配置に戻ります。こういう表現ができるのは音を重複して表示させているからで、これを横幅5列にして重複をなくしてしまうと、パターンが途切れてうまくアニメーションしなくなってしまいます。

www.youtube.com

（動画ではF♯はG♭と表示されていますが、Midivis最新版では音名の表示にシャープを使うよう切り替えることができます。）

おまけですが、コードネームを表示する機能もつけています。よく使われるコードは表示できると思いますが、対応していないコードは代替表示になります¹。異名同音も無視されるので、あくまでおまけ機能です。

---

1. たとえばC, D♭, G, Bから構成されるコードがC{1,m2,5,M7}のような表示になります。↩

「不愉快の峠」仮説

マイノリティとマジョリティの間には、不愉快の峠があるのではないかと思う。

マイノリティ文化がマジョリティ文化に認知される過程を考えると、情報の少ない接触初期段階では、どうしても表現が歪み、不正確になってしまう。理解の深い人間の目には、この不正確で偏見混じりの描写はいかにも不愉快なものに映る。偏見をなくせ、正しく理解しろと憤る。

しかし、マイノリティ文化を最初から正確に描写することはできない。マイノリティ文化は異文化で、まず、正確に表現するための語彙さえ、マジョリティ文化には存在していない。マジョリティ文化の人間にマイノリティのことを正確に説明しようとすればするだけ、迂遠な表現で浅薄な解釈を回避することになるし、正確だが無味な描写は、結局はマジョリティ文化においては無視されることになる。偏見を許さない態度を強めれば強めるだけ、マイノリティ文化への理解が進展しなくなってしまう。そうであるとすれば、マイノリティがマジョリティに認知され、受容されるためには、少なくとも当分は、不愉快を飲んで相手の好奇心を刺激する描写に甘んじるしかないのではないか。

このような法則が、マイノリティの種別を問わず、普遍的にあるのではなかろうか。これは仮説でしかないのだけれども、明らかに不条理な仮説だ、と思う。マイノリティが無視される社会と、マイノリティが偏見にさらされる社会は、どちらも苦しい。マジョリティからの能動的な攻撃に晒されないだけ、無視されていた方がマシだ、という考えもあるだろう。しかし、無視されている状態からは、理解は進むはずがない。異文化間の不和を解消するには、不愉快の峠を乗り越え、その先へ進むしかないはずだ。

では、偏見を受け入れるべきなのか。部分的にはそうだ。しかし、極力無害な偏見を選ぶことは、できるかもしれない。致命的でない、許容できる不愉快さの偏見の峠を見つければ、不愉快さを耐えた先で、より深い相互理解を得られた未来に至ることができるかもしれない。

漢字処理に使うデータベース・関連サイトまとめ

Unicode Character Database www.unicode.org

Ideographic Variation Database unicode.org

Adobe-Japan1 github.com

MJ文字情報一覧表 mojikiban.ipa.go.jp

漢字データベース kanji-database.sourceforge.net

GlyphWiki glyphwiki.org

萌典 www.moedict.tw

キーボード・ノートの対応

コンピューターのキーボードで音符を入力するとき、よくある方式だと

キー	ノート
Z	C3
S	C♯3
X	D3
D	D♯3
C	E3
V	F3
G	F♯3
B	G3
H	G♯3
N	A3
J	A♯3
M	B3
K	B♯3
,	C4

のように対応させていて、要はピアノの鍵盤と対応させているけど、ふつうに横は半音階で並べて

キー	ノート
Z	C3
X	C♯3
C	D3
V	D♯3
B	E3
A	F3
S	F♯3
D	G3
F	G♯3
G	A3
H	A♯3
J	B3
K	B♯3
E	C4

と割り当ててもいいのではないか。C4がEキーに当てられているのは、ベースの弦と同様に1段上が完全4度（5半音）になるように配置した結果で、実際にはQ, WキーにもB3, B♯3を重複して割り当てる。 こういうふうに、縦に完全4度、横に半音間隔で配列すると、左下のZキーから右上の0キーまでの音程は、3×5+9=24半音、ちょうど2オクターブになるので、割り当てに重複があっても、音域としては十分ではないかと思う。

竈門禰豆子の禰の字について

アニメ公式での竈門禰豆子の表記。禰を表示するのに中国語繁体字の字形を使っている。

どうやら、竈門禰豆子の禰の字について、しめすへんは正式には「ネ」の形という指定が存在しているようで、公式サイトでもわざわざフォントを変えて¹、禰のしめすへんを「ネ」に変えています。中国語のフォントでは、しめすへんは常用漢字かどうかに関わらず、いつでも「ネ」の形をしているからですね。²

日本語フォント 禰

中国語フォント 禰

この、フォントを変える手法での字形変更は昔から行われていますが、中国語のフォントを使うわけなので、日本語のフォントのしめすへんとは形が少し違う問題があります。

他の方法としては、異体字セレクタと呼ばれる仕組みを使うと禰󠄁（しめすへんが「示」）と禰󠄀（しめすへんが「ネ」）は区別して出せます。この方法で変えられる字形は、日本語フォントの中で用意されている、他の字になじんだ字形を使うことができるメリットがありますし、異体字がUnicodeで表現されているので、コピー&ペーストしても、意図通りの異体字を出すことができます。³一方で、テキストに異体字セレクタという特殊な文字が含まれることになるので、それを考慮しないソフトウェアが誤った処理をする可能性もあります。

まあ、異体字セレクタまで使って字形に拘るのは個人的にはちょっとこだわりすぎに感じてしまいますが、常用漢字外の難字であればなおさら、細かい字形の差が混乱を引き起こすということもあるかもしれず、まあ難しいですね……

（ここまで書き上げたあとでスラドの WebサイトやWebサービスで異体字セレクタは使われているか | スラド IT で取り上げられていることに気づきましたが、はてなブログで異体字セレクタを使って表示する例として載せることにします。）

---

1. 具体的には日本語のNoto Serif JPから繁体字中国語のNoto Serif TCに変更しています。↩

2. 新字形や国字標準字体の場合。↩

3. 表示に使うフォントが使う異体字セレクタに対応している必要があります。↩

メッセージとコンテキスト

note.com

安倍総理は、星野源さんのコンテンツの趣旨に敬意を払わずに、コンテクストと星野源さんが与えたルールを無視しました。

安倍総理の動画はただくつろいでいるだけで、歌っても踊ってもいない。コンテンツの趣旨、コンテキストを無視しているように見えるし、それが憤りに繋がっている。

しかし、いったいそんなコンテキストが本当にあったのだろうか。

星野源さんのインスタグラムには、バナナマンと大泉洋さんの動画も投稿されている。

www.instagram.com www.instagram.com

これらの動画は、何を伝えているだろうか。参加の形態は、必ずしも楽器の伴奏やコーラスやダンスに限らない、ということではないのか。俳優やお笑い芸人であり、音楽として関わることができなくとも、連帯してほしいということではないのか。これらの動画はニュースショーでも取り上げられていたし、これを見て、音楽でなくても大丈夫、というふうに思った人がいてもおかしくはない。

もちろん、個性的な大泉さんや、お笑い芸人のバナナマンだから、コンテキストを逸脱することが許されるのかもしれないし、星野源自身が投稿した動画であるから、彼らの動画が炎上するはずもない。一方で、一国の総理大臣が（追記：現状あまり職務を全うしていないと見なされている状況で）、彼らのように歌でも踊りでもない逸脱的メッセージを発することは、やはり問題があったのだとは思う。端的に言えば、安倍総理の動画はスベっていて、ムーブメントに水を差す結果になってしまった。

インターネットの時代、私たちは皆が皆異なるものを見ていて、コンテキストはほぼ共有されていない。この世界では、コンテキストを置き去りにして、メッセージだけが転送されてゆく。メッセージは原理的にコンテキストから乖離していく。この時代、正気でコミュニケーションをとろうとするのであれば、異文化への原理的無理解を理解し、ディスリスペクトという現象をリスペクトするべきだ。不快感に正直でありつつ、自分と異なる存在を理性的に認めるべきだ。そうでなければ、排外主義に堕してしまう。文化摩擦は、絶望というよりもチャンスであり、そういう時こそ感性を研ぎ澄まし、失われたコンテキストを集め、現象を見極めようとするべきだ。創造的な、あるいは破壊的な他者へのリスペクトが行われなければ、私たちは永遠にリスペクトされないだろう。