Drafts

@cm3 の草稿置場 / 少々Wikiっぽく使っているので中身は適宜追記修正されます。

Annotation Properties の Semantics

2009-09-07 に書かれた Dublin Core in OWL 2 という文書には

And annotation properties allow for both because they have no semantic relevance for reasoning.

というくだりがあって、明確に Literal しか目的語に取らない Data Properties と、目的語に任意の individual を取る Object Properties に対し、どっちとるかわからない場合に押し込める先としての (Dirty?) Hack が頭にあった。

で、先日書いた「意味」の認識を更新し続けるためのフレームワークを書いた論文にも domain がハッキリしない述語に関して owl2 の semantics を引いて注を加えたのだが、そこで引いたOWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition)の中に以下のくだりを見つけてしまった。

For annotations properties note that annotations are not "semantic-free" under the OWL 2 RDF-Based Semantics. Just like every other triple or set of triples occurring in an RDF graph, an annotation is assigned a truth value by any given OWL 2 RDF-Based interpretation. Hence, although annotations are meant to be "semantically weak", i.e., their formal meaning does not significantly exceed that originating from the RDF Semantics specification, adding an annotation may still change the meaning of an ontology. A similar discussion holds for statements that are built from ontology properties, such as owl:imports, which are used to define relationships between two ontologies.

確かに "semantically weak" だとは認めているが、annotation property の値が主語の意味を変えうると書いている（この文脈では主語は TBox の中の語彙が想定されている）。そりゃ、元の文脈で、X は ObjectProperty or DataProperty ∧ どちらも意味を持つ → X は意味を持つ、ことが当然推論されるので、"semantic-free" だとは思っていないが、じゃあそもそも "semantically weak" だとか議論する意味はどこにあったのだろうと疑問になる。OWL 意味論で拡張される部分が無いと言いたいのだろうか。

ここらへんを手がかりに Annotation Properties の Semantics を考えることで、「どっちとるかわからない場合に押し込める」というのはどのくらい正しいのか検討してみたい。

ウェブのオントロジー言語OWL -- ウェブに存在するものとその関係の定義では、

プロパティには、個体（オブジェクト）を別の個体（オブジェクト）と関連づける個体値型プロパティと、オブジェクトをデータ型値に結びつけるデータ値型プロパティがあります。両者はそれぞれowl:ObjectProperty要素、owl:DatatypeProperty要素で定義します。また、特別なプロパティとしてオントロジーの管理情報を記述するowl:OntologyProperty、オントロジーの注釈に用いるowl:AnnotationPropertyがあります。OWLでのプロパティは、必ずこの4つのどれかのタイプを持たなければなりません（個体の記述に用いるのは個体値型もしくはデータ値型のみ）。

と書かれている。Dublin Core も個々の書誌情報の記述＝個体の記述なのだから、Annotaion Properties を用いるのは正しくないことになる。ところでこの制約はどこから来ているのか。

OWL 2 Web Ontology Language New Features and Rationale の punningあたりを見ていると、これは OWL 1 の制約であって、OWL 2 ではその制約が緩められている。さっきの制約を記述したページはとても古く、おそらく OWL 2 の変更を反映していないと考えられる。

ちなみに、Annotation Properties の特殊性は、OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition) #5.5 Annotation Properties にも "IRIs from the reserved vocabulary other than the ones listed above must not be used to identify annotation properties in an OWL 2 DL ontology." という形で、OWL 2 DL においては 9つの Annotation Properties しか許容されないと書いている。これは、これら9つしか OWL 2 DL において意味論がハッキリしていないからというだけであって、その Annotation Property を用いる対象自体は"Annotation properties can be used to provide an annotation for an ontology, axiom, or an IRI." と書いているので個体に対して用いるのもアリだ。

だって、この9つというのは、

  • The rdfs:label annotation property can be used to provide an IRI with a human-readable label.
  • The rdfs:comment annotation property can be used to provide an IRI with a human-readable comment.
  • The rdfs:seeAlso annotation property can be used to provide an IRI with another IRI such that the latter provides additional information about the former.
  • The rdfs:isDefinedBy annotation property can be used to provide an IRI with another IRI such that the latter provides information about the definition of the former; the way in which this information is provided is not described by this specification.
  • An annotation with the owl:deprecated annotation property and the value equal to "true"^^xsd:boolean can be used to specify that an IRI is deprecated.
  • The owl:versionInfo annotation property can be used to provide an IRI with a string that describes the IRI's version.
  • The owl:priorVersion annotation property is described in more detail in Section 3.5.
  • The owl:backwardCompatibleWith annotation property is described in more detail in Section 3.5.
  • The owl:incompatibleWith annotation property is described in more detail in Section 3.5.

