1. トップページ

XHTML + RDFa 1.0 から XHTML + RDFa 1.1 への書き換え

2013年03月25日

RDFa 1.0 と RDFa 1.1 の変更点という記事を書いたので今回は XHTML + RDFa 1.0 から XHTML + RDFa 1.1 への書き換えの際の注意点を書いておく。

DOCTYPE

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">

RDFa 1.0 と RDFa 1.1 は異なるため DOCTYPE を書き換える必要がある。

HTML要素

<html
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:dbpedia="http://dbpedia.org/resource/"
    xmlns:foaf="http://xmlns.com/foaf/0.1/"
    xml:lang="ja"
    version="XHTML+RDFa 1.1"
    about=""
    typeof="foaf:Document"
>
<html
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xml:lang="ja"
    version="XHTML+RDFa 1.1"
    prefix="dbpedia: http://dbpedia.org/resource/"
    about=""
    typeof="foaf:Document"
    xsi:schemaLocation="http://www.w3.org/1999/xhtml http://www.w3.org/MarkUp/SCHEMA/xhtml-rdfa-2.xsd"
>

XHTML + RDFa 1.1 では @xmlns ではなく @prefix を使用する。FOAF はデフォルトでマッピングされているため @prefix で指定する必要はない。デフォルトで使用できる語彙は RDFa Core Initial Context で確認できる。

XML Schema の場所を @xsi:schemaLocation で指定できるようなので指定しておく。

profile属性

head要素で使用できた @profileXHTML + RDFa 1.1 の DTD で定義されていないため使用できない。

src属性

@src は主語から目的語へと変更された。@src と共に @property@rel を記述している場合には書き換える必要がある。

property属性

@property は目的語リテラルに使用するものだが、@href, @resourcec, @src の何れかが存在して @rel, @rev, @datatype, @content の何れも存在しない場合は @property の目的語はリテラルではなくリソースになる。

<h1><a id="#h1" href="#h1" property="dc:title">Title</a></h1>

以上のような書き方をしている場合には書き換える必要が出てくる。

datatype属性

@datatype のデフォルトはプレーンリテラルとなった。今までは子要素が存在してプレーンリテラルを指定する場合は datatype="" と書かなけばならなかったが、もはやその必要はなくなった。

<p property="dc:title">E = mc<sup>2</sup>: The Most Urgent Problem of Our Time</p>
<p property="dc:title" datatype="rdf:XMLLiteral">E = mc<sup>2</sup>: The Most Urgent Problem of Our Time</p>

XML Literal を使用したい場合 XHTML + RDFa 1.1 では明示的に datatype="rdf:XMLLiteral" と指定する必要がある。

inlist属性

XHTML + RDFa 1.1 では @inlist を使用して簡単に RDF Collection を作成できるようになった。既に XHTML + RDFa 1.0 で RDF Collection を記述しているならば書き直す必要はない。しかし @inlist で記述すると非常に読みやすくなる。

<p prefix="bibo: http://purl.org/ontology/bibo/ dc: http://purl.org/dc/terms/" typeof="bibo:Chapter">
  "<span property="dc:title">Semantic Annotation and Retrieval</span>", by
  <span inlist="" property="dc:creator" resource="http://ben.adida.net/#me">Ben Adida</span>,
  <span inlist="" property="dc:creator">Mark Birbeck</span>, and
  <span inlist="" property="dc:creator" resource="http://www.ivan-herman.net/foaf#me">Ivan Herman</span>.
</p>

タグ: RDF

RDFa 1.0 と RDFa 1.1 の変更点

2013年03月24日

最近になって知ったことだが、RDFa 1.0 をバージョンアップさせた RDFa 1.1 が勧告されていた。

Introduction to RDFa によると RDFa 1.1 による変更点は 以下のようなものである。

  • XHTML 特有のルールが XHTML+RDFa 1.1 として分離。
  • @xmlns による接頭辞宣言を廃止予定とし、@prefix を追加。
  • 接頭辞は大文字・小文字を区別せず、比較するときは小文字変換される。
  • データ型が CURIE の場所に絶対 IRI を書けるようになった(CURIEorIRI)。
  • データ型が CURIE の場所にタームを書けるようになった(TERMorCURIEorAbsIRI)。
  • 未定義のタームを定義するのに(@vocab を通して)デフォルト接頭辞を定義できる。
  • 目的語リテラルに @datatype がない場合、1.0 では XMLLiteral だったが、1.1 はプレーンリテラルになる。
  • @inlist によって、単純トリプルではなく、リソースに付随する RDF リストを生成できる。
  • @src は、1.0 では @about(主語)と同じであったが、1.1 では @href(目的語)と同じ。

私見としては @prefix ではなく @xmlns のままでもよいと思うのだが、廃止予定になってしまった。@xmlns について嫌いな人が多いのか、それとも HTML + RDFa との関係もあるのかもしれない。

