メタデータと密着した画像管理システム。例えば複数の画像から一つの画像に合成したら dc:source 使って元の画像の URI を記録しておくとか。ライセンスも画像に一緒に記録しとけば一番いいはず。
更にキーワードとかを書いておけば画像を検索できたりとか。
結局のとこ、Flickr に似たような感じになるわけだけども……
動かない。sabcmd は (たぶん) 動いてるけど、Ruby の sablot 作ろうと (ruby extconf.rb で) すると libsablot.a で大量にエラーが出る。検索しても何か妙に情報なし。壮大な勘違いでもしてるんだろうか?
ローカルにこれ入れられないといちいち XREA にうぷしてやらなきゃいけない……嫌だ。wakewakame.
とりあえず中途半端だけど書いた。画像に含まれる RDF を抽出して表示するだけ。そのうちちゃんと整形させたい。
nulog の画像参照については全部こっちにリンクが張られるようにした。nulog のデータの href とか src はそのままにして、img を含むリンクや、img 単体が存在する場合に view-img を付けてリンクをはる (はりなおす)
URI が微妙だよなぁ……もっといい感じにならないかなぁ。
特定ディレクトリ以下の画像を一覧表示 (サムネイルで。なければない旨の画像? サイズもちゃんと書いておいて条件分岐? 面倒) とかも面白いかなぁ……形にならないとよくわからない。
なんかエラーでるので原因を特定すると、foaf:nick に rdf:Alt があるとエラーになる。FOAF Explorer の XSLT を見てみると <xsl:template mode="title" match="*"> というテンプレートの中身が悪さしてる。xsl:choose で選択しているので上のほうに書いてある要素で rdf:Alt を含まなければエラーにならないんじゃないかと思ってやってみたらヒット。foaf:name は書いていなかったので適当に書いておいた。この回避法だと foaf:name を既に書いていてエラーが出る場合無理。あっちの対策を待ちましょうみたいな?
でもこっちで回避するより何かフィードバック送ったほうがいいだろうなぁ。っていっても既に誰か送ってると思うんだけど……むしろエンジンのエラーな気がする。
マジメな実装をするなら name() を select や @test で使う機会はまずないはず。 (もちろん name() をそのまま出力する用途では使うけど) そのかわりにちゃんと namespace-uri() と local-name() を使うはずだから。
今まで name() を使うときなんかひっかかりつつ使っていたけどやっと変なことに気付いた。
今まで散々 namazu と書いてきましたが、全部 Namazu の意味です。コマンドラインなんてつかたことない。
予め xmlns:t="http://temporary/" とかやっておく。既存の空間が利用できるならそれ使ってもいいと思う。
<xsl:call-template name="tempfoo"> <xsl:with-param name="foo" xmlns="http://temporary/"> <foo>Foo</foo> <foo>Bar</foo> </xsl:with-param> </xsl:call-template>
<xsl:template name="tempfoo"> <xsl:param name="foo"/> <ol> <xsl:for-each select="$foo/t:foo"> <li><xsl:value-of select="."/></li> </xsl:for-each> </ol> </xsl:template>
<ol> <li>Foo</li> <li>Bar</li> </ol>
渡すほうに名前空間を指定しない場合は、(あたりまえだけど) デフォルトの空間になる。でもそのまま template のほうで接頭辞なしでアクセスしようとしても無理。
できないと思ってた方法ができると分かって、いろいろ楽できる! 諦めかけていたなか光をくれた (謎) 哀さん にありがとう
namazu スタイルシートをつくるときに、一個の option 要素ごとに selected を入れるかの if を作るのが面倒でごちゃごちゃやってた。だいぶスッキリしていい感じ。
ソース間違ってたのをちょっと修正。
少し修正してだいぶやる気がなくなったので適用。公開するとまたアレな部分がいっぱい見えてくる。不思議だ。
タイトルフォントについて書くのを忘れてた……
NULL の部分は Amerika Sans。残りの部分は Brie Light っつうフォントどす。
なんか殆どできちゃったけどまだ適用しない。IE の :first-child 非対応の対策のために元のマークアップを少し変えて (新しく class を導入) しまった。
結局配色について殆ど考えなかった。というか画像を今のスタイルから流用しているから、全体的に殆ど今のまま。
アクセシビリティツールもまだ使ってない。白ベースの青と黒だから殆ど問題ないと思うけどやっぱやってみなくちゃなぁ。
ColorDoctor を使って検証してみたけど、とりあえず大丈夫みたいだ。
それより、この ColorDocter メモリ : 256MB以上 (推奨 : 2GB以上)
って書いてあって 2GB 以上は嘘だろう、とか思ってたら本気でメモリ足りなくなった。むしろ最初起動すらしなかった。起動したと思ったら Firefox が落ちた。どこにそんなメモリ使ってんだろ…….Net だからっすか。
テンプレートに XSLT を使う namazu.cgi の代替を書いて置き換えた。これで namazu だけ HTML4.01 だったり、適用している CSS が違うということがなくなった。
Ruby 拡張ライブラリの search-namazu を使ってクエリ投げて、いったんデータを XML に変換。んでそれを XSLT エンジンに渡してやる。
遠回りだけど、namazu のやつだけ統一感がないのはいくないからこれでよし。もちろん common.xsl が適用されているからスタイルシート追加したきゃ common.xsl を書き換えるだけ。全部変わる!
あーそうだ。Ruby 用の XSLT エンジンがなかったから sablot を使った。何か CGI 経由でコンパイルするっていう方法がずっと頭から抜けてて、Ruby で XSLT エンジンつかえないじゃん!って思ってた。想像力が減ってる。だめだ。
いくつか目標的な何か
そんなわけで CSS Vault とかでパクる参考にするサイトを探す。もっと綺麗な方向にしたい……
なんか細々したグラデーションとボーダー (not CSS) が流行ってるみたいだからパクろう。うん。
なにやら w3.org ドメインにあるじゃないですか! っていってもどれほど使えるかわかりませんけど……
namazu 検索エンジン の夢を見た。namazu はある大学の一つの建物で、中がかなり広い。namazu は工事中らしい。中に入るとコンクリート片やらパイプやらが散らばっている。中に入っていくつかの部屋を抜ける間に何人かの学生を見た。何をしていたかは知らない。かなり中のほうの部屋までいった。そこでパイプの残骸を見つめて、そこで目が覚めた。
coLinux をインスコして Debian を弄ってみる。わかんないこと多すぎだけどとりあえず手探りで……とりあえず仮想的にコンピュータがもう一個あるのは遊べるなぁ。最初にやったのはころがってるチュートリアル見ながら SSH の設定と環境構築 (zsh インスコとか)
一通り KDE とかインスコしてみて VNC で遊んだので Apache をインスコ。
何となく WebDAV って楽しそうじゃん?とか思って mod_dav をインスコ。しかしながら XP SP2 の Web フォルダでは HTTPS でないと Basic 認証ができないらしく mod_ssl を入れる。ついでにログイン時のユーザ名がわけわかになって絶対認証に失敗するので Web Client サービスをとめる。
なんかできたっぽいかなと思ったので、この状態でこのウェブサーバに外部から接続するにはどうしたらいいだろうと考えた。普通の HTTP はホストコンピュータ上の Apache からバーチャルホスト設定 (ホストの Apache はそのまま使うため) と内部 Proxy 使っていってらっしゃい。SSL のほうは TCPTunnel 使ってポートフォワーディング。めでたしめでたし。
xyzzy のキーバインドを一部覚えててよかった。
画像に埋め込んであるだけだといちいち編集するのが面倒なので、簡単な管理方法を考えた。っていっても firefox.png に対して firefox-meta.rdf というファイルを作っておいてスクリプトで一括合成させるだけのものだけど……
本当は firefox.rdf にしようと思ったけど、そのままアップロードしたとき MultiViews のネゴシエーションで RDF のほうが優先されて困るので -meta というサフィックスをつけた。playing.xml を変換するスタイルシートに playing-style.xsl と同じような雰囲気。
むしろ画像データ (firefox.png) をリクエストしてメタデータ (firefox.rdf) が返ってくるは少し変な気もする。いやでも firefox.png はメタデータを含んでいるし、image/png を受け入れないなら RDF を返してもいいか。実際 W3C もそういう方法 (photoRDF) を考えているみたいだし……
なんかこういうのを見つけて仕様 (PDF) を見てみたけど、XML である意味が薄いところが多々あると思う。それと仕様が緩くて仕様の意味が薄かったり、そもそもアプリケーション間のエクスポート・インポートにしか使えない。手で書いたとき creator 属性には何を入れればいいんだろう? 想定外なんだろうけど、メールで XML を送ってインポートさせてあげられれば相手の手間が省けるんじゃないかなぁ。
なんていうか ExtensionItem なんて要素作らずにアプリケーション個別の拡張のためなら独自のネームスペースでやればいいのになぁとか思った。せっかく eXtensible なのに……何か理由があるんだろうか。