[DICT] use case 6

[Jeff Alexander]

To understand the context of this email, please refer to the comments on #6 in the MM and YK columns of the spreadsheet [1].

Almost everyone agreed that searching a dictionary via text input represented a 'must enable' use case.  However, Murata-san objected, raising several valid concerns and suggesting we could be opening a can of worms. Kida-san replied in detail to these concerns, outlining what I think is a good approach to enabling this search while limiting its complexity.

  

I think that if we clarify and limit what is 'must enable' here, then we can keep the lid on the can of worms, so to speak. 

KIDA>The search by the headword string is the most basic and I believe a must have/enable.

Yes, I agree. I think headwords are the only type of dictionary data that it's a "must" to search by text input. 

Advanced interfaces often do let users search for other types of data. However, though it might be nice to enable a search of example sentences, for instance, it's not a must for this first version.

So though the use case states "the user searches for a term by entering text...", the must-enable aspect would be better described, "the user searches for a headword by entering text...".

KIDA>The search by Yomi / Pinyin should also be a must have as they are the primary way of searching entries for Japanese / Simplified Chinese dictionaries.

Good point. By calling this "must enable", we're clarifying that text-input headword search is supported in a broad range of Chinese and Japanese dictionaries.  Another way of stating this is that it would be supported for any alphabetic or syllabic (eg, kana) input method.

KIDA>The search by Radical-Stroke I believe is important but not a must.

I agree. I would really like to define a data representation for the radical/stroke count information in our first version. However, as I know it adds a level of complexity to our effort, I'm unsure it will be possible this time.

My proposal is to treat this as an important, "should enable" goal for the first version, but recognize that it is tricky and may not be possible. However, in the longer term, I would call this "must enable".

To the extent we do attempt to address it now, I think focusing solely on the data representation of radical/stroke information is very important (rather than on the complex search interfaces required for various languages, which are best addressed by reading systems anyway).

Thanks,

Jeff

[1] https://docs.google.com/spreadsheet/ccc?key=0AgaNbXmzpYW1dHdmRFZCelBWb3VWMVVzMDlpX1dLckE

[Yasuo Kida]

Agreed.

To the extent we do attempt to address it now, I think focusing solely on the data representation of radical/stroke information is very important (rather than on the complex search interfaces required for various languages, which are best addressed by reading systems anyway).

Is this something we can take advantage of the progress in the Index subgroup?

- kida