@property, @datatype, @rel, @rev にそのまま URI を指定できる(正確には IRI)ようになったのは大きなメリットだと思う。RDFa 1.0 ではたった一回だけしか使用しないプロパティでも @xmlns を記述しなければならなかった。これはソースを汚くする大きな要因だった。

@datatype が存在せず、子要素が存在する場合は rdf:XMLLiteral になっていたが、これも地味に迷惑だった。子要素があるたびにいちいち datatype="" と記述しなければならないのは面倒だ。デフォルトはプレーンリテラルで XMLLiteral にしたい場合は datatype="rdf:XMLLiteral" と明示的に指定するように改善されたのはよかった。

@inlist が追加されたため RDF Collection が簡単に記述できるようになったのも大きな前進だろう。RDFa 1.0 で RDF Collection を記述しようとすると見るに堪えない汚いコードを書かなければならなかった。また RDF Collection で目的語にリテラルを使えるというのもよいと思う。(というのも RDF/XML では目的語にリテラルが使えず Turtle と比べて大きく見劣りする原因だった。)

@src が主語ではなく目的語になったのもよいことだ。もともとimg要素を使用するとき画像のメタデータの記述を簡単にするために @src を主語にしたと考えられるのだが、これは画像とそのページとの関係を記述するとき大きな妨げになっていた。<img alt="Logo" src="logo.png" rev="foaf:logo" resource="" /> などと書かなくてすむのはありがたいことだ。

それと @vocab は無くてもよい。というか態々新たに属性を作成する必要性があったのだろうか?

あと気づいた事なのだが、幾つかの接頭辞はデフォルトで定義されているようだ。

When an RDFa Processor processes an XML+RDFa document, it does so via the following initial context:

  1. There are default terms (e.g., describedby, license, and role), defined in http://www.w3.org/2011/rdfa-context/rdfa-1.1.
  2. There are default prefix mappings (e.g., dc), defined in http://www.w3.org/2011/rdfa-context/rdfa-1.1.
  3. There is no default vocabulary IRI.
  4. The base can be set using the @xml:base attribute as defined in [XML10-4e].
  5. The current language can be set using @xml:lang attribute.

デフォルトで定義されている接頭辞の一覧は RDFa Core Initial Context で参照することが出来る。W3C で作成された語彙は勿論のこと、Dubli Core や FOAF や SIOC などの有名どころの語彙も @prefix なしで使用できるということであろう。

XHTML+RDFa 1.1 も勧告されているため、すくにでも XHTML で使用することが出来る。

この記事を書いた後 RDF 1.0 と RDF 1.1 の大きな変更点をもう一つ発見した。

例えば以下のような XHTML + RDFa のコードを N-Triples に変換するとする。

<h1><a id="#h1" href="#h1" property="dc:title">Title</a></h1>

RDF 1.0 では 以下のような N-Triples になる。

<> <http://purl.org/dc/terms/title> "Title";

何も可笑しい所はない。ところが RDFa 1.1 だと以下のような N-Triples になる。

<> <http://purl.org/dc/terms/title> <#h1>;

RDFa 1.1 の仕様書を眺めていると、それっぽい記述を見つけた。

A literal object can be set by using @property to express a predicate, and then using either @content, or the inline text of the element that @property is on. Note that the use of @content prohibits the inclusion of rich markup in your literal. If the inline content of an element accurately represents the object, then documents should rely upon that rather than duplicating that data using the @content.

A IRI resource object can be set using one of @rel or @rev to express a predicate, and then either using one of @href, @resource or @src to provide an object resource explicitly, or using the chaining techniques described above to obtain an object from a nested subject, or from a bnode. Alternatively, the @property can also be used to define an IRI resource, in the presence of an @href, @resource, or @src and in the absence of @rel, @rev, @datatype, or @content.

私が読む限り @href, @resourcec, @src の何れかが存在して @rel, @rev, @datatype @content の何れも存在しない場合は @property の目的語はリテラルではなくリソースになるようだ。

正直これは改悪ではないかと思う。なんのための @rel だろうか。

参考リンク

タグ: RDF

台湾ではアダルトに著作権はないのか?

2013年03月23日

昨今著作権に関する問題は尽きないが、台北地検「アダルトに著作権なし」、日本販売元訴え不成立という記事によると台湾ではアダルトに著作権は認められないそうだ。

台湾ではこれまで、1999年にポルノ動画は公序良俗に反し、著作権法の対象である文学・科学・芸術などの著作に該当しないため、その保護は受けないとされた刑事判決事例がある。また高等法院2005年の刑事判決では、モザイク処理を施し、政府新聞局の審査で合格して限制級(台湾のアダルトランク)認定を受けたとしても、著作権法の保護を受けることはないとされている。同地検ではこのような判例や見解を受け、今回、台湾企業側が動画をネット上で配布しても著作権法違法にはあたらないとした。

これによって世界のポルノ動画が台湾に集まってくるなんてこともありうるのだろうか。

