パスワードを忘れた? アカウント作成

yasuokaさんのトモダチの日記みんなの日記も見てね。 Idle.srad.jpは、あなたの人生において完全な時間の浪費です。見るなよ、見るなよ。

13887396 journal
人工知能

yasuokaの日記: 望遠鏡は「望遠」「鏡」なのか「望」「遠鏡」なのか

日記 by yasuoka

AdobeのNLP-Cube1.0.5に、新たなモデル1.1がリリースされたとの御連絡をいただいたので、とりあえず日本語モデル1.1をインストールしてみた。

% pip3 install nlpcube
% python3
>>> from cube.api import Cube
>>> Cube(verbose=True).load("ja",1.1)
>>> quit()

wiki.ja.vecをダウンロードしなくなっているので、インストールがそこそこ早い。試しに「望遠鏡で泳ぐ彼女を見た」を解析してみよう。

% python3
>>> from cube.api import Cube
>>> ja_nlpcube=Cube(verbose=True)
>>> ja_nlpcube.load("ja",1.1)
>>> from cube.io_utils import conll
>>> d=conll.Dataset()
>>> d.sequences=ja_nlpcube("望遠鏡で泳ぐ彼女を見た")
>>> d.write_stdout()

この結果、私(安岡孝一)の手元では、以下のUniversal Dependenciesが出力された。

1 望 望 NOUN _ _ 2 compound _ SpaceAfter=No
2 遠鏡 遠鏡 NOUN _ _ 4 obl _ SpaceAfter=No
3 で で ADP _ _ 2 case _ SpaceAfter=No
4 泳ぐ 泳ぐ VERB _ _ 5 acl _ SpaceAfter=No
5 彼女 彼女 PRON _ _ 7 obj _ SpaceAfter=No
6 を を ADP _ _ 5 case _ SpaceAfter=No
7 見 見る VERB _ _ 0 root _ SpaceAfter=No
8 た た AUX _ _ 7 aux _ SpaceAfter=No

うーん、望遠鏡が「望」←compound─「遠鏡」になってしまっていて、かなりマズイ。以前の日本語モデル1.0に比べても、残念ながら精度が下がっているように見える。やっぱりwiki.ja.vecを使わないと、未知語が増えちゃうのかなぁ。

13882699 journal
人工知能

yasuokaの日記: 日本語係り受け解析エンジンとしてのNLP-Cube

日記 by yasuoka

AdobeのNLP-Cube1.0.5のベクトル・ダウンロード回りが治った、との連絡をいただいた。昨日の日記に続いて、NLP-Cubeの日本語モデルもインストールしてみよう。

% pip3 install nlpcube
% python3
>>> from cube.api import Cube
>>> Cube(verbose=True).load("ja")
>>> quit()

巨大なwiki.ja.vecを筆頭に、あちこちから色んなモノを取ってくるので、とにかくダウンロードに時間がかかるが、一回だけ我慢することになる。次に、インターフェースの準備。

% python3
>>> from cube.api import Cube
>>> ja_nlpcube=Cube(verbose=True)
>>> ja_nlpcube.load("ja")
>>> def nlpcube2ud(sentence):
...   return("".join("".join("\t".join([str(t.index),t.word,t.lemma,t.upos,t.xpos,t.attrs,str(t.head),t.label,t.deps,t.space_after])+"\n" for t in s)+"\n" for s in ja_nlpcube(sentence)))
...
>>>

NLP-Cubeを使って、Universal Dependenciesを返す関数が、これで準備できたことになる。どうせなので、私(安岡孝一)の「SVGによるUniversal Dependencies可視化ツール」にも繋いでみよう。

>>> def svgviewer(ud):
...   import urllib.parse,webbrowser
...   webbrowser.open("http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kyodokenkyu/ud-kanbun/conllusvg/viewer.svg#"+urllib.parse.quote(ud))
...
>>>

これで、関数の準備は完了だ。では「望遠鏡で泳ぐ彼女を見た」を、試しに解析してみよう。

>>> u=nlpcube2ud("望遠鏡で泳ぐ彼女を見た")
>>> print(u)
>>> svgviewer(u)

この結果、私の手元では、以下のUniversal Dependenciesが出力されると同時に、こんな感じのSVGが表示された。

