2020年7月5日日曜日

Beautiful mountain view comes automatically to your smartphone

revised [Version2, 2020-7-5] [Version1, 2019-12-19]

Abstract
The purpose of this project is to create an application that uses AI (artificial intelligence) to determine that a mountain is now in a beautiful landscape, and automatically notify it to the smartphone. You can enjoy the scenery with a live camera even in a distant mountain. However, the mountains are often covered with clouds, and the weather changes over a short period of time. Therefore, there will not be many opportunities to see the beautiful scenery. The smartphone app described below will automatically notify you when a photo that is so beautiful that you can see it up to the top of the mountain is obtained. Wouldn't it be fun if you received such a notification while drinking coffee?

Outline of the project
The weather in the mountains changes in a short time. Therefore, the scenery is not always beautiful so that you can see the summit. Here, we have created an app that automatically stores only the photos in which the mountain summit is clearly visible. As an example, this app recognizes the scenery of Rishiri mountain that is towering in northern Hokkaido of Japan in real-time and saves good photos. This app incorporates a trained model of this mountain images, but of course, it is easy to replace them with your favorite mountain images. 

Preparing mountain images
For image recognition, we used MIT's Personal Image Classifier [1]. First, we should classify many photos of this mountain into four categories, as shown in Fig1, depending on how they look. For this purpose, we quote images of a live camera [2] installed at the foot of the mountain. Get the image at appropriate intervals and give it a category label, as shown in Fig.1 and Fig.2. For each label, it is good to have more than 10 images. Enter them into MIT's Personal Image Classifier via your PC's web browser.

Fig.1 Classification into four categories

Fig.2 Preparing images for classification training

Training of the recognition model
When the images are ready, perform training as shown in Fig.3. Training takes place on the Neural Network. Adjust the network structure and some hyperparameter values if necessary. At the scale of this example, training usually ends in tens of seconds. Then download the trained model to your PC and use it in the App Inventor program as shown below.

Fig.3 Train our own model using MIT Personal Image Classifier

Using the trained model in App Inventor
The extension (named personalimageclassifier.aix) for using the downloaded model in App Inventor can be obtained from the reference [1]. The usage is very simple as shown in Fig.4. First, set the downloaded model to the Classifier properties, and then give the image you want to recognize to the block for classifying. As a result of recognition, the degree to which the image should be classified into each label is shown. That is, you get a list of label/confidence pairs. Finally, the image is classified into the label with the highest confidence value.

Fig.4 Blocks of the Personal Image Classifier

Getting the weather forecast
Before using this app, it is better to check the weather forecast for this mountain. If the weather is too bad, you can't expect a good picture. Press the button shown in Fig.5 to automatically display mountain weather up to 6 hours ahead. The weather forecast requires parsing a JSON file from OpenWeatherMap [3]. So we use our own JSON Decoding Extension (named FoYoJSON.aix) [4]. Fig.6 provides an overview of it. In order to use OpenWeatherMap, you need to get your own API key.

Fig.5 Checking weather forecast

Fig.6 Getting and decoding weather forecast JSON file

Running the app
An example of running the app is shown in Fig.7. In this case, it was recognized as "Cloudy but looks good" because there are many clouds but the mountainside looks good. Such a case is normal and it is rare to see it well up to the top.

Fig.7 Get an image and then recognize

Automatic notification of good scenery
If you are lucky, you will encounter a scene where you can see the summit as shown in Fig.8. In such a case, the recognition results in "Clear enough to see the summit". In that case, You can know that in two ways. One way is to feel the vibration of your smartphone, another way is to receive an e-mail automatically. If you choose the latter, the recognized image is automatically sent to the registered mail ID. Whichever you choose, if you have a PC nearby you will be able to enjoy the larger, clearer images immediately on your PC screen rather than your smartphone.

Fig.8 Automatic notification of beautiful scenery via email

Probably the easiest way to send emails automatically without human intervention is to use Taifun's extension [5] shown in Fig. 9 but note that it is a paid extension. 

Fig.9 Using an extension to send emails via SMTP without user interaction

Notice
(1) If the live camera image of your choice has a high resolution, you may need to reduce the resolution and pass it to the image classifier.
(2) To get and display the weather forecast, you need your own API Key for OpenWeatherMap. 
(3) If Error_908 is displayed when running the app, please allow access to External_Storage on your Android settings.

References
[1] MIT's Personal Image Classifier
https://appinventor.mit.edu/explore/resources/ai/personal-image-classifier
[2] Live camera at Rishiri Town Hall (in Japanese)
http://www.town.rishiri.hokkaido.jp/rishiri/
[3] OpenWeatherMap
https://openweathermap.org
[4] JSON Decoding Extension by FoYo
http://sparse-dense.blogspot.com/2019/01/a-json-decoding-extension-for-app.html?m=0
[5] Taifun's mail extension (paid)
https://puravidaapps.com/mail.php

2020年7月2日木曜日

係り受け解析は格フレーム辞書に強く依存するらしい

【要旨】3つの係り受け解析器CaboCha、KNP、GiNZAを試用してみて、素人ながら分かってきたことが少しあります。それをここ簡単に書き留めておきたい。

■3種類の日本語係り受け解析器
 十分使い込んだとは言えませんが、これまでに、以下の3つの係り受け解析器を利用させていただきました。いずれも、なんらかの自動構築の格フレーム辞書を利用していると思われます。(その具体的な違いは小生には分かりませんが。)

 ・CaboCha(参考資料[1])
 ・KNP (参考資料[2])
 ・GiNZA(参考資料[3])

■2つの例文についての解析結果の比較
 今回は、以下の2つの例文について、3つの解析器の解析結果を比較してみます。

例文(ア):葉は葉柄の長い卵形である。
例文(イ):葉は虎柄の長い卵形である。


 まず、例文(ア)に対する結果をみます。KNPは、「葉柄の長い」という係り受け関係をきちんと捕らえていますが、CaboChaとGiNZAはいずれも、「長い卵形」と判断しており、妥当ではありません。


 次に、例文(イ)です。これは例文(ア)に出現する"葉"が"虎"に変わっただけです!それだけの違いであれば、係り受け解析結果は変わらないのでは?と思いませんか。結果はどうでしょうか。(ア)の場合の判定結果(○×)が逆転してしまいました。すなわち、KNPは、「虎柄の長い」という不自然な係り受け関係を採用してしまいました。


■格フレーム辞書が解析精度を左右する
 上記の解析は、一例(2つの例文のみの)に過ぎません。しかしながら、人間が理解するのと同じく(自然な)係り受け関係を見つけるには、格フレーム辞書(詳しくは参考資料[4][5]を参照)が重要な役割を果たしているようです。参考資料[5]には、「Webから自動構築する膨大な格フレーム辞書は、蓄積が高まれば効果が出てくる反面、どうしても雑音も入ってしまうので、結果的に解析精度は頭打ちになるだろう」という趣旨の記述があります。共感できるように思います。

■Google翻訳はどうなっているか
 最後に、上の2つの例文をGoogle自動翻訳(英訳)にかけてみました。妥当な英文を生成するには、適切な係り受け解析が必要なはずです。結論として、2例文とも、妥当な英文になっています。このことから、相当に優れた格フレーム辞書を使っていることが推察できます。

 Google翻訳結果:
例文(ア):葉は葉柄の長い卵形である。
 -> The leaves are oval with long petioles.
例文(イ):葉は虎柄の長い卵形である。
 -> The leaves are long ovals with a tiger pattern.

参考資料
[1] CaboCha/南瓜: Yet Another Japanese Dependency Structure Analyzer
[2] 日本語構文・格・照応解析システム KNP 
[3] GiNZA - Japanese NLP Library
[4] 杉本徹、岩下志乃:Javaで学ぶ自然言語処理と機械学習、オーム社、平成30年9月発行
[5] 山本和英:箱庭言語処理のための格フレーム辞書構築の意義

2020年7月1日水曜日

Thank you, AppyBuilder, for a long time!

In my long-time development of smartphone apps, MIT App Inventor and its derivatives, AppyBuilder, and Thunkable, have been very useful. Among them, AppyBuilder completely stopped its service yesterday (2020-6-30). AppyBuilder has continued to offer a uniquely designed GUI and new features.  I would like to express my gratitude to Hossein, who played a central role in this, and to the colleagues who had useful discussions in the community. My first Extension program (with JAVA) was created using the CodeEditor published by Hossein. As many know, AppyBuilder is already on a new path as Kodular. I look forward to further development in the future. Finally, to commemorate, here are some screenshots of some of the apps I've developed so far with AppyBuilder.


I am very pleased that AppyBuilder's CodeEditor is still available in Kodular.  Kodular says "If you are an advanced user, why not code in Java and create amazing Extensions for the Creator?"