書誌情報を RDFa で記述する

2013年03月23日

焼きたて!!ジャぱんレシピで焼きたて!!ジャぱんの単行本の情報を大幅に追加したのだが、書誌情報をどのように RDFa で記述するか迷ったのだが、以下のようになった。

<div
    id="main"
    about="#main"
    typeof="book:Book"
    xmlns:bibo="http://purl.org/ontology/bibo/"
    xmlns:book="http://purl.org/NET/book/vocab#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:foaf="http://xmlns.com/foaf/0.1/"
    xmlns:ov="http://open.vocab.org/terms/"
    xmlns:owl="http://www.w3.org/2002/07/owl#"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
>
    <h1 property="dc:title">焼きたて!!ジャぱん 1巻</h1>

    <p property="dc:description">「週間少年サンデー」2001年第47号〜第51号、2002年第4・5号掲載作品</p>

    <blockquote cite="http://skygarden.shogakukan.co.jp/skygarden/owa/solc_dtl?isbn=4091263917" title="小学館:コミック 『焼きたて!!ジャぱん 1』">
        <p property="dc:description">東京に着き、早速パンタジアに向かった和馬。だが本採用されたと思ったのは早合点で、採用通知はその日一日のみ有効のものだった。和馬を待っていたのは、受験者35名中1人しか採用されない、厳しい本採用試験。果して和馬は、パンタジアの正式な店員になれるのか…!?</p>
    </blockquote>

    <dl>
        <dt>焼きたて!!ミニ知識</dt>
        <dd property="dc:subject">フランスパン</dd>

        <dt>ページ数</dt>
        <dd property="ov:numberOfPages" datatype="xsd:positiveInteger" content="192">192ページ</dd>

        <dt>初版発効日</dt>
        <dd property="dcterms:issued" datatype="dcterms:W3CDTF" content="2002-04-15">2002年04月15日</dd>

        <dt>価格</dt>
        <dd>JPY 390</dd>

        <dt>言語</dt>
        <dd property="dc:language" datatype="dcterms:RFC5646" content="ja">日本語</dd>

        <dt>著作権表記</dt>
        <dd property="dc:rights">©Takashi Hashiguchi 2002</dd>

        <dt>ISBN10</dt>
        <dd><a property="bibo:isbn10" datatype="xsd:string" rel="owl:sameAs" rev="owl:sameAs" href="urn:isbn:4091263917">4-09-126391-7</a></dd>

        <dt>ISBN13</dt>
        <dd><a property="bibo:isbn13" datatype="xsd:string" rel="owl:sameAs" rev="owl:sameAs" href="urn:isbn:9784091263919">978-4-09-126391-9</a></dd>

        <dt>雑誌コード</dt>
        <dd>45093-91</dd>

        <dt>出版元によるページ</dt>
        <dd><a rel="foaf:homepage" href="http://skygarden.shogakukan.co.jp/skygarden/owa/solc_dtl?isbn=4091263917">小学館:コミック 『焼きたて!!ジャぱん 1』</a></dd>

        <dt>データベース</dt>
        <dd><a rel="owl:sameAs" href="http://www.worldcat.org/oclc/168962102">WorldCat</a></dd>

        <dt>次巻</dt>
        <dd><a rel="next" href="http://japan.nusutto.jp/yakitatejapan/comics/volume2.html" resource="http://japan.nusutto.jp/yakitatejapan/comics/volume2.html#main">焼きたて!!ジャぱん 2巻</a></dd>
    </dl>

    <div class="section" id="fragment_translations" rel="dcterms:hasFormat">
        <h2>翻訳版</h2>

        <div class="section" id="fragment_en_version" about="#fragment_en_version" typeof="book:Book">
            <h3 property="dc:title" xml:lang="en">Yakitate!! Japan, Volume 1</h3>

            ...
        </div>
</div>

この RDFa は 焼きたて!!ジャぱん 1巻 のページに書かれているものである。 一部見やすくするため改編している。

まず http://japan.nusutto.jp/yakitatejapan/comics/volume1.html#main が本であることを示すために RDF Book Vocabularybook:Book@typeof に記述。

単行本のタイトルと説明と言語とコピーライトには Dublin Coredc:titledc:descriptiondc:languagedc:rights を使用した。

単行本のその他のメタ情報は、ページ数については Terms in the OpenVocab RDF schemaov:numberOfPages を、初版発効日は DCMI Metadata Termsdcterms:issued を、ISBN10 と ISBN 13 については The Bibliographic Ontologybibn:isbn10bibn:isbn13を使用して記述した。

また http://japan.nusutto.jp/yakitatejapan/comics/volume1.html#mainurn:isbn:9784091263919WorldCathttp://www.worldcat.org/oclc/168962102 は同じリソースと考えられるので owl:sameAs で同一であることを明示した。

翻訳版に関しては dcterms:hasFormat で示せば問題ないはずである。