1 望遠鏡 望遠鏡 NOUN _ _ 6 obl _ SpaceAfter=No
2 で だ AUX _ _ 1 case _ SpaceAfter=No
3 泳ぐ 泳ぐ VERB _ _ 4 acl _ SpaceAfter=No
4 彼女 彼女 PRON _ _ 6 obj _ SpaceAfter=No
5 を を ADP _ _ 4 case _ SpaceAfter=No
6 見 見る VERB _ _ 0 root _ SpaceAfter=No
7 た た AUX _ _ 6 aux _ SpaceAfter=No

正しく「望遠鏡←obl─見」となっているのが、素晴らしい。ただ、NLP-Cubeは「で」がAUX(助動詞)になってしまっていて、このあたりが「あと一息」だったりする。ちなみにNLP-Cubeは、wiki.ja.vecを必要としないバージョンを開発中らしいので、個人的には楽しみである。

13881856 journal
人工知能

yasuokaの日記: 日本語係り受け解析エンジンとしてのGiNZA・StanfordNLP・UDPipe

日記 by yasuoka

GiNZA1.0.2が一昨日リリースされたので、StanfordNLP0.1.2およびUDPipe1.2.0と比較してみることにした。とりあえずは、python3.7とpip3で、日本語モデルのインストール。

% pip3 install 'https://github.com/megagonlabs/ginza/releases/download/v1.0.2/ja_ginza_nopn-1.0.2.tgz'
% pip3 install stanfordnlp
% python3
>>> import stanfordnlp
>>> stanfordnlp.download('en')
>>> stanfordnlp.download('ja')
>>> quit()

あちこちから色んなモノを取ってくることになるので、とにかくダウンロードに時間がかかるが、一回だけ我慢することになる。ここではUDPipeはインストールせずに、LINDAT/CLARINのサーバAPIを使うことにしよう。次に、各モデルのインターフェースの準備。

% python3
>>> import spacy
>>> ja_ginza=spacy.load("ja_ginza_nopn")
>>> def ginza2ud(sentence):
...   from spacy.lang.ja_ginza.cli import token_line
...   return("".join("".join(token_line(t,{})+"\n" for t in s)+"\n" for s in ja_ginza(sentence).sents))
...
>>> import stanfordnlp
>>> ja_stanfordnlp=stanfordnlp.Pipeline(lang="ja")
>>> def stanfordnlp2ud(sentence):
...   from stanfordnlp.models.common import conll
...   return(ja_stanfordnlp(sentence).conll_file.conll_as_string())
...
>>> def udpipe2ud(sentence):
...   import urllib.parse,urllib.request,json
...   with urllib.request.urlopen("http://lindat.mff.cuni.cz/services/udpipe/api/process?model=japanese&tokenizer&tagger&parser&data="+urllib.parse.quote(sentence)) as r:
...     q=r.read()
...   return(json.loads(q)["result"])
...
>>>

GiNZAとStanfordNLPとUDPipeで、それぞれUniversal Dependenciesを返す関数が、これで準備できたことになる。試しに「望遠鏡で泳ぐ彼女を見た」を解析してみよう。

>>> s="望遠鏡で泳ぐ彼女を見た"
>>> print(ginza2ud(s))
>>> print(stanfordnlp2ud(s))
>>> print(udpipe2ud(s))
>>>

この結果、私(安岡孝一)の手元では、以下の3種類のUniversal Dependenciesが出力された。

1 望遠鏡 望遠鏡 NOUN 名詞-普通名詞-一般 _ 3 nmod _ SpaceAfter=No
2 で で ADP 助詞-格助詞 _ 1 case _ SpaceAfter=No
3 泳ぐ 泳ぐ VERB 動詞-一般 _ 4 acl _ SpaceAfter=No
4 彼女 彼女 PRON 代名詞 _ 6 obj _ SpaceAfter=No
5 を を ADP 助詞-格助詞 _ 4 case _ SpaceAfter=No
6 見 見る VERB 動詞-非自立可能 _ 0 root _ SpaceAfter=No
7 た た AUX 助動詞 _ 6 aux _ SpaceAfter=No

1 望遠鏡 望遠鏡 NOUN _ _ 3 obl _ _
2 で で ADP _ _ 1 case _ _
3 泳ぐ 泳ぐ VERB _ _ 4 acl _ _
4 彼女 彼女 PRON _ _ 6 obj _ _
5 を を ADP _ _ 4 case _ _
6 見 見る VERB _ _ 0 root _ _
7 た た AUX _ _ 6 aux _ _