なんだから、rdfs:label が個体に用いれないとなったら大変だ。

あと、 OWL 2 の RDF-Based Semanticsにおいて、Table 5.1 と 5.2 を見る限り、owl:AnnotationProperty の domain と range は IOAP に等しく、その外延が IR × IR であり、IR は空集合を除くすべての要素を指すわけだから、 domain と range の観点からしていえば "semantic-free" だ。一方で、semantics は domain と range にだけ依存する（≒型にのみ依存する）わけではないので、用法としてどんなIRIに用いても意味があるかは微妙。

そして、この domain や range の面からは全く制約できないこと、部分集合に対してしか意味論をキッチリ定義できないこと、あたりを指して "semantically weak" と言わざるを得ないのだと思う。一般的にはこれはもっとポジティブに「人間にとって"意味"があるが、機械にとって"意味"がない」という認識がなされていると思うが、つまり人間にとってどう意味があるか定式化できないんでしょう。

ここまで見てくると、Annotation Properties は 弱い Semantics を有していて、それは domain や range で規定されるようなものではなくて、推論機構によってはちゃんと規定された Semantics を有している Annotation Properties は9つだけに限られていたりする。そうすると、目的語が何かわからないから Dublin Core のような語彙を Annotation Property にしておくといのは Dirty Hack くさい（そういう domain や range の議論の外に Annotation Properties の Semantics の核があるから）。一方で、title が常にリテラル値を取ると決めたならば、rdfs:label の subproperty にしてしまえばいいのだ。元の"Dublin Core in OWL 2"ではdcterms:titleがリテラル値以外を取るかもしれないなんて書かれているが、2012年更新版では明確にリテラル値だと書かれているのだし。

もし、リテラルかindividualかどちらを取るかわからない述語があれば、単に Property だとだけ定義しておけばいいし、その Semantics を明確に定義したければ、Object Property にしておいて、リテラル値を目的語に取りたいときには、

A 今議論している述語 [rdfs:label リテラル値].

のように空ノードを用いて individual 化すればよいのではないかと思う。こうして置くことには意義があり、SPARQLでクエリを書くときに、（間に挟まるのが Named か Non-nammed Individual かという違いはあれど）リテラル値 は同じ位置に来るため、SequencePath を用いてシンプルに書くことができる。なによりモデル構造が統一されるのは気持ちいいではないか（笑）なんにせよ、range の曖昧性は Annotation Properties を採用する理由にしてはならないと思う。

日本語でこれを書いてもこの議論に興味と見識がある人はかなり限られると思うけれど、変なところがあったらぜひ忌憚なくご指摘ください。

最近ブログを更新していないことの理由と効用

■ - Drafts で書いていた Markdown container のエディタとＣＭＳのα版が完成したため、つまり強力なチラシの裏を手に入れたため、ブログの更新頻度がガクッと下がった。実際に書いてみると、一部の実装は Python で行い、ほとんどの実装を Windows のコマンドスクリプトで書くという予想外の実装になった。使い勝手を上げるためにどうしてもＯＳと密結合してしまうのだ。レジストリもいじっている。今後は Linux や Mac でも同様のことができるか確かめたい。

ちなみに、もともと１ファイルで持ち運びたいという欲求で設計したものだったが、記事の中でも書いているようにエディタの設計にあたって、一旦zipを解凍して取り扱うようにしたこともあり、現在は非圧縮版のみで環境を整えている。つまりフォルダ単位で記事を管理しているだけである。

今、鋭意整えているのはメタデータの仕様であり、container.xml ではなく、metadata.json を META-INF に入れている。発想のもととなったTextBundle とかも json でメタデータを持っており、なおかつ拡張性などについても設計しているのでそういう部分を参考にしつつ、Dublin Core のようなもっと広い文脈のものも考慮に入れている。

