転成名詞などの例からもわかるように三属性の境界は時として曖昧であり、ひとつの語が複数の属性をかけ持ちするケースは十分考えられます。
例えば「戦死」のように用言全般のよろづロ万に属すると考えられている語句がありますが、一方で「-死」という接尾語を含む言葉なので第三のよろづハ万への帰属も兼ねています。
これは接辞の「し」が氏・誌・史・市・師・紙のように選択候補が多岐にわたるためこの例のサ変動詞などのように用言としてのよろづが検出される場合にはその特徴を活かしてよろづロ万を持たせることにより、他のよろづの、接尾語をもつ変換候補選択が煩雑になる場合と差別化できて便利だからです。
元々このような措置に至ったのは特にこれといった考えがあったわけではなく、気軽な気持ちで「大は小を兼ねる」の言葉通りとりあえず両方に変換候補を載せてしまえばいいんじゃないか…との判断によるものでした。
とはいったもののあれこれ思考実験を巡らせているうちに、この「属性かけ持ち」のインターフェイスとしての挙動は結構奥が深いのだということが推量できるとの認識に至りました。
ユーザーは変換候補の中から納得のいく候補が上位に無いと、変換キーが4つもあるせいか別の変換キーで選択したら期待する変換候補がすぐ見つかるのではないかと試行錯誤し、渡り鳥みたいになってしまう行動様式をもつに至るのではないかとの洞察が頭をよぎってきたのです。
これは意図する属性の変換候補リストの中に元々入っていなければお手上げなので無論セイフティー的に手広く帰属属性を兼任させればよいのですがこれだけではせっかちなユーザーから満足の得られるインターフェイスとしては手ぬるいものになってしまうだろうと言わざるを得ません。
三属性変換の候補リストの提示に、それまで試行錯誤した文脈が反映されていなければただその都度その都度刹那的に属性のリスト照会をしているだけで、ユーザーの意図をくみ取ろうという視点が全く欠けているのです。
ペンタクラスタキーボードの強く意識する、システムとしての「人間-機械系」というものをより高いレベルで体現するためにも想定されるユーザーのオペレーションミスからしっかり観察しそれを有効に生かしていかなければなりません。
まずは実例から入ってどのような改善策があるのか解説していきたいと思います。
「見得を切る」で使われる「見得」について順を追って考察していきたいと思います。この語は名詞としてピックアップしましたが「見得を切る」というイディオムで使われているというのもあって叙述用言の発端としてみる＝叙述構造句として不可分…だとみなし用言属性のよろづロ万を兼任しています。(厳密には名詞なのですがよろづの用として様態叙述イメージに併呑されます）
例えば「出ました…この見得！」みたいに突発的に名詞使いされることもなくはないので名詞属性を持たせるということに特に問題はないと思われます。
ただ順当に考えれば名詞でみえといえばまず「三重」が挙がるので「見得」がトップに来るということはまずありません。そこでユーザーは「三重だと名詞名詞しすぎているから叙述要素のニュアンスで…」ということでロ万の変換キーを押して軌道修正しようと試みます。
このとき一度名詞のイ万を経由していることを鑑みて、二番手でよろづロ万に遷移したときのトップ候補が両方のニュアンスを満たす「見得」になるようにする工夫です。
普通なら単発的に見ると「みえ」のロ万での候補順位は「見え」「観え」「見栄」などが上位に来るはずなのですがこのようなときには普段あまり使われない「見得」がピンポイントでトップに来るという算段です。
さらにこの考えを進めていくと特に接頭辞・接尾辞を含んだ言葉＝ハ万に対して興味深い強みを発揮するパターンがよくみられるので留意しておきたいところです。
例えば極端な話、ぷりしら嬢の・ぷりしら場の・ぷりしら城の・ぷりしら錠の・ぷりしら状の・ぷりしら上の・ぷりしら乗の・ぷりしら条のなどのような接尾語「じょう」のつく言葉を属性遷移のニュアンスづけを利用して効果的に変換候補を選択できるようにすることも理論上可能です。
経由する属性は、「嬢・場・城・錠」は名詞属性のイ万、「状・上」は叙述成分のロ万、「上・乗・条」は抽象概念的なハ万での変換に反映させれば適当かと思います。
ここで一部「上」がロ万とハ万で重複していましたが、ここが属性兼任のクセのあるところでかならずしも排他的に浮かび上がってくるだけとは限らないという事も考慮に入れなければなりません。
なにかよいデータ定義様式を検討しないと変換手続きが意図するふるまい通りに機能してくれないことが見込まれるのでいずれ対策が必要になってくるでしょう。
さらにはハ万の同属性遷移＝かさね踏み(？)のときには本来のハ万で列挙したオーダーが切り替わってしまっては意味がないのではないかという疑問も湧いてきます。
あと細かい話ですが通常変換×３ののちハ万へ遷移した場合などは通常変換で通過した変換候補はハ万のテーブルでは省いて再オーダーされるなどといったようなチューニングも求められるかもしれません。
さらにさらにイ万→ハ万の遷移のときとハ万→イ万の遷移のときで差が出てきたりはするのか、またそういった定義はあるのか、検証事項は尽きることはありません。
ただあまりにも属性遷移反映が行き過ぎると求める変換候補を見失ったとき収拾がつかなくなってしまいますのでわかりやすさのために通常変換に再び戻したときには候補順位テーブルをリセットさせることが大前提になってくるかと思います。
いずれにしろこれから煮詰めなければならない話ですがひとつ重要なポイントとして、上記のようなぷりしらという言葉が事前にどんな素性・フレームをもつのかがわからないときでも造語・複合語の類いが手軽に表記できるという利点があるということに触れておきたいと思います。
もちろんぷりしらというワードが人名の属性であることがわかっていて適切にぷりしら嬢へと変換されるという流れであれば解析プロセスに任せる方が良いかもしれませんが遷移を利用してより重層的な、奥行きのある構えがとれるならそれに越したことはない…ということはハッキリ言えます。
例えば「戦死」のように用言全般のよろづロ万に属すると考えられている語句がありますが、一方で「-死」という接尾語を含む言葉なので第三のよろづハ万への帰属も兼ねています。
これは接辞の「し」が氏・誌・史・市・師・紙のように選択候補が多岐にわたるためこの例のサ変動詞などのように用言としてのよろづが検出される場合にはその特徴を活かしてよろづロ万を持たせることにより、他のよろづの、接尾語をもつ変換候補選択が煩雑になる場合と差別化できて便利だからです。
元々このような措置に至ったのは特にこれといった考えがあったわけではなく、気軽な気持ちで「大は小を兼ねる」の言葉通りとりあえず両方に変換候補を載せてしまえばいいんじゃないか…との判断によるものでした。
とはいったもののあれこれ思考実験を巡らせているうちに、この「属性かけ持ち」のインターフェイスとしての挙動は結構奥が深いのだということが推量できるとの認識に至りました。
ユーザーは変換候補の中から納得のいく候補が上位に無いと、変換キーが4つもあるせいか別の変換キーで選択したら期待する変換候補がすぐ見つかるのではないかと試行錯誤し、渡り鳥みたいになってしまう行動様式をもつに至るのではないかとの洞察が頭をよぎってきたのです。
これは意図する属性の変換候補リストの中に元々入っていなければお手上げなので無論セイフティー的に手広く帰属属性を兼任させればよいのですがこれだけではせっかちなユーザーから満足の得られるインターフェイスとしては手ぬるいものになってしまうだろうと言わざるを得ません。
三属性変換の候補リストの提示に、それまで試行錯誤した文脈が反映されていなければただその都度その都度刹那的に属性のリスト照会をしているだけで、ユーザーの意図をくみ取ろうという視点が全く欠けているのです。
ペンタクラスタキーボードの強く意識する、システムとしての「人間-機械系」というものをより高いレベルで体現するためにも想定されるユーザーのオペレーションミスからしっかり観察しそれを有効に生かしていかなければなりません。
まずは実例から入ってどのような改善策があるのか解説していきたいと思います。
「見得を切る」で使われる「見得」について順を追って考察していきたいと思います。この語は名詞としてピックアップしましたが「見得を切る」というイディオムで使われているというのもあって叙述用言の発端としてみる＝叙述構造句として不可分…だとみなし用言属性のよろづロ万を兼任しています。(厳密には名詞なのですがよろづの用として様態叙述イメージに併呑されます）
例えば「出ました…この見得！」みたいに突発的に名詞使いされることもなくはないので名詞属性を持たせるということに特に問題はないと思われます。
ただ順当に考えれば名詞でみえといえばまず「三重」が挙がるので「見得」がトップに来るということはまずありません。そこでユーザーは「三重だと名詞名詞しすぎているから叙述要素のニュアンスで…」ということでロ万の変換キーを押して軌道修正しようと試みます。
このとき一度名詞のイ万を経由していることを鑑みて、二番手でよろづロ万に遷移したときのトップ候補が両方のニュアンスを満たす「見得」になるようにする工夫です。
普通なら単発的に見ると「みえ」のロ万での候補順位は「見え」「観え」「見栄」などが上位に来るはずなのですがこのようなときには普段あまり使われない「見得」がピンポイントでトップに来るという算段です。
さらにこの考えを進めていくと特に接頭辞・接尾辞を含んだ言葉＝ハ万に対して興味深い強みを発揮するパターンがよくみられるので留意しておきたいところです。
例えば極端な話、ぷりしら嬢の・ぷりしら場の・ぷりしら城の・ぷりしら錠の・ぷりしら状の・ぷりしら上の・ぷりしら乗の・ぷりしら条のなどのような接尾語「じょう」のつく言葉を属性遷移のニュアンスづけを利用して効果的に変換候補を選択できるようにすることも理論上可能です。
経由する属性は、「嬢・場・城・錠」は名詞属性のイ万、「状・上」は叙述成分のロ万、「上・乗・条」は抽象概念的なハ万での変換に反映させれば適当かと思います。
ここで一部「上」がロ万とハ万で重複していましたが、ここが属性兼任のクセのあるところでかならずしも排他的に浮かび上がってくるだけとは限らないという事も考慮に入れなければなりません。
なにかよいデータ定義様式を検討しないと変換手続きが意図するふるまい通りに機能してくれないことが見込まれるのでいずれ対策が必要になってくるでしょう。
さらにはハ万の同属性遷移＝かさね踏み(？)のときには本来のハ万で列挙したオーダーが切り替わってしまっては意味がないのではないかという疑問も湧いてきます。
あと細かい話ですが通常変換×３ののちハ万へ遷移した場合などは通常変換で通過した変換候補はハ万のテーブルでは省いて再オーダーされるなどといったようなチューニングも求められるかもしれません。
さらにさらにイ万→ハ万の遷移のときとハ万→イ万の遷移のときで差が出てきたりはするのか、またそういった定義はあるのか、検証事項は尽きることはありません。
ただあまりにも属性遷移反映が行き過ぎると求める変換候補を見失ったとき収拾がつかなくなってしまいますのでわかりやすさのために通常変換に再び戻したときには候補順位テーブルをリセットさせることが大前提になってくるかと思います。
いずれにしろこれから煮詰めなければならない話ですがひとつ重要なポイントとして、上記のようなぷりしらという言葉が事前にどんな素性・フレームをもつのかがわからないときでも造語・複合語の類いが手軽に表記できるという利点があるということに触れておきたいと思います。
もちろんぷりしらというワードが人名の属性であることがわかっていて適切にぷりしら嬢へと変換されるという流れであれば解析プロセスに任せる方が良いかもしれませんが遷移を利用してより重層的な、奥行きのある構えがとれるならそれに越したことはない…ということはハッキリ言えます。