# newdoc
# newpar
# sent_id = 1
# text = 望遠鏡で泳ぐ彼女を見た
1 望遠鏡 望遠鏡 NOUN NN _ 6 obl _ SpaceAfter=No
2 で で ADP PS _ 1 case _ SpaceAfter=No
3 泳ぐ 泳ぐ ADV RB _ 6 advmod _ SpaceAfter=No
4 彼女 彼女 PRON NP _ 6 obj _ SpaceAfter=No
5 を を ADP PS _ 4 case _ SpaceAfter=No
6 見 見る VERB VV _ 0 root _ SpaceAfter=No
7 た た AUX AV _ 6 aux _ SpaceAfter=No

上から順に、GiNZA、StanfordNLP、UDPipeの結果である。正しく「望遠鏡←obl─見」となっているのはUDPipeだけで、GiNZAもStanfordNLPも現状では解析しきれていない。ただ、UDPipeは「泳ぐ」がADV(副詞)になってしまっており、これはこれでマズイと思う。うーん、今のところ一長一短だなぁ。

13880198 journal
日本

yasuokaの日記: 「駆け抜ける」と「走り切る」は複合動詞なのか動詞連続なのか

日記 by yasuoka

一昨日以来GiNZA (Ver.1.0.1令和版)と戯れていたのだが、どうも妙なUniversal Dependenciesが出力されるのに気づいた。たとえば「都大路を駆け抜けてゴールまで走り切った」という文に対し

% python3
>>> import spacy
>>> from spacy.lang.ja_ginza.cli import token_line
>>> ja=spacy.load("ja_ginza_nopn")
>>> d=ja("都大路を駆け抜けてゴールまで走り切った")
>>> u="".join("".join(token_line(t,{})+"\n" for t in s)+"\n" for s in d.sents)
>>> print(u)

で依存文法解析をおこなうと、以下のUniversal Dependenciesが出力される。

1 都大路 都大路 NOUN 名詞-普通名詞-一般 _ 3 obj _ SpaceAfter=No
2 を を ADP 助詞-格助詞 _ 1 case _ SpaceAfter=No
3 駆け抜け 駆け抜ける VERB 動詞-一般 _ 8 advcl _ SpaceAfter=No
4 て て SCONJ 助詞-接続助詞 _ 3 mark _ SpaceAfter=No
5 ゴール ゴール VERB 名詞-普通名詞-サ変可能 _ 8 nmod _ SpaceAfter=No
6 まで まで ADP 助詞-副助詞 _ 5 case _ SpaceAfter=No
7 走り 走る VERB 動詞-一般 _ 8 aux _ SpaceAfter=No
8 切っ 切る VERB 動詞-非自立可能 _ 8 root _ SpaceAfter=No
9 た た AUX 助動詞 _ 8 aux _ SpaceAfter=No

8 root」となっている部分に関しては、ちゃんと「0 root」となるようパッチを当ててもらったのだが、問題は「走り←aux─切っ」のauxだ。もし、「走り切る」を動詞連続(serial verb construction)だとみなすなら、auxではなくcompound:svcあたりを使うべきだろう。ただ、それは「駆け抜け」を、いわゆる複合動詞(compound verb)とみなして、一語として処理していることとと、スジが合わない気がするのだ。何というか、どっちつかずなのだが、さて、こういうの、どうしたらいいんだろ?

13878689 journal
人工知能

yasuokaの日記: GiNZAが出力したUniversal DependenciesをSVGで可視化する

日記 by yasuoka

リクルートMegagon LabsがGiNZA日本語UDモデル(Ver.1.0.1令和版)をリリースしたので、私(安岡孝一)の「SVGによるUniversal Dependencies可視化ツール」に繋いでみることにした。GiNZA日本語UDモデルは、spaCy上での日本語自然言語オープンソースライブラリで、pip3とpython3があれば

% pip3 install 'https://github.com/megagonlabs/ginza/releases/download/v1.0.1/ja_ginza_nopn-1.0.1.tgz'

だけでインストールできて、係り受け解析の結果をUniversal Dependenciesで出力可能である。たとえば「心を労する者は人を治める」という文に対する係り受け解析は

% python3
>>> import spacy,urllib.parse,webbrowser
>>> from spacy.lang.ja_ginza.cli import token_line
>>> h="http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kyodokenkyu/ud-kanbun/conllusvg/viewer.svg"
>>> ja=spacy.load("ja_ginza_nopn")
>>> d=ja("心を労する者は人を治める")
>>> u=""
>>> for s in d.sents:
...   for t in s:
...     u=u+token_line(t,{})+"\n"
...   u=u+"\n"
...
>>> print(u)
>>> q=urllib.parse.quote(u)
>>> webbrowser.open(h+"#"+q)

