原文では"That makes sense — but our data should be readable by us, too."（これはなるほどそうだろうが、しかし、我々のデータは我々にも読めるべきだ。）と書いてありますね。Googleがユーザから収集したデータを当該ユーザが取得できるようにしているとしても、当該ユーザがその内容を理解できないと意味ないよね、ということ。そのためには、Googleが（あるいはサードパーティが）データを一般ユーザが解読できるようにするためのツールを提供するだのでもいいはず。
"Many files in my archive were odd formats that were not easy to open or read."なので、拡張子のことではなくファイル形式のこと。（一般人には）見慣れない形式で簡単には開くことも読むこともできない、という趣旨かと。その一例としてJSONの拡張子のついたファイルが挙げられている。
New York Times記事も大概 (スコア:0)
東洋経済の元の翻訳がどうだったかは不明ですけど、New York Timesの元記事も大概ひどいと思う。（"odd formats"って言っているし）
ロケーション履歴が格納されているJSONファイルが、
って、普通でしょうが。逆に「座標とタイムスタンプのリスト」以外にどう格納しろと？
JPEGファイルで提供しろとでも言うんだろうか。
New York Times記事は読んでないけど (スコア:2)
原文は「JSONなる機械可読形式で提供されているが、個人の権利を守るためとして理想論を言えば人間可読な形式で表示できるべき」という論調だったとか誰かが。
その意図を丸々落としてしまった結果が「なんだかよくわからんあれにこうなっている、気味が悪い」だったとかなんとか。
# 雑
Re:New York Times記事は読んでないけど (スコア:2)
原文では"That makes sense — but our data should be readable by us, too."（これはなるほどそうだろうが、しかし、我々のデータは我々にも読めるべきだ。）と書いてありますね。Googleがユーザから収集したデータを当該ユーザが取得できるようにしているとしても、当該ユーザがその内容を理解できないと意味ないよね、ということ。そのためには、Googleが（あるいはサードパーティが）データを一般ユーザが解読できるようにするためのツールを提供するだのでもいいはず。
東洋経済の「納得のいく説明だが、ユーザー自身が理解しやすいフォーマットにすることも重要ではないのか。」という和訳は、勝手にフォーマットに言及しているので、和訳としておかしいのです。
Re: (スコア:0)
「フォーマット」がどこまでの射程なのかによるのでは？
JSONというコンテナフォーマットだけとみるならその通りだけど、その中に入ってる、いわば「GPS座標が記されたJSON」を「ユーザのわかりやすい座標（市町村？無理があるけどな）の書かれたJSON」にするのも、フォーマットの話では。
スキーマ、というべきかな？
Re:New York Times記事は読んでないけど (スコア:1)
そこを書き換えたところでこの著者が納得するとは思えないですけどね。一般人にはなじみのないファイル形式で提供されることを含めて問題視してますし（ただし、これをファイル形式を変えろと言ってると読むのは読み込みすぎ）。
Re:New York Times記事は読んでないけど (スコア:1)
JSONってそこまで機械可読によってるか？
XML Schema理解しないと読めやしないXMLと超簡単YMLの中間ぐらいの人間可読性だと思うんだが。
効率で言えば、パックド形式、圧縮とか他に方法はあるし。
Re:New York Times記事は読んでないけど (スコア:1)
XMLは何らかのパーサーを通さないと、一つの値を取り出すのも大変だけど、JSONなら区切り字目安に切り出してもなんとかならないか？
Re: (スコア:0)
区切り文字目安でやればいい程度の処理なら、
XMLだってタグ目安に切り出せば十分じゃんよ
Re: (スコア:0)
API用JSONはだいたい改行が省略されてるので読みずらいのは間違いない。
人間可読のためにテキストで始まり、普及後最適化して難読になるけど効率ではバイナリに及ばない、
という中途半端なパターンがプロトコルフォーマットでは何故かお定まり。
Re: (スコア:0)
Re: (スコア:0)
改行が省略されてたって、ブラウザのデバッグモードでリクエストやレスポンスのJSON拾ってきて、Pythonのdict型変数に突っ込んで、keyとvalueをリスト化した上で、ループで回して表示させれば良いだけだろ。
読み辛いって程じゃない。
Re: (スコア:0)
Pythonにかけるまでもなく今どきのブラウザの開発者モードJSONをプリティプリントできるのでは…？
Re: (スコア:0)
いずれにせよツール使ってデコードすれば読み易いで良いならバイナリでいい、
と悟るとProtocl Buffer とか HTTP/2 とかになる。
Re: (スコア:0)
× 読みずらい
○ 読みづらい
#ヅラ警察
Re: (スコア:0)
ですよね。JSONってかなり人が読みやすいフォーマットなんですけどねぇ
XMLなんて複雑すぎて読む気起きないし。
開業ない奴は成形ツールかければきれいに成形してくれるから問題なし。
Re: (スコア:0)
ブラウザのDevToolsで簡単にツリー表示してもらえるからむしろ読みやすくてありがたい方だな
Re: (スコア:0)
結論は大昔に出てる。
XML+XSLT=XHTML。
ブラウザで開ける。
ついでにXML Schemaがあればもっと便利。
Re: (スコア:0)
別にフォーマットはJSONファイルでもXMLでもCSVでもいいんだが、一般人は数字の羅列を見せられてもどこまで把握しているのか分からず、安心してもらえないというのも事実なので、そもそもGoogleがこんなことをやっている目的を考えると必ずしも正しいやり方とは言えない。
JSONの生データを取り込んでGoogle Mapsに表示してくれる簡単なウェブアプリを提供すればTimesの著者も満足するんじゃないか。
Re: (スコア:0)
何言ってんの？
ユーザフレンドリーなサービスはgoogle自体がwebやアプリで提供してるじゃん
その生データを開示請求できることに意味があるの
無駄な加工を加えて情報量を減らしてはならない
Re: (スコア:0)
肩を持つわけでもないけど、oddって日本語に訳すとき結構難しいと思うよ。
奇妙なって訳が多いけど、ニュアンス的には規則性が違うとか、他とは違うみたいな意味合いもあるし、時々とか約みたいな意味に発展することもあるしで、原文書いた人が4文字拡張子だったら、oddって表現使った可能性もあるし。
Re:New York Times記事も大概 (スコア:1)
"Many files in my archive were odd formats that were not easy to open or read."なので、拡張子のことではなくファイル形式のこと。（一般人には）見慣れない形式で簡単には開くことも読むこともできない、という趣旨かと。その一例としてJSONの拡張子のついたファイルが挙げられている。
Re: (スコア:0)
翻訳としては、原意を分かりやすく伝える、良くできた翻訳だと思うんだよね。
実際、東洋経済の初出の記事と、書き換えられた現在の記事を見比べても、それほど内容に変わりはない。
変わったのは見出しの部分で「聞いたことのないファイル」であるとか「気味の悪い拡張子」とかいう見出し（これは東洋経済が独自につけたもののようだ）を、おとなしい表現に変えた程度。
ただ、この変える前の見出しが極端な表現かと言われると､､､なんせ原文が"odd formats"とか言っちゃてるわけだから、むしろ前のほうが分かりやすかったのではないかと思ったりする。
問題があるとすれば、こんなどうしようもない記事を掲載するよう選択してしまった、東洋経済の責任者だろう（翻訳者と同一の可能性もあるが）。
翻訳自体は良く出来ており、原意も正しく伝わるが、そのもともとの原意がどうしようもなかったって話だろう。
なんかもとの英文自体が、ヨボヨボの爺さんが世を憂いて書いたものであるか、世の中知らない（調べない）高校生のすねた作文みたいなものなので、どう翻訳してもどうしようもなかったのではないだろうか。