効用

  • 余計なことをブログに書くことが少なくなったのではないか
    • 人に読まれることを前提に書かなくなったので、余計な事に関する記事を作成する丁寧さが減った
      • それはそういう方面での学びを放棄することでもあるので一長一短だけれど
  • もともと手元にあった別のチラシの裏システムが効率的になった
    • このブログに書くような、メモと記事の間のような立場の書き物を置く場所ができたので、メモのところに肥大なまとまりが蓄積されてしまって年間１万行以上のメモが産出されて全文検索以外に参照する術がないという状況を脱した。そのメモはあとで自分が読んでも分からないこともあるレベルだったので、このブログのように少なくとも僕が読めば１年前の記事でもわかるレベルにはなった。
  • もう少し公開したら他の人の役に立ちそうなことも公開しなくなってしまった。これはデメリットかもね。
    • まあそれも熟成したら公開するから良いのではないか。

■

駄文

本の出版まわりについて考えるというのは私について厄介な事柄だ。

知識流通について考えるという意味では専門上無視できない事柄であり、一方で、私自身が漫画喫茶や図書館ばかりで本を読む人なので、所謂本好きからは敵視されかねない人種だ。あと、読んでいる文字数という意味では、ウェブの記事≒論文ＰＤＦ＞＞＞越えられない壁＞＞＞紙の本＞電子書籍くらいの順序だ。さらに、図書館情報学的な指導は受けていない。

漫画喫茶にお金を払っていることからも推測してもらえる通り、別に本にお金を払うのが厭なのではない。なんなら、図書館に本の ～5割 の金銭を任意で納入する制度でもあれば、納入する（割合は読む人の数や読んだ後の価値判断で決められてよい。想定上限が5割なのは、物としての所有の権利を放棄しているので。まぁ制度としては下限・上限なしで良いと思うけれど、本の返却時に自動返却機で１クリック増えるようなのを想定している＝メインの選択肢は固定だと便利）。でも、基本的には知識は社会のインフラとして万人に十分にアクセスできるようになるべきだとは思っている。そもそも図書館の自由に関する宣言にある思想とか考えると、特段ぶっとんだ考え方ではないと思っている。そういや、ＮＹのメトロポリタンに行った時も、無料で入って見て回ったうえで、最後に規定料金満額（そこも本来任意額）払った。比較的みすぼらしい恰好をした私が入館締切間際に満額払うのを係員は２度ほど止めてくれたけれど。

一方で、共産党嫌いの私としては、ちゃんとサステイナブルに本による知識流通が維持できるように出版・印刷・流通について責任ある意見を有したいとも思っている。Facebookにでもこの記事を投稿したら、kskさんや図書館系の人たちから暖かく厳しい突っ込みが入るかもしれない。それはそれでありがたいことだけれど、まずは未熟な自分の考えを整理するために駄文カテゴリでここに書く。

表現創作と経済との整合性という問題

機能だけの本というのは存在しないし、どこからが機能でどこからが cosmetic な美なのかということにハッキリとした境界は無い。

たとえば、東京に居たときは毎年、印刷博物館の「世界のブックデザイン」展に行っていたが、そこでも一見単に芸術的なものもあれば、分かりやすいインフォグラフィックを表彰されているものもあり、様々だ。それらを眺めていると美は機能であり、機能的なものは美しいという関係が体感できると思う。

大学４年で「デザイン」に触れたとき、どの先生も初めに口にしたのはこのフレーズである。

「私たちは『デザイン』というと美術的なものを想像すると思いますが、この授業で扱うのは工学的設計としてのデザインです。」

しかし、そう前置きされて始まった授業でも Good Design Award の話になると用と美の関係は、「美ではなくて用の話」と片付けられなくなってくる。ちなみにこの用と美の関係に初めに気づかせてくれたのは工芸を「用の美」という端的な表現で紹介してくれた 中学校の先生で、彼の授業で作った木工のティッシュケースは15年経った今でも現役で使っている。

さて、本の話に戻って、日本語で「装丁」というと中身のことは指さず外形だけを指すことが多いので、最も「美」要素の大きいところだが、逆に「用」要素の大きい例として、文字の折り返し、所謂字切りが挙げられる。

参考: 改行の字切り：Talking Design：So-netブログ

