w3c / jlreq-d

Requirements for Japanese Digital Text Layout
17 stars 3 forks source link

Warichu and string searching operations #45

Open xfq opened 9 months ago

xfq commented 9 months ago

When doing string searching operations, should Warichu be skipped or not? For example, when searching for "福沢諭吉の" in the text below, should it match?

img2_4_2

kidayasuo commented 9 months ago

Good question. Ideally, yes.

It might not be critical however. Usually warichu is attached to a concept and most commonly searches are done against such concepts. I can think of cases that breaks this and I am not sure how such cases are important. For example warichu can be inserted in the middle of a compound noun that as a whole might be important search object. I will ask other folks.

This reminds me other similar cases. Insertion of footnote marks, insertion of inline graphics, etc. How are they treated do you know?

KobayashiToshi commented 9 months ago

一つの判断基準として,“読者がそれに興味や関心を持つかどうか”ということがある.上記の"福沢諭吉"の割注内のテキストを検索しようとは,一般には思わない.そして,割注の使用法として,人や事項の簡単な解説,紹介という使用例が多いので,一般には除外できるが,それが一般化できるかどうかはケースによるでしょう. もっとも,“読者がそれに興味や関心を持つかどうか”という判断は,簡単ではない.これは索引項目の選択の問題でもある.このことをもっとも知っているのは,その原稿の執筆者(著者)であるが,一般に著者は,索引項目の選択はやりたがらない傾向にある,という問題もある.

kidayasuo commented 9 months ago

@KobayashiToshi 敏先生、問題は割注内のテキストではなくて、割注を跨いだ文字列を一体として検索できるべきか? ということです。

つまり上の例のように「諭吉」と「の」が割注で分断されている場合もちゃんと「福沢諭吉の」を探したときに見つかるべきかということ。答えはもちろん Yes だと思います。文としては続いているので。

ただ、どのくらい重要かと問われたときにどのくらいかな?と。普通割注は一つのコンセプトに付きますし、それが通常の検索ターゲットなので、ものすごく重要というわけではないかもしれません。ただ、例えば「福沢(割注)諭吉」を「福沢諭吉」で探す、「福沢諭吉(割注)の妻が」を「福沢諭吉の妻」で探すといったケースはその通常のケースに当てはまりません。どうでしょうね。

また、似たようなケース、例えばフットノートマーク(†‡)などが含まれる場合や、インライングラフィクが含まれるようなケースではどうなっているんでしょうね?

KobayashiToshi commented 9 months ago

注番号は一般に文末に付くケースが多いが,語句の注もあり,語句の直後に付くケースもある.で,  語句a“注番号又はその他の異物”語句bの続き… と考えた場合,語句aは,一般にそれだけで完結しており,それに続く語句bは,それも完結しており,別々に検索できれば,一般にはいい.ですから,重要度は高くない,と思う.

しかし,検索では,語句を組合せた検索,つまり“福沢諭吉の妻”という検索をしたいとケースはある.“本文注1)の行間”とあった場合,“本文の行間”で検索したいでしょう.具体例は忘れたが,検索を絞りたいために,語句を組合せた検索したいケースはそれなりにあるが,できないので,1つの単語で検索し,すごく数が多くなって,というケースは,何回か経験している.

もう一つのケースですが,これは漢文などにあるケースで,文字1字だけが問題となり,それに注が付くケースがある.複数の字で構成される人名の1字だけについて,この字は,誤記や異体字かもしれないという注記がつくケースです.この場合は,まとまった人名で検索したい.

ただ,最近では近接した距離の長さを指定し,組合せた語句の検索できる方法もある(日本語でこれができるかは,未確認)ので,この方法で“福沢諭吉の妻”は,間に割注があっても検索できる可能性はある.

そして,異物には,注番号,インライングラフィク以外に,約物(例:“編集”の意義,特に書名などで括弧で括った例がある)や,ダーシなどもある.これらは一般に検索では無視されるケースが多い.

KobayashiToshi commented 9 months ago

この問題は,割注よりは,以下のような例の方が多いのではないかな.(図書館で探してきました,たった1冊でこれだけありました.多少は改変してあるが.)  東海道線鈴川駅(現・富士市)の地すべり  経済団体連合会(経団連)会長の土光敏夫  これは,経済団体連合会会長と経団連会長と2つほしい  国鉄(国有鉄道)の民営化  国鉄(国有鉄道)民営化  東京証券取引所(東証)に上場  東京証券取引所(東証)上場  運輸省(いまの国土交通省)の政務次官(いまの副大臣) 運輸省(いまの国土交通省)政務次官(いまの副大臣)  平和維持活動(PKO)に出動  ワールドカップ(W杯)の開催  ワールドカップ(W杯)開催  これもワールドカップ開催とW杯開催と2つあってもよい

himorin commented 9 months ago

また、似たようなケース、例えばフットノートマーク(†‡)などが含まれる場合や、インライングラフィクが含まれるようなケースではどうなっているんでしょうね?

あんまりウェブ上で注記号を入れているのは見ない気はしますが、<sup>を使って上付きで入れてる場合は、その中身も平たくしてin page searchに掛かる実装になっていると思います。どちらかというと<span title="">とかのhoverの事例の方が多い??けれどスマホ全盛になって今はどうなってるか不明、、。

kidayasuo commented 9 months ago

この問題は,割注よりは,以下のような例の方が多いのではないかな.(図書館で探してきました,たった1冊でこれだけありました.多少は改変してあるが.)

確かに。これは英語でも同じ問題があって、マッチしませんね、さすがに。

とすると、割中で分割された言葉は括弧で注釈の入る場合と同様で、語に分解して行う賢い検索では探せるけれど、そうでない場合は探せなくてOKですかね。

KobayashiToshi commented 9 months ago

とすると、割中で分割された言葉は括弧で注釈の入る場合と同様で、語に分解して行う賢い検索では探せるけれど、そうでない場合は探せなくてOKですかね。

OKというか,現状ではやむをえないのではないかな.語に分解して行う賢い検索で探す方法で解決するしかないのではないかな.

参考までに,文字に注記号が付く漢文の例を示しておきます.こんな感じです.単語の字間に注記号が入る.  黄帝の聴きて……  *黄は他本では皇……  骨敖(こつごう)を伐たんと欲す  *諸本では骨は胥と……  枝経肯綮(しけいこうけい)  *枝は諸本では技とあるが……  

もっとも,漢文では,字間に注記号を入れるのではなく,行間に注記号を入れる.そういう点では,行間に注記号を入れる,あるいは,行間注にして,検索したい文字列の間には異物を入れないという方法は,それなりのメリットがあるのかもしれない.

kidayasuo commented 9 months ago

So, @xfq san, the conclusion is that

For the main text flow, the search algorithm should operate as though warichu (inline annotations) are not present in the text. This means it will ignore warichu when scanning the main body of text. Similar to warichu, there are cases where annotations (like text within parentheses), footnote marks, or other objects are inserted within the text flow. These should be treated the same way as warichu by the search algorithm, essentially disregarding these elements during a standard search.

The search should be capable of processing the content inside these annotations, in addition to its ability to bypass them in the main text flow.

xfq commented 9 months ago

Thanks a lot! Filed https://github.com/w3c/string-search/issues/22 to document this.

Personally, i think it would be better to have some text about this in jlreq-d too.

kidayasuo commented 9 months ago

Personally, i think it would be better to have some text about this in jlreq-d too

I agree.

Currently we do not have a method to label issues for inclusion in a document such as jlreq-d. Does clreq have an established method for tracking them?

r12a commented 9 months ago

I was surprised at this conclusion. Personally, i would have thought it useful to search on the annotations, given that they may include useful words when explaining things that they annotate. I see searching as different from text-to-speech (where there is certainly a need to be more aware of the structure of the text).

Wrt ruby, the annotation and the base are most likely to be in different scripts, and so it seems to me that unless there is a plan to intelligently parse the content and search for a term in both scripts, that it would be useful to allow search on the ruby text in case the user typed their query in, say, hiragana, rather than kanji.

kidayasuo commented 9 months ago

@r12a I updated the conclusion text as it was not clear enough.

The original question from @xfq was if search against the main text flow should work as if warichu does not exist. The answer is yes, and the same goes to the similar cases such as inserted parenthesised text, footnote marks and inline graphics. The content of these annotation should be searchable also.

r12a commented 9 months ago

Is it currently possible to specify that a search looks only at the body text? Or is that looking to the future?

himorin commented 9 months ago

Is it currently possible to specify that a search looks only at the body text? Or is that looking to the future?

There were some discussion on this point during recent jlreq calls, but we could not find any suitable markup nor standard way for Warichu (or even for marks to indicate annotation anchors?). Even for ruby, which has elements to specify its semantics, there are some copy&paste issues exist in some rendering engines, but any browser engines might not be possible to tell about these kinds of annotations like Warichu AS annotations if we don't have any way to tell... (e.g. CSS property to mark parts as not for FindAsYouType or copy&paste)

xfq commented 9 months ago

This was also discussed (in https://www.w3.org/2023/11/17-clreq-minutes.html#t03 and some offline discussions) by the clreq group, and people think while it is sometimes useful to include the annotation, it should be skipped by default, and ideally the behaviour should be configurable.

Is it currently possible to specify that a search looks only at the body text? Or is that looking to the future?

This is about the future. Also, this is about the expected behaviour, without describing particular technological solutions (like markup or CSS property).