以上が私が書誌情報を書くときに使った語彙です。皆さんが書誌情報を RDFa で記述するときの参考になれば幸いです。

タグ: RDF

RDFa を使用して Blog に SIOC を埋め込んでみましょう

2013年03月23日

現在ブログ改装中なのだが RDFa を利用して SIOC を埋め込んでみた。

SIOC とは BBS や Wiki や Blog などでの情報をセマンティク化するために RDF で定義された語彙群である。

The SIOC (Semantically-Interlinked Online Communities) Core Ontology provides the main concepts and properties required to describe information from online communities (e.g., message boards, wikis, weblogs, etc.) on the Semantic Web. This document contains a detailed description of the SIOC Core Ontology.

この SIOC をブログに導入するだけで、今流行のセマンティックWebに貢献することになる。導入する方法はとても簡単である。すこし HTML を書き換えるだけである。

例えば以下のような HTML が存在したとする。これはブログのエントリーの HTML に他ならない。

<div class="article">
    <h1><a href="http://www.example.com/blog/entry/154">花粉がひどい</a></h1>

    <div class="content">
        <p>花粉症が酷くて鼻水が止まらない。今年は去年よりも花粉の飛散量が多いそうだ。</p>

        <p>早く花粉がやんでほしい。辛くて仕方ない。</p>
    </div>

    <p>タグ: <a href="http://www.example.com/blog/tag/%E8%8A%B1%E7%B2%89%E7%97%87">花粉症</a></p>

    <p>Posted by <a href="http://www.example.com/user/31">アリス</a> at 2013年03月23日 04:08:56</p>

    <div class="comments" rel="sioc:has_reply">
        <h2>コメント</h2>

        <div class="comment" id="comment-1">
            <p>花粉症ですか? 大変そうですね。お大事にしてください。</p>

            <p>Posted by <a href="http://www.example.com/user/63">ボブ</a> at 2013年03月23日 10:30:47</p>
        </div>

        <div class="comment" id="comment-2">
            <p>私も花粉症です。早く花粉がやんでほしいですね。</p>

            <p>Posted by イブ at 2013年03月23日 11:50:36</p>
        </div>
    </div>
</div>

これに SIOC を埋め込むと以下のような HTML コードとなる。

<div class="article" about="http://www.example.com/blog/entry/154" typeof="sioc:Post">
    <h1><a href="http://www.example.com/blog/entry/154" property="dcterms:title">花粉がひどい</a></h1>

    <div class="content" property="sioc:content">
        <p>花粉症が酷くて鼻水が止まらない。今年は去年よりも花粉の飛散量が多いそうだ。</p>

        <p>早く花粉がやんでほしい。辛くて仕方ない。</p>
    </div>

    <p>タグ: <a rel="sioc:topic" href="http://www.example.com/blog/tag/%E8%8A%B1%E7%B2%89%E7%97%87">花粉症</a></p>

    <p property="dcterms:created" content="2013-03-23">Posted by <a rel="sioc:has_creator" href="http://www.example.com/user/31">アリス</a> at 2013年03月23日 04:08:56</p>

    <div class="comments" rel="sioc:has_reply">
        <h2>コメント</h2>

        <div class="comment" id="comment-1" about="http://www.example.com/blog/entry/154#comment-1" typeof="sioc:Post">
            <p property="sioc:content">花粉症ですか? 大変そうですね。お大事にしてください。</p>

            <p property="dcterms:created" content="2013-03-23">Posted by <a rel="sioc:has_creator" href="http://www.example.com/user/63">ボブ</a> at 2013年03月23日 10:30:47</p>
        </div>

        <div class="comment" id="comment-2" about="http://www.example.com/blog/entry/154#comment-2" typeof="sioc:Post">
            <p property="sioc:content">私も花粉症です。早く花粉がやんでほしいですね。</p>

            <p property="dcterms:created" content="2013-03-23">Posted by イブ at 2013年03月23日 11:50:36</p>
        </div>
    </div>
</div>

以上のように SIOC を使用すると自然なマークアップでメタデータを埋め込むことが出来る。

以上の RDFa を RDF Graph に変換すると http://maplesikou.up.seesaa.net/image/20130323132750.svg のようになる。

ちなみに SIOC と DC Terms を 使うためにはXML名前空間を使用して、SIOC と DC Terms を使用することを記述しなければならない。以下のようにルート要素に記述しておくのが良いであろう。

<html
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:sioc="http://rdfs.org/sioc/ns#"
>

タグ: RDF

Seesaa Blog で自動的に挿入されるコード

2013年03月23日

Seesaa Blog は本当にいいブログサービスだと思う。レスポンスが遅いことはよくあるが、HTML/CSS を好きなように編集出来たり、容量が2GBだったりと他のブログサービスと比較しても本当に高機能でいいブログサービスだと思う。

ところで現在ブログのデザインを変更中なのだが、その中で少々見慣れないコードを目にした。