とやれば、python3からブラウザが起動してきて、こんな感じのSVGが表示されるはずである。「心←iobj─労する」がiobjなのかobjなのかについては、多少議論があるとは思うのだが、まあ、そこそこいい結果が出ているように思う。ただ、GiNZAは日本語専用で、漢文(古典中国語)には応用できそうにないのが、ちょっと残念。

13876449 journal
日本

yasuokaの日記: 「令和」の典拠は日本古典なのか漢籍なのか

日記 by yasuoka

私(安岡孝一)の昨日の日記の複数の読者から、「令和」の典拠は日本古典なのか漢籍なのか、という趣旨の御質問を複数いただいた。いや、その、漢文(古典中国語)って本質的にコピペ文化なので、どれが典拠とか普通はわからないと思う。

試しにKanripoで「令和」を文字列検索してみると、こんな感じ。古いところだと、『撰集百縁經』卷一の佛説法度二王出家縁に「能令和解」という用例があるらしい。この用例における「和」は「知」の別体なのではないか、とする説があるものの、とりあえず、私が返り点を打つなら「能令解」あたりだろうか。

一方で、『萬葉集』卷五の「初春令月、氣叔風和」には、たぶん返り点が要らないと思う。その点では、まあ『萬葉集』の方が、日本人好みなんじゃないかなぁ…。

13875326 journal
エイプリルフール

yasuokaの日記: 新元号は「令和」に、施行は5月1日 199

日記 by yasuoka

次の元号が「令和」に決まった。施行は5月1日を予定している。合字の文字コードとしては、U+337E「㍾」U+337D「㍽」U+337C「㍼」U+337B「㍻」と来て、次はU+32FF「㋿」を予定しているが、5月1日に間に合うかどうかは微妙なセンである。お急ぎの方は、多少、形は違うもののU+29841「𩡁」を使われたい。

13873519 journal
NTT

yasuokaの日記: Re: NTT西日本が考えるQWERTY配列の歴史

日記 by yasuoka

「パソコンのキーボードは,なぜABC順・五十音順ではないのですか」の読者から、NTT西日本のチエネッタの記事「キーボードの配置のルーツとキーの役割を知ろう」(ネットのいろは、vol.21、2019年3月28日)を読んでほしい、との御連絡をいただいた。読んでみたのだが、QWERTY配列に関するガセネタが並べ立てられていて、かなり閉口した。

不規則なQWERTY配列になった理由って何?
ではなぜこのような不規則な配置になったのでしょうか。確実な根拠のある理由はわかっていないようですが、諸説あるうちのいくつかを下記にまとめました。

  • タイプライターのセールスマンが顧客に対してプレゼンテーションを行う際に素早く美しく「typewriter」と打鍵を披露できるようにしたものだという説(最上段のキーのみで全ての文字の入力が可能)
  • 早く打ちすぎるとタイプバーが絡まるため、敢えて打ちにくい配列にした説
  • ERやTRなどよく使用するキーを左に配置することによりタイプバーの絡みを防止しようとした説
  • 市場を独占するためにタイプの練習が必要な配列にし、他社製品の乗り換えを防ごうとした説

※他にも様々な諸説があります。

「諸説があります」と書いたからって、ガセネタばかり並べ立てていいはずがないだろう。4年前のネットの知恵袋もほったらかしで、なに考えてるんだNTT西日本。とりあえず、順に見ていこう。

タイプライターのセールスマンに関しては、2009年9月18日の日記にも書いたとおり、電信会社や速記学校などへの持ち込みとデモンストレーションによって成り立っており、かなりシビアなものだった。そもそも「typewriter」なんて小文字で打てるはずがないし、打ってみせたところで買ってくれない。馬鹿馬鹿しいにもほどがある。

「タイプバー」の絡みについては、そもそもアップストライク式タイプライターの「タイプバー」は絡んだりしない。現実の「タイプバー」の配置がどうなっているかについては、「ECONOトリビア」QWERTY記事顚末記に示しておいたので、ちゃんと確認するように。