ウェブ上でのレスポンシブデザインでは言うまでもないが、電子出版系は字切りに弱い。たとえば、著者・編集者・出版社の方へ | NextPublishingで、「以下の点は伝統的出版に比べて劣ります。」の筆頭に挙げられているのが「字切り、縦組・横組混在などの複雑なレイアウト（ビジュアルな雑誌など）」だ。字切りが不味いと読みにくい。でも、読めないことは無い。私は学術系の出版で字切り部分にお金をかける必要性はあまり無いと感じている。論文ＰＤＦでは最低限の字切り考慮（つまり、PDFの元となる Word や LaTeX が対応する範囲）しか為されていないし、それで特段の不便を感じないからだ。でも、文系の先生方はそこに拘る先生も少なくないし「若手にそういう編集の知識を学ばせてボランタリーに学会誌の編集作業をさせてはどうか」という意見を仰る先生も居る。それは趣味ならよいが学者の仕事ではないと個人的には思うし、その部分を編集知識のある人間に任せるお金が捻出できないような活動ならばコストダウンのために諦めるべき部分だろう*1。LaTeX や Markdown みたいな形式で論文を書く場合は、そういう cosmetic な部分は言語処理を用いて自動で行える未来も来るだろう。

要はその表現の発信者と消費者の流通全体を見たときに、どのくらい現状の経済と整合性があるかという視点が、本を出版する多くの学者に欠如していると感じている。一方、コストダウンだけを図っていてもその経済は縮小していくだけなので、GRAPHICATION2, No.1, 2015 - Draftsの p.9 について触れたように企画力でそこを補うというのは重要になる。大学出版会はそういうとこちゃんとしてて、「理事会で採択された企画については、企画意図や読者対象に応じて十分な編集を加えた上、出版されます。編集経過を経ない印刷請負のような形式は認められません」みたいな方針になっている。各学会や研究所単位で出版する出版物に関して、大学出版会を経られないような内容なのにお金だけやたらかけている場合はなんか特段の理由が存在すべきだ。

そうでなきゃ、美を切り捨てて、最低限の用を取り、コストダウンを図るべきだ。

関連しそうなそうでないような参考:

10年ほど前、某美大で「自腹でアートを買う」という授業を行った。「画集」購入は「反則」として禁止。その結果「アートには金を出して買う価値のあるものがない」「展覧会には金を出すが、基本は無料で見るもの」という者が続出した。「では自分の作品は？」と聞くと「自分の作品は例外」となった。

美大生の一人はアート作品を買いたくない理由として、「ウザクて自分の部屋に飾りたくない」と言った。「何かの表現であるアート作品は、生活を共にするのに鬱陶しい」。

そして彼等の多くは「アート作品」の代わりに、家具や、フィギュアや、カレイドスコープやらを買ってきた。「こっちの方がいわゆるアート作品などより、自分にとってはアートです」。

アーティストになろうとしている（多くはなろうとしていないかもしれないが）美大生のこの自己矛盾。しかしまた多くのアーティストもまた、熱心なコレクターではないのも確かだろう。

授業の最後のあたりで「自分の作品を自分で買いたいと思う？」と聞く。「微妙」という答えが帰ってきた。

from 美大生はアート作品を買わない。 - Togetterまとめ

返本制度、Amazon、ＰＯＤ。

vs Amazon という形でよく言われる日本の出版業界の保守的な態度も問題である。既に上で NextPublishing の紹介をしたが、

● 現状の出版事業では経済的に困難な専門書（小部数）の出版を実現
● 優秀な個人や組織が保有する多数の専門知識の流通を促進
● デジタルによる編集・制作・流通手法なので、圧倒的な低コスト・短期間で発行できる。
● 電子書籍と印刷書籍が同じ編集プロセスで発行できる。
● 電子書籍の基本フォーマットはEPUB を採用しているので、汎用性・発展性がある
● POD を利用しているので、品切れがなく、末長く販売できる。
● プリントオンデマンドは、Amazon の仕組みをそのまま利用、注文に応じて印刷・製本して出荷
● 電子書店はKindle、kobo、iBooks Store、紀伊国屋書店Kinoppy などで販売

from 出版社にとってのプリントオンデマンド | JAGAT

というメリットを実現するのに、ＰＯＤのような新たな技術、およびビジネス形態にはもっと日本の出版業界は力を入れるべきだと思う。とは言ってもニーズの無いところにそれを推し進めても成立しないので、要はテレビ番組と同じくメディア全般に言えることだが「消費者が保守的すぎる」のだ。