<script type="text/javaScript">seesaa_site_id = 'maplesikou'; seesaa_floating = false;</script>
<span id="iphone-link" style="display:none; padding-top:3px;text-align:right;"><a href="javascript:document.cookie='force_pc=0; max-age=15768000; path=/'; document.location='/'">スマートフォン専用ページを表示</a></span>
<script type="text/javaScript"><!--
if ((0 <= navigator.userAgent.indexOf('iPhone')) || (0 <= navigator.userAgent.indexOf('Android'))) { document.getElementById('iphone-link').style.display = 'block'; }
//--></script>
<script type="text/javascript">
var url = document.URL;
document.write("<img src='http://d3mgo879eugsjh.cloudfront.net/t.gif?url=" + encodeURIComponent(url) + "' />");
</script>

もちろんこのようなコードを記述した覚えはない。この2つのコードは編集時のHTMLコードの中には存在しないが、ブログに出力したときに自動的に追加されるコードのようだ。

前者のコードはbody要素の開始に挿入されていて、どうもブログにアクセスしてきたスマートフォンためのコードであると思う。問題は後者のコードで、これはbody要素の終了前に挿入されていて、一見する限りこれは明らかにトラッキングコードだ。

実際に http://d3mgo879eugsjh.cloudfront.net/t.gif?url=http%3A%2F%2Fmaplesikou.seesaa.net%2F は 1×1 のスペーサーGIFである。トラッキング用の GIF かと思ったのだが、GIF の Http Response Header を見る限り不思議なことに Cookie を送ってきていないようである。

以下のような HTTP Request Header を送ると

GET /t.gif?url=http%3A%2F%2Fmaplesikou.seesaa.net%2F HTTP/1.1
Host: d3mgo879eugsjh.cloudfront.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

以下のような Http Response Header が返ってきた。

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 807
Connection: keep-alive
x-amz-id-2: YxP3qaEZKOdRGA3rb4UTDr8KA1s9Xd8kXi6SWY7OYVyrLor3DwQLO+Q2KN31lvPQ
x-amz-request-id: 9778B0D5C6FB9406
Date: Sun, 03 Mar 2013 19:52:42 GMT
Last-Modified: Wed, 24 Oct 2012 05:27:37 GMT
Etag: "028e0deae257fc5f0b21587317e32328"
Accept-Ranges: bytes
Server: AmazonS3
Age: 70885
Via: 1.0 e80339feae8349e9a672ae4b2bc6d816.cloudfront.net (CloudFront)
X-Cache: Hit from cloudfront
X-Amz-Cf-Id: SNKG_Br8tm1h3p8epYMLZUd4PaJGAFz9314vMdj-bnqeCwAlTquWmg==

GIF 自体は Amazon のサーバにあるようだが Cookie を送ってきていないことを考慮するとトラッキングではないのか? それとも IPアドレス単位で記録しているのだろうか? どちらにしても Seesaa がブログにこのコードを挿入している理由はわからない。

残念ながらこの2つのコードを自動的に挿入されないように設定することは出来ないようだ。XHTML が valid ではなくなってしまうため迷惑なコードだ。

インターネットを停止させても止められないものがあるようだ

2013年03月22日

Tor Project のメンバーである Karen Reilly氏とRuna A. Sandvik氏が一日質問を受けていたようだ。

Karen from Tor here. How do we feel about it? We are angry. We talk to people who work with NGOs and government agencies to combat child abuse, human trafficking, stalking, and domestic violence. If you work for Tor, you learn more than you ever wanted to know about the horrible things that happen to vulnerable people. We also get to do work on behalf of vulnerable people. Think about what happens to people in prison after they are arrested for protesting against the government. Some of that happens because of Internet surveillance. Survivors connect to each other anonymously online, because they cannot do so in person.

I am angry at the people who abuse children. I am angry at people in institutions who look the other way in order to preserve reputations and money at the cost of the well-being of vulnerable people. I am angry at government officials and politicians who divert resources away from social services and the investigators who are working on the ground to prevent child abuse in the first place. I am angry at politicians who do not bother to learn how the Internet works; to better know how much of the problem is technology and how much is lack of counselors, training for police, work against corruption, and other non-technical means. Instead, they act as if placing restrictions on the entire population is a magic bullet against child abuse images.

Even if the entire Internet went away, child abuse images would still be traded. Some things can not be stopped. One can only ensure that these bad things do not give people in power excuses to take out the good.

残念ながらインターネットで違法なものが流れているのは事実であろう。DNSポイズニング程度のブロッキングではその流れが変わることはない。インターネット全て遮断してやっと流れが止まるのだろう。それでもアンダーグラウンドの中では流れ続けるだろう。

CSS/JavaScript 依存のWebページ達

2013年03月22日

IBM で Peter Seebach氏が Webアクセシビリティについて述べている文書が面白かった。

ここに書かれている事はかなり正しいように思える。特に最近は CSS/JavaScript 依存が酷いように感じる。

