文芸船

Web技術雑感1

新規格はファットフォン

 最近のスマートフォンの流行にHTML5を絡めた動きが活発だ。その一方でスマートフォンは早期解約等の消費者問題も非常に多いという。従前の携帯サイトは貧弱な環境を前提に設計されており、PCサイトと比べて情報量や娯楽の複雑さという点では明らかに劣っていた。

 だが裏を返すと、携帯サイトの方が余計な情報が少なく情報が厳選されていた面もある。視力の弱い知人に言わせると、最近の美麗な文字の細かいサイトは全体のレイアウトが見渡せないほど拡大しないと使えないようだ。情報の厳選と目的情報へのアクセスの総合的な容易さから考えれば、スマートフォンはスマートどころか、むしろファットフォンと言って良いかもしれない。

電子記録の永続性

 東日本大震災の発生から3ヶ月が経過した。報道によると約1,100年前に発生した貞観津波の記録が菅原道真らによって残されていたそうだ。研究等の反省は他に譲るとして、1,100年前の記録が残っていたことは驚異的だ。この他にも古い地震の記録が伊勢神宮などでも続々と見直されているという。

 翻って現代の記録を見ると、まず1960年代から1980年代の記録は酸性紙で劣化しやすいという。デジタルデータはソフトが無ければ読むことすら困難で、安易なファイル名で大量に蓄積されたデータは見返すことも難しい。HTMLはTEXTである分だけワープロソフトのファイルよりはましだろうが、HTML5のリッチな情報環境は遠い未来への永続性を低下させるかもしれない。現代の情報が菅原道真の記録よりも短命なら寂しい話だ。

IT技術の幻想

 年始にネット通販のおせちで、写真と中身が違ったり商品が正月に届かないなどの問題が発生した。Webサービスの諸問題はIT技術に主因があるものより門外漢でも想像可能な内容が案外と多い。今回も5割引という数字だけで消費者も不審を抱いて良さそうなものだ。ITは主に情報管理の効率化であり、音楽CDのようにデータ転送で置換できない限り、原料原価は低下するはずがない。お惣菜に支払う代金の半分以上が情報管理料だとは思っていないだろうに不思議なことだ。

 魚の漁獲には漁船の燃料費が必要だし、切身を造るには人件費が必要で尾や中骨などの産業廃棄物も発生する。私は大学入学以来、漁業や食品加工に携わってきたせいか直感的にわかるが、そういった内容を想像出来ない人が現場で働いていたはずの高齢者にも意外に多い。魚が切身で泳いでいると思っている子供の話があったが、コスト感覚はさほど大人も変わらないように思える。

構造を読む力

 構造記述の手段としてのHTMLの位置づけについてHTML5の策定作業が始まってから議論が増えたが、構造と視覚表現の分離とが難しい理由はHTMLやIT技術レベルの問題ではなく、社会全体で構造を読む力を持つ人の少なさが原因だと思う。

 例えば仕事が増えたとき、仕事の手順を見直して根本的に改善するのではなく個人の頑張りで対応しようとしがちだと思う。つまり問題の構造を解決せず、末端の細部のみを変えて逃げる考え方である。2ちゃんねるの政治談議を見ていても、発言者や右翼左翼という議論を求める人が多く議論に道筋の無い人がかなり多い。これも問題の構造より、その問題に付随するレッテルや属性で判断しようとする流れだと思う。要はHTMLに限らず、課題を構造と個々の属性に分解して考える力のある人は意外なほど少ないのだ。だから自然と構造記述手段としてのHTMLでは支持されにくいのだ。

文章の喪失

 温泉の入浴感想サイトはblog形式よりゼロから構築しているサイトが割と多く、CSSもろくに使わない前時代的なサイトもあるが、有名な温泉は5年前の感想でも十分に参考になる。一方、流行り物のサイトでは「blogよりtwitterの時代」といった論調を見かける。

 Webサイトは、自作のホームページ、簡易日記サイト、blog、twitterと技術的には進化してきた。だが中身の文章は次第に衰えており、twitterに至っては短すぎて文章は書けず単文のみだ。更にtwitterは情報の速さが売りだが、速さが肝心な情報とは即座に価値を喪う情報でもある。Web上に情報量(バイト数)は増えているが、その多くは瞬時に消費されて無価値になる情報だ。簡易なシステムは鮮度の高い情報を増やしたが、永続性のある体系だった説明を生む土壌を減少させている。Webシステムの利便性は私たちに言語表現の機会を与えながら、同時に言語表現の能力を簒奪している。

煩雑なダッシュ記号

 文章中の独白や引用にダッシュ(dash)を使うことがあるので調べてみたところ、ハイフン(Hyphen)など類似の記号が複数あり、各々の使う場面に違いがあってかなり厄介だ。とりあえず調べた内容を一覧表にまとめてみた。