たった4,980円で紙の書籍が出版できる！超格安出版ベンチャー「MyISBN」は Amazon の ＰＯＤの上に乗っかってて、それがMyISBNがキナ臭い－注意しておきたい不明瞭なビジネスモデルと言われたり、「MyISBN」が”キナ臭い”んだってさ！と反論されたり、2013年の時点でしているのだが、MyISBN は Amazon の POD のめんどくささを代行する仕事と出版社としての ISBN 付与をマージン取ってやってると見るのが正しいと思う。つまり、2011年の深津さんのブログ記事日本のAmazonでオンデマンド印刷が始まった件（そして注文してみた） | fladdictの末尾で提唱されている「現状は出版コードをもっている会社しかオンデマンド申請できないのだとか。 だから同人誌、自費出版は難しい。 でもこれなら、オンデマンドを仲介するだけの出版社を作るってのは面白いかもしれないなぁ」というアイデアの実現がコアなのだ。

そして著者のワリの悪さは主に Amazon に起因しているので、MyISBN が批判されるのは俺も違うなぁと思う。

既存の出版社は印税を１０％しかはらわないかわりに、編集・校正や、プロモーションなどの営業努力をしてくれる。それらのサポートがなく完全自費出版なのに、印税が１０％ではしかたない。

ここでの卸率は 70% で計算されているが、アマゾンと出版社、容赦ない取次「外し」加速…問われる取次の存在意義、存亡の危機か | ビジネスジャーナルの記事では、

セミナー出席社に限定して、1カ月以内に申し込めば、通常60％である出版社からアマゾンへの卸率（編注：1000円の書籍であれば600円でアマゾンに卸すという意味）を66％にするというのです

というのがセンセーショナルに書かれているので、そりゃ Amazon がそんだけ持ってきゃぁ、上に乗っかるビジネスはそのくらい著者にとって不合理に見える価格設定になりますわな、と思う。

じゃあ Amazon が悪いのかと言われれば、それだけの仕事してるわけで。でも、この部分握られ過ぎているのは国単位の政策で考えれば不味いと思う。こんなこと言うと「日本版 Amazon を」なんて言う人たちが現れるのだけれど、即座に「日本版 Google ってフレーズに聞き覚えあります？」と返さねばなるまい。

参考: 記者のつぶやき - 情報大航海プロジェクトへの批判と経産省の回答：ITpro

もう少し根本に立ち返って、知識流通にとっての本の役割とか考えたら何か解はあるのかな。

その他参考:

*1:まあ京大に出入りするような教授はマルクスの分業による疎外の批判でも念頭にあるのかもしれないが（…実はそこまで深く考えてないだろうと思っている）、（万一そうなら）そこはベバッジ的な視点でも補って考えてほしい。分業の問題じゃなくて、美を遍在させたいという意識から来ているのかもしれないが、それなら支倉の鼻紙にでも学んで、まず低コストにその美が提供できる素地を作ることが先だろうよ。

現代のブラクラ

タブを閉じるイベントを検知して「閉じていいですか？」みたいに聞いてくれる機能はウェブアプリで便利なんだけど、それを悪用したブラクラに先日嵌った。つまり、閉じても閉じなくてもその閉じようとした行為をトリガーにしてタブが無限に増殖するというブラクラ。

Chrome で嵌ったので、Chrome での対処法は「ナビゲーションの確認」が閉じたカンマ秒の間に［Shift］＋［Esc］キーを押して タスクマネージャを立ち上げて該当のウィンドウを落とす。Windows 付属のタスクマネージャでは落とせなくて、かなり苦労した。

参考:

Docker 再勉強

Virtuoso を Docker で運用 - Drafts を1年前にやってたのだが、Docker が進化しすぎて全然通用しなくなっていたので再勉強中。

Docker Toolboxという形でOpenStackみたいにいくつかのコンポーネントにプロジェクトが分かれた模様。最低限は Engine と Machine。ほんとは GUI の Kitematic も欲しいけれど、Linux Support はまだ初期段階ということで今回は見送り。

Docker Engine をインストール

docker.io ではなく docker-engine をインストールする。Installation on Ubuntu にいろいろ書いてある。

Docker Engine をアップグレード

sudo apt-get upgrade docker-engine

でできました 1.11から1.12にアップグレード。

