Drafts

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

cron で source コマンドを有効にする方法

結論

crontab に

SHELL=/bin/bash

と書くことで、シェルが bash に切り替わり、source コマンドが使えるようになる。

参考

Windows コマンドプロンプトから Python に変数を渡す

結論

  • スペースを含む変数の場合は " で囲う必要がある。
  • しかし、~(チルダ) を使って自分で設定した変数の "(ダブルクオート)は外せない
    • %変数の使い方に書かれているような特殊変数には効果あり。
    • だから、ちゃんと受け渡し先で解釈されるように試行錯誤。
  • " で囲った場合は \ は基本的には一つでOK
    • ただし、" 直前に \ を置く場合は \\ とする。
    • 例: set path="C:\hoge\fuga piyo\hogera\\"

以下テスト例

> set a="a a"
> python test.py %a% %a%

['test.py', 'a a', 'a a']

> python test.py %a %a
['test.py', 'a']

> set b="b\"
> python test.py %b% %b%
['test.py', 'b" b"']

> set c=c\
> python test.py %c% %c%
['test.py', 'c\\', 'c\\']

> set d=d\\
> python test.py %d% %d%
['test.py', 'd\\\\', 'd\\\\']

> set e=e e\\
> python test.py %e% %e%
['test.py', 'e', 'e\\\\', 'e', 'e\\\\']

> set f="f f\\"
> python test.py %f% %f%
['test.py', 'f f\\', 'f f\\']

> set g="g\\ g\\"
> python test.py %g% %g%
['test.py', 'g\\\\ g\\', 'g\\\\ g\\']

> set h="h\ h\\"
> python test.py %h% %h%
['test.py', 'h\\ h\\', 'h\\ h\\']

> python test.py %~h%
The following usage of the path operator in batch-parameter
substitution is invalid: %~h%

For valid formats type CALL /? or FOR /?

> set i="i i\"
> python test.py %i% %i%
['test.py', 'i i" i', 'i"']

test.py

import sys
print(sys.argv)

モバイルファーストというバズワードについて

きっと、ブログを書くような文字の入力はそのうち音声認識に置き換わる、だから一般人にはキーボードは不要になる…

そういう予想は支持するが、モバイルファーストという言葉で指されるのは、大抵「だから、うちのソリューションでモバイルやりましょう」と持っていくための煽りが多くて正直馬鹿にしていた。

例えば、Webサイト設計で「モバイルファースト」はなぜ重要なのか?allWebクリエイター塾 菊池 崇 先生が解説 - schoo(スクー) WEB-campus では

  • バイルの方が市場が広い
  • バイルの画面が小さい分、本当に重要なことにフォーカスできる
  • バイルの機能が様々な新しいイノベーションの土台になる

とモバイルファーストのメリットが説明されている。

1つ目はわかる。2つ目はもともとZenの国日本がなんでYahooのトップ画面みたいなん好むねんみたいなデザインの問題の話であって、もし広い画面でも「本当に重要なことにフォーカス」できないならそれはデザインが悪い。3つ目はモバイルがもつセンサー機能を活用したウェブサイトが例に挙げられているが、そんなものはUXのデザインの時点で出てくる話であって、ウェブサイト設計の段階で出てくる話ではない。

…という具合に、全く学ぶところが見つからなかったモバイルファーストという概念だが、最近軽量な CSSフレームワークに乗り換えて開発することが多く、その Milligram | A minimalist CSS framework. になるほどな文言をみつけた。

The Mobile First is the design strategy that takes priority development for mobile devices like smartphones and tablets. It means all styles outside of a media queries apply to all devices, then larger screens are targeted for enhancement. This prevents small devices from having to parse tons of unused CSS.

「(前略)全メディアに共通するスタイルがまず適用されて、大きなスクリーンは拡張として対象にされる。小さいデバイスが使わない大量のCSSを解析するの無駄だろう」。

つまり、モバイルにもデスクトップにも対応しますって言ったときに、前者の方が非力なんだから後者の方が重くてよい。そうならばモバイルに最適化した設計をして、それをデスクトップに拡張する CSS を追加で書けという話になる。

skeleton-frameworkとかでもなんでリストの間こんなに幅が開いているんだろうと思ったけど、実際モバイルで操作すると、リストがリンクになってた場合、リストが詰まっていると指で押す場所が難しくなるのだ。デスクトップではもうすこし狭めに見せたいということなら、それを追加で書けばいいだろう。

これはまあウェブデザインだけじゃなくていろんな制度設計にも言えるけれど、弱くて人数の多い対象者を第一のモデルにしてデザインすることでデザインの想定と不一致があった場合に背負うユーザのコストの負荷を全体で最小化するというのは良いストラテジーで、それをウェブに適用したら「モバイルファースト」になるんだよね。

参考(これを書くにあたって読んだもの、というだけ):

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

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

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

効用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

返本制度、Amazon、POD。

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

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

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

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

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

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

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

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

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

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

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

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

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

その他参考:

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

現代のブラクラ

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

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

参考: