I think we look at it from different sides. Mine is "how good will this be in independently running code" (where 80% correctness is minimally needed), yours seems to be more "how well does this represent our knowledge" (from different angles).
you could make this point about tokens also ("take any bunch of characters that happens often enough, and call it a token").
My reason was more that such an approach doesn't work well with (unrestricted natural language) text. E.g. side_effects => physical_damage: What side effects? (Why plural?) Not all cause physical damage. And not all side effects that cause physical damage cause the same damage. The differences are described elsewhere in the text, but not consistent enough to extend the token with that information, so just associating literal excerpts from a text will practically guarantee underspecification (except for practically unambiguous term). The effectiveness will be language dependent, of course.
Comments
True.
I think we look at it from different sides. Mine is "how good will this be in independently running code" (where 80% correctness is minimally needed), yours seems to be more "how well does this represent our knowledge" (from different angles).
My reason was more that such an approach doesn't work well with (unrestricted natural language) text. E.g. side_effects => physical_damage: What side effects? (Why plural?) Not all cause physical damage. And not all side effects that cause physical damage cause the same damage. The differences are described elsewhere in the text, but not consistent enough to extend the token with that information, so just associating literal excerpts from a text will practically guarantee underspecification (except for practically unambiguous term). The effectiveness will be language dependent, of course.
Anyway...