Docker Machine をインストール

Install Machine にやりかた書いてあるけど、パーミッションの関係で動かなかったので、

wget https://github.com/docker/machine/releases/download/v0.7.0/docker-machine-`uname -s`-`uname -m`
sudo cp docker-machine-Linux-x86_64 /usr/local/bin/docker-machine
sudo chmod +x /usr/local/bin/docker-machine

とやった。つまりは、適切なバイナリ持ってきて適切な場所に置いて、実行権限つけてるだけ。

学ぶ

Linux — Docker-docs-ja 1.11.0 ドキュメント という日本語ドキュメントがあって、45分のチュートリアルがある。これを今やっている。

その他参考

  • Dockerでホストを乗っ取られた - Qiita 前もセキュリティ的に色々考えて面倒だった。そりゃ分かってる人が読めば当然のことなんだけど、Docker は使う側がセキュリティのことあれこれ考える必要が大きいのは現状の問題だと思う。

WordPressのカスタムメニューでただのテキストを挿入する方法

■

駄文 ただの日記

二日酔いがまだ抜けきりません。三日目です。純粋アルコール換算量 10ml まで大丈夫だったはずなのですが、8ml程度で半日つぶれることを覚悟したのに、36時間たってもまだ体がだるいです。あのちゃんとしたシャンパンとウイスキーはなかなか価値だったのですが、舐める程度でやめるべきでした。アセトアルデヒドを分解するALDH2遺伝子が無いのは確定なのですが、その場合ADH1B遺伝子の有無にかかわらず飲めないとされるもので、僕はあとの苦しみを考えなければ３，４時間ならば並みの日本人並みには飲めるので、よくわかりません。まぁこんな事実公表して飲まされたところで飲ます側はあとの責任を取ってくれるわけでもないので「飲めません」と基本的には断ってます。飲んでいるうちに強くなるというルートがあるともいわれていて、それが消えたため、10ml の限界が下がってしまったのかもしれません。これからは、改めて、舐める感じの喫酒を極めていきたいと思います。

その酒の席は料理持ち込みだったので、新味バターソースのマカロニアスパラサラダ by かおりん♪♡を作っていきました、結構好評で良かった。１時間くらい放置しただけでちょっと乾いた感じになってしまったので、レンチンすればよかった。たぶん脂分が時間の経過で固くなるんだと思う。

あと、その場でも料理をしたのですが、トマトを拙く切っているときに、Ｈさんが「お、上手いな」的なことをおっしゃって、僕が照れてしまって切り方を間違えたりしつつ、喜んで切り続けているのを見て、Ｙさんが「さすが褒められて育った世代だな！」とおっしゃってた。Ｙさんは昔アメフトか何かやってらっしゃって、そういうスポーツにおける発破による奮起みたいなのと対照的に見え、それを世代差として受け取ったのだと思う。もちろん世代差も大きいが、僕たちの世代は個人差が大きいと僕は思っている。

むしろ、Ｈさんのことを「人のことを良く見ていて、ちゃんと評価してくれるので、やる気が出る」とＹさんと似た世代の方が評していたので、叱咤激励で頑張れないことを（これも規範っていうの？要はちょっと広範に力を持つ世間感覚）恥ずかしいというような風潮が、実はどの世代でもある程度あった個人差を抑圧してただけなんじゃないかなとさえ思う。

これはスポ根的なものを批判してるんじゃなくて、むしろ逆。彼らは叱咤激励に愛を感じて頑張れてたわけで、スポ根漫画も多くの場合、その世界だけに閉じていれば問題が無い。叱咤をコミュニケーション手段として用いることは、弊害が大きかったからこの数十年で否定されてきているだけで、それ自体が常に問題になるわけではないし、初等教育のような場で用いることは危ないということが共有されるのは妥当だとしても、スポ根漫画的表現が非難されたら馬鹿らしい話だと思う。

美味しいお酒も、褒めも、叱咤激励も、ちゃんと僕というレセプターや社会環境をひっくるめて個々アトミックなコミュニケーションとして成立していて、そこに齟齬があった場合は僕はできるだけ自分でなんとかしてるつもりだし、そのコミュニケーションに規範的なものが持ち込まれると、それが自分に味方するモノであったとしても特に歓迎してないです。その場の全員が共有してそうだと確信した場合のみ歓迎する。

その他関連：