「市場を独占するためにタイプの練習が必要な配列にし」というのは、さすがにナンセンスにもほどがある。Union Typewriter(つまりはTypewriter Trust)によるタイプライター市場の独占は、株の買い占めと、持株会社の設立によっておこなわれたものだ。しかも、Union Typewriterによる市場独占は、私(安岡孝一)の見る限りでは15年も続かず、後発のUnderwood Typewriterに取って代わられている。キー配列ごときで、製品の乗り換えを防げるわけがない。

「キーボード配置のルーツとキーの役割を知ろう」というタイトルなら、ちゃんと「諸説」じゃないルーツを調べるべきだろう。それが出来ないのなら、こんなチエネッタなんてサイト、さっさとやめてしまうべきだと思う。

13869401 journal
政府

yasuokaの日記: 改正戸籍法、全ての戸籍を法務大臣が一元管理 75

日記 by yasuoka

国会で審議中の改正戸籍法により、全ての戸籍の副本(コピー)を法務大臣が一元管理することが明らかになった。これまで戸籍およびその副本は、各市区町村と全国の法務局で分散管理してきたが、今回の改正は、これをデジタル化して法務大臣に一元化するもの。同時にマイナンバー法も改正され、全ての戸籍が「情報提供用個人識別符号」と紐づけられると同時に、法務大臣が「個人番号利用事務実施者」の適用除外となる。したがって改正後、法務大臣は、個人情報保護委員会の監督・保護評価を受けずに、自由に全国民のデジタル戸籍を利用可能となる。「特定個人情報保護評価」も適用除外となるため、国民への「パブリックコメント」も実施されない。施行は改元後を予定。

13868825 journal
政府

yasuokaの日記: 番号利用法第二十六条による条例事務関係情報照会者・条例事務関係情報提供者への準用

日記 by yasuoka

昨日の日記

やはり、条例事務関係情報照会者と条例事務関係情報提供者を、あえて外す方向で法改正しようとしているように見える。

と書いたのだが、これは私(安岡孝一)の読みが足りなかった。ごめんなさい。番号利用法の第二十六条が

第二十六条 第二十一条(第一項を除く。)から前条までの規定は、第十九条第八号の規定による条例事務関係情報照会者による特定個人情報の提供の求め及び条例事務関係情報提供者による特定個人情報の提供について準用する。この場合において、第二十一条第二項第一号中「別表第二に掲げる」とあるのは「第十九条第八号の個人情報保護委員会規則で定める」と、第二十二条第一項中「ならない」とあるのは「ならない。ただし、第十九条第八号の規定により提供することができる特定個人情報の範囲が条例により限定されている地方公共団体の長その他の執行機関が、個人情報保護委員会規則で定めるところによりあらかじめその旨を委員会に申し出た場合において、当該提供の求めに係る特定個人情報が当該限定された特定個人情報の範囲に含まれないときは、この限りでない」と、同条第二項中「法令」とあるのは「条例」と、第二十四条中「情報提供等事務(第十九条第七号」とあるのは「条例事務関係情報提供等事務(第十九条第八号」と、「情報提供等事務に」とあるのは「条例事務関係情報提供等事務に」と、前条中「情報提供等事務」とあるのは「条例事務関係情報提供等事務」と読み替えるものとする。

となっているので、新設される第二十一条の二は、この準用の範囲に含まれるのだ。つまり、条例事務関係情報照会者も条例事務関係情報提供者も、情報提供用個人識別符号を取得できる。ただし、情報提供用個人識別符号の取得の方法は、現在は個人番号(マイナンバー)から得られるのに対し、改正案(第二十一条の二第二項)では「取得番号」とかいう、何か別なものになっている。

 前項の規定による情報提供用個人識別符号の取得は、政令で定めるところにより、情報照会者等が取得番号(当該取得に関し割り当てられた番号であって、当該情報提供用個人識別符号により識別しようとする特定の個人ごとに異なるものとなるように割り当てられることにより、当該特定の個人を識別できるもののうち、個人番号又は住民票コードでないものとして総務省令で定めるものをいう。以下この条において同じ。)を、機構を通じて総務大臣に対して通知し、及び総務大臣が当該取得番号と共に当該情報提供用個人識別符号を、当該情報照会者等に対して通知する方法により行うものとする。

この「取得番号」というのは、あいかわらず私には理解できない。こんな「取得番号」なんて、法制審議会でも戸籍法部会でも議論された覚えがないのだが、どうして「戸籍法の一部を改正する法律案」に紛れ込んでるんだろう。あるいは、これも、私の読みが足りないせいなのだろうか?

typodupeerror

最初のバージョンは常に打ち捨てられる。

読み込み中...