ハイフン・ダッシュ一覧表
名称Unicode記号文字参照用法
18文字
Hyphen-MinusU+002D--単語を繋げる、マイナス記号
Soft HyphenU+00AD­­単語内で改行する(通常は非表示)
Modifier Letter Minus SignU+02D7˗˗修飾文字マイナス記号
HyphenU+2010‐単語を繋げる
Non-Breaking HyphenU+2011‑折り返さないハイフン
Figure DashU+2012‒数値の列記
En DashU+2013–空間や時間の範囲(欧文)
Em DashU+2014—副題、引用(欧文。和文は2つ連続)
Horizontal BarU+2015―副題、引用(和文)
Minus SignU+2212−マイナス記号
Heavy Minus SignU+2796➖太いマイナス記号
MinyU+29FF⧿⧿鉱山記号?
Fullwidth Hyphen-MinusU+FF0D-マイナス記号(全角)
TildeU+007E~~半角チルダ
Small TildeU+02DC˜˜小さい半角チルダ
Tilde OperatorU+223C∼数学記号
Wave DashU+301C〜波ダッシュ、「から」
Fullwidth TildeU+FF5E~全角チルダ

 上記の数があるだけで面倒なのに、さらにEm DashHorizontal Barには機種依存の問題もある。しかし英文ではダッシュの扱いが厳密で煩雑だ。このサイトでも妙な使い方をしているかもしれないが、過去の日記までは訂正しきれない。本来の表示と異なり小さく隙間が空いてしまうフォントも多くあるので使いにくい。(更新:

TEXTの強み

 小説を書き始めて以来幾つものワープロソフトを使ったが、純粋に文章を書く際はワープロの高機能が邪魔でエディタ中心になったため、私の小説執筆はTEXTファイルを基本にしている。また、TEXTファイルは各種ソフトウェアのバージョンアップに振り回されず作品を長期保存する上で安心だ。互換性で問題になりがちな改行コードもMacOS XがUnix/Linuxと同じLFに変更になったことは有り難い。

 HTML4.01はSGMLを、XHTMLはXMLをそれぞれ基礎に据えたTEXTファイルなので定義が変更されても基本的な規則が変わらない安定性がある。その一方、HTML5は前述のような技術応用としてではなくHTML5の勧告でのみ規則を据えるようなので、遠い未来に基本的な考え方も変えてしまう危険性も高まると思う。また現在、HTML4.01が基底とするSGMLの各種応用ツールは素人の手には渡らない上に今後の復権も無いと思う。そういう面でXHTML1.1は意外に良い安全策だと思う。

HTML5は強化版か

 HTML5の勧告草案が公開されていたので軽く読んでみた。新技術の期待などは他のサイトでも随分書かれているのでここでは割愛して、逆に私は削除されたりしている部分を敢えて挙げたいと思う。

 まずprofile属性が廃止されているのでGRDDLを使えない。私はGRDDLでメタデータ抽出を出来るようにしたページが多くあるので残念。またscriptが原則JavaScriptに限定され、更にJavaScriptのMedia TypeはRFC4329に関わらずapplication/javascriptではなくtext/javascriptになっている。現実に沿わせた方向だとは思うが、HTMLの規格内で定めなくても良いとは思う。他にもDOM0相当の規定などHTML4やXHTML1のサイトでも現実に使っているのだから、HTML5に押し込まずにDOM0を勧告しても良さそうだけれど。

トレーサビリティとメタデータ

 「食品トレーサビリティ」(新山陽子編、昭和堂)を読んだところ、食品製造現場の課題として、IT関係の知識習熟が低く、現場で水を大量に使用するため直接PCを利用できないという問題が挙げられていた。その解決法の一案として興味深かったのはポテトチップスの管理事例で、手書き帳票をPDFファイルで管理し、それをインデックスにより紐づけしておいて必要に応じて視認により解析するという手法である。他にはOCR帳票の活用もあったが、これは新たな投資が必要だ。また、流通上や出版物で活用の多いバーコード方式は最初にデータ入力が必要なので、最初の生産現場においては意味がない。社長自身が包丁を握って魚の開きを製造しているような零細メーカーや家族経営の小さなケーキ店などにはPDFファイル方式が最も容易だろう。

 現在のSemantic Webは既に電子化済みか電子化に向けたデータ整理の基礎があるものに閉じている。こういったPDFや画像ファイル、音声ファイルを基礎にしてつながりを作っていく仕組みを増やしていかなければ、Semantic Webはどこまでも仮想世界の話に終わるように思う。

図書館とメタデータ

 図書分類について調べていたところ、国立国会図書館で「国立国会図書館ダブリンコアメタデータ記述要素DC-NDL)」が公開されていた。これはDublin Coreを図書館用メタデータの記述用に精密化したものだ。日本十進分類法など図書館で用いられている書籍メタデータのスキーム要素が定義されたので活用が可能だ。文芸船の読書散策路も元データはRDF/XMLで書いているので、書籍の分類は日本十進分類法での記述に変更した。

 Amazonの検索は実に便利ではあるものの、書籍という広汎で歴史のある文書情報担体を電子情報と接続していく上では一企業を基礎とせずWeb標準と同様、なるべく公的な基準により記述すべきだ。それを考えると国立国会図書館の規格を応援したいと思う。当初この記事を書いた際はXML出力ぐらいあれば、と書いていたのだが、に再確認したところXML、SOAPなど様々なデータ利用が可能になっており今後の発展が楽しみだ。(更新:

メタデータと識別子

 W3Cが提案するGRDDLは、HTML文書に予めclass、id、rel属性等で付加した情報に基づいてメタデータを抽出可能とする技術だ。私のサイトでprofile属性を設定しているページもGRDDLによりメタデータの抽出が可能であり、W3C公開のW3C GRDDL serviceで確認できる。なお当該サービスを手軽に利用しやすくするBookmarklet等を作成したので参照願いたい。抽出可能な情報はhead要素内の記述内容、あとは本の話題から書籍の基礎情報(ISBNコード、書名、著者名、出版年)程度だ。食べ物や映画の話題は書籍のISBNコードのような識別子が無い。とくに食品のような、千差万別の特性を有する上に品質が時系列で変化するものにURIをどう与えるか難しい問いだ。

 ところで地理情報も扱いにくい。既存のWebサービスの多くは地名・施設名と緯度経度による座標を結ぶ形で扱っているが、座標は点である上、日常生活で使われる行政区画や目印と上手く一致しないことが多い。それを考えると全国地方公共団体コード(JIS X 0401、JIS X 0402)や大学・高等専門学校コード(JIS X 0408-04)等を上手く使えたら面白いと思う。ただ海面や湖面に限っては、船舶航行では世界測地系による座標を使用するうえ、漁業権区域等も一般には座標と距岸距離等で表現することから、現状のリテラルと緯度経度が最も妥当だと思う。(更新:

SNSと匿名性

 mixiでの公開情報から、P2PのShareによる流出画像の個人が特定されるという問題が起きた。現在進行中のSemantic Webでは一つの情報から必要な情報を収集できることを目指しているわけで、今後こういった事故は増えていくと思う。ただし気をつけるべきことはWeb全体の匿名性を高めることではなく、情報を発信する個人が秘匿すべき情報と公開可能な情報を切り分けることだ。家の外に家族写真を貼ったり日記帳を酔っ払って置き忘れるなというレベルの話に過ぎない。ちなみに招待制だから安心だというmixiの主張は完全な誤りである。スモール・ワールド現象の理論によれば、たった6人の知り合いと繋がればその先に無関係の人が関わりを持ってくるわけで理屈上は世界中全員がmixiに加入することすらありえる。SNSの招待制は入会者に対して詳細な審査等を行うわけではないのだから、一見さんお断りの料亭よりはるかに公開された世界なのだ。

 日本で騒ぎが多いのは、技術の未熟性よりも欧米近代以降の私の確立が未だなされないことにある。2ちゃんねるの繁栄は匿名性自体よりも「私と彼は別人である」ことを確定させずに「みんなの意見」に変えてしまう点にある。単に交流を目的として日本の文化に合わせるならば、案外2ちゃんねるの健全型が終着点かもしれない。

HTTPヘッダ再考

 HTTP1.1においてファイルが存在しない場合、本来ステータスコード404で返す規定だが、Apacheで独自のNot foundファイルを絶対パスで指定すると、302で転送された後Not foundファイルが200で返される。つまり404は一度も返されない。これを避けるには相対パスで記述するか、乱暴だがファイルパスの代わりにHTMLソースを直接.htaccessに書けば良い。

 忘れがちなのは302によるリダイレクトで、本来の仕様ではリダイレクト先を表記した短いHTMLを送る。単に.htaccessで処理するのならApacheが自動でHTMLを送ってくれるが、PHPやCGIで302を送る場合には実装が必要だ。なお細かいことを言えば、Apache標準のHTMLはHTML2.0のhere症候群文書で行儀の良いHTMLではない。

HTMLの規格選び

 私のサイトはXHTML1.1を用いている。スクリプトで処理する場合にXMLだと便利な上、MIME-Typeを除けば書式としてXHTML1.0を選ぶ必要を感じなかったからだ。とくに私のサイトは早期からHTML4.01 Strictに収まっていたという事情もあった。初学者が下地なしで覚えるには終了タグの複雑な省略規則や閉じないmeta要素があるHTMLよりXHTMLの方が単純で楽だと思う。経験者がHTMLの方を楽だと感じるのは経験の蓄積とHTMLの誤り補正機能が理由だろう。だが誤り補正機能は誤りを直さなくて良いという意味ではないし確実に補正される保証も当然にない。

 Pre-HTMLに基づいて一定規格で生産するISO-HTMLの工程管理思想は面白いが各種ツールやCMSが台頭してきた現在、その利点を再構築するべきだと思う。ちなみにISO-HTMLのセクションに関する考え方は安易な入れ子要素を抑制する上では便利だが、XHTMLでも意識して作業するのみで充分に感じる。(更新:

トップページとblog

 blogが出てから世にあるトップページはメニューを中心とした玄関機能から更新情報を初め日記その他が来る形式が中心に変わった。更新情報のためにわざわざ別のページに行くのは面倒だという感覚はわかったので、私もトップページにRSS1.0を変換した更新情報を掲載し、更新情報ページは廃止してしまった。但し、3カラムもあるblogの構造は情報が多すぎるように感じる。とくにアフィリエイトはネット上の情報価値を希釈するばかりのように思えてならない。

RDF/XMLの使い方

 文芸船の読書散策路トップページについては、元データをRDF/XMLで作成し、XSLTでXHTMLに変換して提供している。冗長にはなるが資料集的な文書を作る際には頭が整理できて逆にわかりやすい。でもRSS1.0以外のRDF/XMLを上手く使えるアプリケーションが殆ど見当たらない点は残念。実際、blogに付いているFOAFの中身を見るとnickとmbox_sha1sumしかないものが多く、これではソフトウェアを作っても価値は低いだろうと思う。

サイト紹介の作り方

 自己紹介やサイト紹介のページはどうもこれといったものが思いつかない。何をどこまで書けば良いのか基準もないので私のサイトでは本当に最低限しか書いていない。

 Web技術雑感は近況つれづれからWeb技術関係を分離することと、サイト製作基準などを何となく書ける場所を確保しようという発想が始まりだ。サイト開設当初は確認ブラウザなども書いていたのだが、Mozilla FirefoxやLynxが頻繁にバージョンアップするため、書き直すのが煩わしくて外してしまったという経緯がある。それならWeb技術メモを並べておいた方が結局は私の指向を見てもらえるかと考えたわけだ。いずれにしろDublin Coreなどの統制語彙も含め、しっくりする紹介方法にはまだ出会えない。

Strictな人たち/100の質問など

 時折2ちゃんねるのWeb製作版を覗くのだけれど、その中のStrictスレッドが面白い。HTMLの妥当性を極めるという趣旨なのだが、窮極を目指すせいか極論も多い一方、簡潔で論理的な説明もある。でも文芸サイト運営者の私は日本語の限界まで引き出そうという指向だからHTML次第で文章の書き方まで変える話は勘弁してくれと思う。ちなみにあのスレッド住人は何のサイトを作っているのだろう。Web技術話中心ばかりならちょっと嫌。そんな流れで100の質問など回答してみた。「タグ打ちさんに50の質問」はなるべく出題者の意向を汲みつつ、結構真面目に回答していたりする。書いている最中はだるいのに病みつきになりそうなのは無駄な達成感の仕業かな。

  1. CSS関係者に37の質問
  2. タグ打ちさんに50の質問

ISBNとURN

 URN:ISBN:XXXXXXXXXXXXXという記法は、書籍の国際識別コードであるISBNコードをURIの一種であるURNとしてネットワーク上の識別子化したものだ。このためhref属性の値に設定している例も見られるが、電子書籍以外の書籍はネットワーク上に存在しないため、デッドリンクかスクリプト等で書店のサイトへのリンクに変換しているサイトがほとんどだ。

 リンクとは、あるWebリソースから他のリソースへの繋がりのこと、とHTML4.01仕様書で定義されており、href属性の値はURIになるが、さらに詳しく読むとWebリソースの所在(locationを指定する、とされている。また「榎本武揚は明治維新に功績を残した」という文章で「榎本武揚」にリンクを設定する場合、通常は人物紹介のサイトにリンクすることを考え併せると、本質的な関係性を示す意図はなく便宜的なものに過ぎないが、初めから書店のサイトにリンクしたいのなら素直にそのリンクを書いても良いはずだ。ちなみに文芸船では書籍名などにISBNを元にしたid属性を与えてJavaScriptでアンカーを生成しており、またRDFも抽出可能にしている。(更新:

文芸船profile & mail