はっきり言って JavaScript を切ってアクセスすると真っ白で何も表示されなかったり、JavaScript を通してリンク(href="javascript:open();"など)が貼れているためリンクが全く機能しないサイトなどははっきり言って論外だと思う。

本来 HTML の文法通り記述すればWebブラウザの CSS/JavaScript を切っても難なく読めるはずである。ところがそれを満たしているWebサイトがどれ程存在するあろうか。

私が思うにどうでもよい所に JavaScrpt が使われ過ぎている感がある。本来で CSS で解決できるものに態々 JavaScript を使用したり、HTML/CSS をベースにしないで、JavaScrpt をベースにして作られているWebページのことに他ならない。そんな作り方をしているから JavaScript を切ったとき真っ白で何も表示されないWebページが出来上がるんですよ。

最近は Twitter の影響で Hashbang が話題のようだが、こういった JavaScript に依存している技術は早く廃れていってほしい。

最後にPeter Seebach氏の文書を引用しておこう。

Webサイトに関して言えば、自覚していなかった箇所に、大きな問題が潜んでいます。わたしたちは、自分たちが特権を持った人間であるということを 忘れて います。わたしの知っているあるユーザーが、HTMLでなくPDFをWebページ上に入れる習慣があることについて不平を言っていました。当初わたしには、これは無害のように思われました。しかし、必ずしもすべてのユーザーが専用リーダーをコンピューターにインストールする権限を 持っているわけでないこと、また、テキスト・インターフェースを使用するユーザーがPDFをまったく 読み取ることができないことを知るに及んで、わたしの考えが変わりました。あなたが当たり前の事と思っていることを点検してください。最新のコンピューターを持っていない 人たちに、どんなオプションを持っていると思うかと聞いて、自分の想定を点検してみるのです。(あなたのサイトにアクセスしてくる可能性のあるすべてのユーザーのために、事前に制約を取り除くことを喜んでコミットしない限り、あなた が制限を1つ取り除くことができたとしても、役に立ちません。)

あなたが、あなたのサイトを訪れるユーザーに、特定のバージョンのブラウザーや特定のフィーチャーを要求するとしたら、どのような理由からにせよ、指定された機能を持っていないすべての人たちに、次のようなことを言っていることになります。「わたしは、あなたたちのことに構うつもりはないし、伝えたいことも無いし、気にもかけていない」と。果たして これがあなたのメッセージでしょうか?

いいえ、そうではない筈です。すべての環境で稼動するページを作ってください。Lynxの上でも、わたしのPDAで稼働するブラウザーの上でも、あるい最新最高バージョンのNetscape上でも稼動するようにしてください。追加の機能が必要であれば、それらを組み込むのもよいでしょう。しかし、わたしがその機能を使えなくても、あなたのページを見れるようにしてください。イメージの内容が分かるようにalt タグをイメージに使用してください。いつの日にか、あなたの両親が 1月か2月おきに動かすウンザリするほど古いMACから、 あるいはPalm Pilotから、自分のページにアクセスすることになるかもしれません。 あなたが取りおいた健全さ、あなたに役立つようになるかもしれません。

要約すれば、JavaScriptは常に、ユーザーのオプションにすべきだということです。JavaScriptに依存しても、ページを改善できないばかりか、不自由にするだけです。特に、機能強化だけが目的で変更する場合、ツールがJavaScriptへの依存性を組み込む可能性があることに気を付けてください。機能強化そのものは無害であり、普通は人の感情を害するものではありません。ただし、ページを表示するにはJavaScriptを使用する必要があるのだと、他の人に言うことはやめてください。そのような言い方は乱暴ですし、あなたのサイトを訪れる人を獲得することにもならないでしょう。

トラッキングを回避する為に行うこと

2013年03月21日

最近スラッシュドット・ジャパンを見ることが多くなったのが、インターネットでの行動は常に監視されている。逃れることはできないという記事を読んだ。

またFirefox 22でのサードパーティーCookie仕様に米国の広告協会が文句を言うという記事が掲載されるなど最近はトラッキングの話題がホットだと思う。

そこでトラッキングを回避する方法をレベル別に紹介したいと思う。

Level 1 DNT をオンにする

HTTP Response Header の中には DNTフィールドというものが存在する。これはクライアント側がサーバ側に対してトラッキングしないでほしいと要望するものである。

最新ブラウザーならばほぼ設定の中にDNTフィールドに関する項目があると思う。Mozilla Firefox ならば ツール >> オプション >> プライバシーの中にあるトラッキングの拒否を Web サイトに通知する(D)の欄にチェックを入れて OK を押す。

ただDNTフィールドはあくまで要望であってサーバ側が対応しているとは限らない。DNTの要望に忠実なサーバもあれば全くもって無関心なサーバも存在する。そのためおまじない程度と考えた方が良いであろう。この問題についてはIE10のDNT(トラックすんなよヘッダー)、Apacheで無視されることになり議論勃発がよく纏まっているので参照されたい。