2020年6月30日火曜日

日本語解析のためのCaboChaとKNP

 植物の特性に関するJSONファイルの生成では、(いつの間にか)日本語の係り受け解析が主となってしまいました。これまで、CaboChaを使ってきましたが、他にKNP [1] もあるというご教示(ここにあるコメント)をいただき、KNPも試用しました。

■ CaboChaとKNPの両方を使ってみる
 先の記事では、CaboChaによる係り受け解析結果が期待通りではなかった例を、9例示しました。今回は、この9例をKNPでもやってみました。確かに、KNPではいくつかの例で精度良く解析されることが分かりました。小生の理解では、KNPは、膨大な格フレーム辞書(すなわち、より踏み込んだ意味理解のための辞書)を自動構築して使っているようです。また、並列構造(例えば、"3月から4月に"では、"3月"と"4月"が並列)を明示する点も特徴と思われます。

 ただし、必ずしも全ての例文がKNPで改善されたわけではありません。依然として、日本語の解析は難しい面があることを感じます。具体的な実験結果を以下に示します。

(以下の図において、CaboChaの結果は作図アプリによる手動描画、KNPの結果はスクリーンショットの切り抜きです。)


■自分のアプリケーションで係り受け解析を利用するために
 これまでよりも、選択の幅が広がりました。しかし、解析精度だけで全てが決まるわけではありません。例えば、小生の場合、アプリケーションをJAVAで作成しています。したがって、JAVAにすんなり取り入れられるか否かも、重要なのです。当然、アプリケーション開発のフェーズが進めば、状況は色々変わりますが。

参考資料
[1] 黒橋・村脇研究室 日本語構文・格・照応解析システム KNP

2020年6月26日金曜日

日本語係り受け解析を有効活用するために(その2)

 前回の(その1)では、約3,000件の短い文について、係り受け解析とJSON自動生成を試みました。そのノウハウに基づき、今回は、やや長めの植物記述文について検討します。

■国内希少野生動植物種:ムニンノボタン
 国内の希少植物ムニンノボタンについてです。小笠原諸島父島にだけ生育する日本固有種で、平成16年国内希少野生動植物種に指定されています。その葉や花や果実の特徴を図1に示します。図中に示したWebサイトから引用させていただきました。


■ムニンノボタンの説明文
 参考資料[1][2][3]を基に、小生が作成した説明文を以下に示します。少し長いですが、その葉や花や果実の特徴を記したつもりです:

「ムニンノボタン:http://www.ogasawara-syokubutusi.com/koyuusyuZUKAN/koyusyuZUKAN/muninnobotan.htm:明瞭な3本の脈がある葉は両面にまばらな剛毛をつける。4枚又は5枚の花弁を持つ白い花が7月から8月頃に次々と咲く。小笠原が涼しくなる頃に直径1センチほどの丸い果実が実る。」

■係り受け解析(CaboChaによる)の結果
 上記の説明文を入力として、CaboChaによる係り受け解析を実行した結果が図2です。全体が木構造(tree)となり、最後に出現する述部「26 実る。」が根(root)となります。文の順序を反映して、述部「8 つける。」は「18 咲く。」に、そしてそれはさらに根に係ります。


■JSONテキスト生成の方法
 上記の解析結果を基に、図2のノードのうち、黄色く表示した「葉」「花」「果」について、それぞれ、タグtype, what, howをもつJSONテキストを生成します。その詳細手順は(例外的処理も必要ですが)省略しますが、基本的に表1のようにノード(文節)を連結し、タグの値として設定します。色分けは、図2に対応しています。なお、実際のJavaプログラムは、先祖(predecessor)、あるいは子孫(successor)を辿り集約する再帰的な構造になります。プログラミングの演習問題としてもよいかも知れません。


 例外はありますが、概ね、タグtypeには種類等が、whatには色や大きさや形状が、そしてhowには配置・接続状況や出現時期等が対応するはずです。

■JSONテキストの自動生成結果
 上記のようにして、JSONテキストを自動生成した結果が図3です。「葉」「花」「果」に関する3つのタグの値(連結したテキスト)は、いずれも妥当であることが確認できました。


■まとめ
 このような類いの記述からJSONテキストを自動生成することにより、原文のコンピュータ処理(種々の検索やグループ化等)がかなりしやすくなるはずです。その一例を以下に示します。参考資料[4](掲載植物約2,100種)から、ムニンノボタンを検索してみます。実際には、参考資料[4]にある一行記述約3,000件をJSON化したもの(現時点では未公開)を使います。以下のようなキーワード検索で一発でヒットしました!