Level 2 referer を送信しない

referer を説明するのは面倒なので e-Words から引用する。

あるWebページリンククリックして別のページに移動したときの、リンク元のページのこと。Webサーバアクセスログに記録される項目の一つ。

これを辿っていくと閲覧者がどこのサイトから訪問したのか、また、サイトでどのような軌跡を辿ったのかなどを調べることができる。検索エンジンからの訪問の場合には、URLパラメータ部分を調べることによって、どんな言葉で検索した結果のページから来たのかを知ることができる。Web広告の世界では、どのサイト/ページに掲載した広告に効果があったのかを調べることができる重要な項目である。

以上のように referer が有効になっていると どのページを辿ってきたかを送信していることとなる。

最新ブラウザーならば referer を送信しない設定は用意されているはずである。Mozilla Firefox ならば アドレスバーに about:config と入力し移動。設定の中に network.http.sendRefererHeader が存在するので値を0に変更する。これだけで referer を送信することはない。

Level 3 HTTPS を利用する

HTTPS とは早い話普段使用している HTTP に暗号化を施したものである。これによって HTTPS で通信している限りその内容はネットワーク管理者にも ISP にも分からない。

多くのネットワーク管理者は善良だと信じているが、一部の悪意あるネットワーク管理者は HTTP 通信を覗き見ているかもしれない。また ISP についても DPI広告などのきな臭い動きもあるため普段から HTTPS で通信しておいて損はないはずである。

HTTPS で通信を行うにしてもサーバ側が対応していなければ行うことが出来ない。いちいちサイト毎に HTTPS に対応しているかを大変であるが、幸いにも HTTPS Everywhere というアドオンがある。

このアドオンをブラウザーに導入すれば HTTPS に対応しているサイトに HTTP でアクセスした際に自動的に HTTPS に切り替えてくれる。

Level 4 Flash Cookie を無効にする

Flash Cookie とは Flash Player に内蔵されている記憶領域の事である。この機能を使うことによって例えば ユーザーは Flash Game などでログインなしで再び進めた処からプレイすることが可能などのメリットも多数存在するが、この機能を悪用してトラッキングにも利用されるなど問題になっている。

そもそもゲームの進捗状況や進み具合などはアカウントで管理すべきものであろう。

Flash Cookie を無効にする方法は Windows ならば スタート >> コントロールパネル >> Flash Player >> 記憶領域タブの中にあるこのコンピューターへの情報をすべてのサイトでブロック を選択すればよい。

また 同設定画面にあるすべて削除を押してすべてのサイトデータおよび設定を削除すべてのオーディオおよびビデオのライセンスファイルを削除にチェックを入れてデータを削除を押せば 今まで Flash Player を利用する中で PC 内に蓄積されてきた Flash Cookie は全て削除される。

またこの設定によって 一部 Flash が正常に動作しなくなるのではなどの懸念があると思うが、私が確認した限り一部の作りこんだ Flash Game などでは影響が出たもののそれ以外では特に問題はなかった。多くの人が利用するであろう YouTubeDailymotionニコニコ動画などの動画共有サイトでも問題はなかった。

Level 5 サードパーティ Cookie を無効にする

サードパーティ Cookie とは本来のアクセス先とは違うドメインから送信されてくる Cookie のことを言う。ちなみに本来のドメインから送信されてくる Cookie をファーストパーティ Cookieと言う。

例えばこのブログに Facebook が提供しているいいねボタンを設置したとする。そこへ常時 Facebook にログインしたままのユーザーがこのブログにアクセスしてきたとする。そうすると Facebook はこのユーザーはこのブログにアクセスしているということを知ることが出来る。

このように接続先が本来アクセスしたサイト以外にも漏れてしまうためサードパーティー Cookie は問題視されている。

無効にする方法は Mozilla Firefox ならば ツール >> オプション >> プライバシーの中にあるサードパーティの Cookie も保存するのチェックを外して OK を押す。これでサードパーティー Cookie は無効となる。

Level 6 Webブラウザーを閉じる時に Cookie を削除する

Webブラウザーを閉じる度に Cookie を削除するように設定すれば長期的なトラッキングを避けることが出来る。もちろんWebブラウザーを起動しっぱなしするより、Webブラウザー閉じる回数が多いほどトラッキングされにくくなる。

設定の方法は Mozilla Firefox ならば ツール >> オプション >> プライバシーの中にあるFirefox の終了時に履歴を消去するにチェックをいれ、その右側の設定を押し履歴の消去設定を開き、Cookie(C)の欄にチェックをいれて OK を押せば設定完了である。

Level 7 Cookie を無効にする

サードパーティー Cookie を無効にしてもファーストパーティ Cookie によるトラッキングを避けることはできないし、Webブラウザーを閉じる時に Cookie を削除しても短期的なトラッキングを避けることもできない。これを解決するには Cookie を全面的に拒否する以外に方法はない。

もちろん Cookie を全面的に拒否していればログインすることはできなくなるし、一部の Cookie を使用している Webサイトを利用する上で不具合が出るかもしれない。

これでは余りにも不便なので Cookie をホウイトリスト形式で管理できる Webブラウザーのアドオンを利用したい。

Cookie を管理するアドオンは幾つかあるが、私が使用しているのは Cs Lite Mod である。基本的な機能を備えていながらシンプルな為利用している。

それと Mozilla Firefox では Cookie を無効にすると localStorage も一緒に無効化されようだ。localStorage は Cookie の強化版のためこの動作は正しいように思える。

Level 8 検索エンジンを変更する

検索エンジンには Google, Bing, Baidu などが存在するが、これ等の検索エンジンはほぼトラッキングしていると言っても過言ではないであろう。検索エンジンにとっては何を検索したか、どのページにアクセスしたかは重要なのだから。

そんな中 Startpage Search Engine ではIPアドレスの記録やトラッキングを行わないことを明言している。

Startpage, and its sister search engine Ixquick, are the only third-party certified search engines in the world that do not record your IP address or track your searches.

この Startpage Search Engine を私も利用しているのだが、日本語検索では検索結果がいまいちだったり、一部の文字が文字化けしたりといろいろ難がある検索エンジンである。単純なことを検索するにはこれでいいのだが、複雑なことを検索する場合は Google などの既存の検索エンジンを利用したほうが効率が良いであろう。

Level 9 IPアドレスを変更する

IPアドレス単位でトラッキングが行われていると、避けるのは非常に困難だと言える。これに対してはIPアドレスを変更することが効果的だと言える。

動的IPアドレスの場合モデムの電源を一度切り、その後電源を入れるとIPアドレスが変わっていることがあるそうだ。確実な方法ではないが、手軽に行えるため一度試してもよいであろう。

Level 10 多機能 Proxy ソフトを利用する

モデムの電源を切る方法は確実ではないし、自分でモデムを管理していない場合(街中のアクセスポイントを利用する際など)では行うことはできない。

IPアドレスを変更する方法としては、古典的だが最も効果的な方法として Proxy を利用が考えられる。

Proxy とは代理サーバのことで、例えば http://www.example.com/ にアクセスする場合普通ならばクライアントがサーバに対して http://www.example.com/ の内容を送ってもらうように要求を出す。サーバはその要求を受けて応答するという仕組みだが、Proxy を利用する場合にはクライアントは Proxy に http://www.example.com/ の要求をして Proxy が サーバに問い合わせるという仕組みになっている。サーバの応答も要求と同じで Proxy を通して行われる。

このため Proxy を利用するとサーバにはクライアントのIPアドレスが分からない。ただこの場合 Proxy の信用性が問題になる。というのは Proxy の管理者にはどのような通信が行われているかが丸わかりである。

この問題に対応するために 多重に Proxy を使用して暗号化して通信を行うソフトがある。私が知っている限りでは TorI2P だが、特におすすめなのは Tor である。なぜならば Tor には Tor Browser という 匿名Webブラウザーが付属してあり、この Tor Browser はトラッキングを回避するように設定してあるためである。

いずれにせよ Exit Node には通信内容が丸見えのため注意が必要である。

XHTML Vocabulary と accesskey属性

2013年03月19日

HTML を記述している中でa要素のaccesskey属性 の命名基準を何にするかはかなり迷う。accesskey属性の順番ごとに1,2,3と連番にしてもよいのだが、これでは余りにも味気ない。

どうせなら XHTML Vocabularyaccesskey属性を対応付けられないかと思う。例えば rel="prev" ならば accesskey="p"rel="next" ならば accesskey="n" のようにすればアクセシビティも向上するというもの。

そんなわけでして、私が作った対応表が以下の様のもの。

XHTML Metainformation Vocabulary と accesskey の対応付け表
XHTML Vocabularyaccesskey
authora
contentsc
citeq
copyright, licenser
glossaryg
firstf
helph
indexi
lastl
prevp
nextn
start, topt
upu

XHTML Vocabulary の中には author というプロパティは存在しないが、そのページを作成した作者のページというのはよく利用するリンクだと思うのでこの表の中にも含めた。

XHTML Vocabulary には存在するもののこの表の中にはないプロパティーがある。具体的には alternate, appendix, bookmark, chapter, icon, itsRules, p3pv1, role, section, stylesheet, subsection である。

まず alternate, icon, p3pv1, itsRules が無い理由については、これらのプロパティの参照先はユーザー自身が直接参照するものではなくウェブブラウザーなどが自動的に読み込むべきものだからである。よってaccesskeyを割り当てる必要はないと考える。

bookmark, chapter, section, subsection などのプロパティはページ内で一回だけ記述するものではなく、何回も記述するためaccesskey属性と相性が悪い。よって accesskey を割り当てる必要はないと考える。