●検索クエリ(葉の3本の脈と、白い花がポイント)
        jsonStream  //植物オブジェクトのストリーム
        .filter(p -> bQ(p,"leaf","3") && bQ(p,"leaf","脈")) 
        .filter(p -> bQ(p,"flower","白")) 
        .forEach(p -> pP(p));  //ヒットした植物の表示
[↑詳細については、過去記事をご参照ください。]

●検索結果(以下の1件のみヒット)
ムニンノボタン(双子葉木本)葉は長楕円形で3脈明瞭で、白い花が咲き、丸い蒴果がつく。


参考資料
[1] 新宿御苑 希少!ムニンノボタンの花
[2] 環境省 自然環境・生物多様性 ムニンノボタン
[3] 小笠原植物誌 ムニンノボタン
[4] 渡辺 坦:植物の名前を探しやすいデジタル植物写真集


2020年6月24日水曜日

日本語係り受け解析を有効活用するために(その1)

【要旨】これまでの日本語係り受け解析の利用において、人間には自然な文であっても、妥当な解析結果が得られない場合もありました。そのような典型例をここにまとめておき、今後の有効活用に資することとしたい。

■日本語係り受け解析器CaboCha
 ここで利用するのは、参考資料[7]に示したCaboChaです。以下の解析結果は、デフォルト設定のまま使った場合です。標準辞書以外の辞書を使うなど、環境設定を変えた場合は、異なる結果となる可能性があります。

■これまでの利用経緯
 植物の特性の一行記述(参考資料[6]に掲載されているもの)に対して、CaboChaを適用し、その係り受け解析結果に基づき、JSONテキストを生成してきました。参考資料[1]〜[5]をご覧下さい。その経験にもとづき、係り受け解析が期待通りに行かなかった例をまとめます。

■係り受け解析が期待通りの結果とならない場合の検討
 以下の、9例((A)〜(K))は、参考資料[6]を参考に設定したものですが、原文のとおりではなく、一部省略したり改変している場合があります。いずれも、人間が読む場合は自然であり、特に問題はないのですが、何らかの理由で期待通りの係り受け解析結果とならなかったケースです。

- 9個の例文 -
●複文に含まれる単文の区切りの認識に問題?
 例文(A) 茎は細く葉は披針形である。
 例文(B) 葉は細長い披針形で、装飾花のある白い花が咲く。
 例文(C) 葉は広楕円形で、5深裂した白い花が咲く。
●何らかの理由により、不自然な修飾となる問題
 例文(E) 葉は葉柄の長い卵形である。
 例文(F) 外皮が淡紅色の種が見える。
 例文(G) 葉は2回3出複葉で、茎先に大きい花が単生する。
 例文(H) 黄橙色で一重の花を数輪つける。
●文節を生成するための辞書に載っていない用語
 例文(J) 葉は卵円形で、小さい淡青紫色の花が咲く。
 例文(K) そう果を萼片が丸く包む。

■係り受け解析が期待通りの結果とならない場合の対応
 上記の9例の係り受け解析結果を以下に示します。そして、何が問題であるかを示し、それを回避するために変更した例文を示します。この9例は典型例と思われますが、まだ他に問題となる例文もかなり存在するかも知れません。











■まとめ
 上記で、なぜ期待どおりの解析結果が得られなかったのかは、もう少し調べられそうです。なぜなら、文節(上記図の黄色い丸い図形)がどんな品詞で構成されているかの情報も得られているからです。しかし、当面は本記事のレベルで留めておきます。本記事の内容について、何か間違いがあるかも知れません。ご指摘戴ければ幸いです。

参考資料
[1] 植物に関する自由記述のJSON化とJavaラムダ式とストリーム(B)
[2] 植物に関する自由記述のJSON化とJavaラムダ式とストリーム(A)
[3] 植物に関する自由記述からJSONを自動生成(その3)
[4] 植物に関する自由記述からJSONを自動生成(その2)
[5] 植物に関する自由記述からJSONを自動生成(その1)
[6] 渡辺 坦:植物の名前を探しやすいデジタル植物写真集
[7] CaboCha/南瓜: Yet Another Japanese Dependency Structure Analyzer

2020年6月21日日曜日

火星探査車のAIを強化するためのお手伝い

 NASAの火星探査車Curiosityは現在も活動中ですが、火星での行動を支援するためのAI(人工知能)を強化するお話です。以前の火星探査車は砂に埋もれて動けなくなったことが報じられました。その後は脱出できたようですが。そこで、搭載するAIを一層強化することが進められています。

 AIには、学習データが不可欠です。地球上での似た画像はもちろん学習している筈ですが、実際に火星に行ってみると色々な違いがあるようです。すなわち、実際に火星で撮影した画像をたくさん学習(この辺は砂丘なのか、堅い土なのか、大きな岩なのかな等々)する必要があります。そのためには、人が画像をみて、領域毎に(砂か土か岩石かなどを示す)ラベルを付ける必要があります。しかし、学習すべき画像の数は膨大であるため、そのようなラベル付けをしてくれる人を求めています。以下のサイトにその説明があります。

AI4Mars

 ユーザ登録すれば、誰でもすぐにこの作業(ボランティア)に参加できます。さっそくやってみました。下図のような画像が次々と表示されます。いくらでも好きなだけ作業できます。画像をよく見て、以下の4つのラベルを付ける区域を多角形で示してあげればよいのです。「教師付き(ラベル付き)学習」に使われるのですね。

 ●Sand:砂地(車輪が埋まるかもしれない)
 ●Soil:車輪が埋まらないような堅い土
 ●Bedrock:タイルを敷き詰めたような比較的平坦な岩
 ●Bigrocks:高さ30cmを越えるような大きな岩(あまり多くないが)


 この画像について、私がラベル付けした結果が以下の図です。中央付近は砂地、その上下の領域は埋まらないような土、そして、左下隅は堅い平板な岩のように見えました。その結果を、ボタンを押してNASAヘ送信します。

(注)分かりやすさのため画像に文字を表示していますが、
実際には不要です。多角形を描く色で識別されます。


 ここで、ちょっと心配になる人がいるかも知れません。「私のラベル付けが間違っていて、その結果、探査車が砂にはまったり、大きな岩石に衝突してしまったら責任を問われるのでは?」と。それはないです。膨大な数のボランティアがやっている筈ですから、少しくらい誤りがあっても、雑音として扱われ、問題ないはずです。AIの学習では、むしろ、一定の雑音が含まれている方が、適用性が高くなる(柔軟性が高まる)傾向があるからです。

 この作業は、子供といっしょにやるのもいいと思います。AIとはどんな仕組みでやっているのかを知るきっかけになるでしょう。人間によるデータの準備の重要性も分かるはずです。

■ここで思い出したことが...
 以下は古い(3年前)の記事ですが、Google機械翻訳に対する人手による改善ボランティア活動です。今回の火星探査車向けAIの場合と似ていませんか。

■さらに進めることもできそう...
 この作業をやって行くうちに、もっと先をやりたくなるかも知れません。すなわち、ラベル付け作業で終わらず、このようなラベル付き画像を集めたら、自分でも独自にdeep learningできますね。それを基に、自分でおもちゃの火星探査車も動かせそうに思います。実際、こうして大勢のボランティアがラベル付けした画像は公開されるようです。すでに一部は使えるようになっているはずです。


2020年6月19日金曜日

植物に関する自由記述のJSON化とJavaラムダ式とストリーム(B)

前報(A)の続編です。

(2020-6-21, [検索例(その3)]を追加しました。)

■今回の進展
 約3,000行の自然言語による自由形式記述(参考文献[1]にある、植物の一行記述)から、その内容を反映するJSONテキストを自動生成しています。原文に対して係り受け解析を行い(CaboChaにより)、それに基づいてJSONを生成します。係り受け解析結果とJSON生成結果の妥当性検査と、それにもとづいた原文の一部変更という作業を続けてきましたが、このほど終了しました。
 まだまだの状態(JSON自動生成のバージョンはVersion 0.5)ですが、一通りできましたので、以下のとおり、再度いくつかの検索を行ってみました。

■自動生成JSONテキストに基づく植物の検索例
 最初の例は、「葉が"倒披針"を含み、花が"白"または"紫"を含む植物」です。検索する主要部は下図のように、Javaの1ステートメントですみます。図中で、jsonStream1は、自動生成したJSONファイルをストリーム化したものです。メソッドbQやpPは小生作成のものです。妥当な検索結果が得られているはずです。

 
 次の例は、「果実のタイプ(type)」を列挙するというものです。上記のその(1)では、.filterと.forEachを使いましたが、ここでは、.mapと.collectを使っている点が違います。概ね妥当(係り受け解析結果の解釈に一部少しの不具合がありますが)な結果のようです。すなわち、このデジタル植物写真集に現れる果実のタイプを概ね列挙しているはずです。


 最後の例は、植物の区分(カテゴリ)毎に"葉"の特徴の記述を集約したものです。多少、処理は複雑にはなりますが、JavaのStreamを処理する強力なgroupingByメソッドのおかげで、見通しのよいコードが書けます。



■今後は...
 以上のとおり、植物の葉、花、果実に関するいろいろな検索が少し楽にできるようになったと思います。一方、現状では「穂」や「樹皮」や「茎や根」に関しては、まだJSON生成の対象としていません。今後検討したいと思います。

参考資料
[1] 渡辺 坦:植物の名前を探しやすいデジタル植物写真集
http://plantidentifier.ec-net.jp

2020年6月14日日曜日

植物に関する自由記述のJSON化とJavaラムダ式とストリーム(A)

本記事は、(その3)の続編ですが、少しタイトルを変更しました。

■今回の問題設定
 参考資料[1]には、植物を見つけるための1行記述が2,965行(ただしこのうち849行は別名)掲載されています。すなわち、実質約2,100種の植物が掲載されています。そのうちの2例を図1に示します。ここで、例えば、「葉に"楕円"を含み、花に"白"を含む植物」と、そうではなく「果に"楕円"を含み、花に"白"を含む植物」を見つけたいとします。


 単にキーワードとして"楕円"や"白"を含む行を探索するのでは、明らかに妥当な結果が得られません。そのため、自由記述文に形態素解析と係り受け解析を施し、それを基に適切にJSONテキストを生成し、それを使って探索すべきということになりました。

■係り受け解析とそれに基づくJSON化は容易か?
 上記のようにして、係り受け解析結果をJSON化することは、実際に行ってみるとそう簡単ではありませんでした。それは、係り受け解析結果が、原文の意味とは異なるケースが少なからずあるからです。その多くの場合、原文に句読点を補う(1文に含まれる複数の単文の区切りを明確にする)こと等で解決しますが、時にはどうしても原文を変更せざるを得ませんでした。その作業は、1行づつ人手で確認しながら進める必要がありました。約3,000行ありますので、1日100行づつ根気強く、確認変更作業を進めています。約1ヶ月かかりますが、まもなく完了します!

 自由に書かれた文の自然言語解析には色々な困難があります。係り受け解析も、簡単なルールだけでは処理仕切れず、機械学習を行っているはずです。人工知能を搭載して、華々しく街へ繰り出した自動運転車もすでに死亡事故を何件か起こしています。学習データの周到な準備は必然ですし、人手による評価修正のフィードバックが必要な状況は続くでしょう。今回のように、3,000件くらいやってみてようやく、自然言語処理の本質が少し見えた来たような気がします。

■Javaで自然言語解析する良さがここに現れた
 このように、まだ試行途中なのですが、これまでの作業結果をもとに、上記で設定した問題をやってみました。すなわち、以下の探索を可能にするJavaプログラムを作成しました。
 (1)葉に"楕円"を含み、花に"白"を含む植物
 (2)果に"楕円"を含み、花に"白"を含む植物


 詳しいことは略しますが、図2において、jsonStreamは、生成したJSONテキストをストリーム(stream)化したものです。このストリームの中味は、JSONオブジェクトです。そうなると、ラムダ式を使ったfilterや終端処理としてのforEachの出番です!Javaを使った自然言語処理の良さがここにも現れた気がします。

■生成したJSONテキストの概要
 未完成ですが、図3のようなJSONテキストが、係り受け解析結果から自動生成されましたので、ご参考までにその一部をご紹介します。(このJSONテキストは、整形すると全体で約55,000行になります。小生の研究用に生成したものですので、当面、公開はしません。)


参考資料
[1] 渡辺 坦:植物の名前を探しやすいデジタル植物写真集
http://plantidentifier.ec-net.jp

2020年6月3日水曜日

近づく夏 - ガクアジサイとバッタの子供

 6月に入り、夏がやってきました。散歩で出会ったガクアジサイとバッタの子供の写真を掲載します。

咲き始めのガクアジサイ(厚木市郊外)

どこか幼い子供のバッタ2種(真夏にはこの3倍位の大きさに)