KW requirement from user perspective

[karen <karen@3721.com>]

Dear Klensin,

It was great meeting and discussing  with you in Salt Lake city.  Thanks to your IRNSS initiative, there is now increasing discussions on keyword related issues in the frame work of your proposed IRNSS framework.  I just want to share with you and the IRNSS discussion group a very brief, one-page draft we shared with the MINC keyword discussion group,  it highlights our understanding of the Keyword requirement from the user perspective.  

Best regards,

---Karen Liu
Inter China Network Software  (3721.com)

As for the requirement for Keyword System, following represent the opinion
of Inter China Network Software Co. Ltd(3721.com).

------------------------------------------------------------------------


                                                          Steven Shi
                                                           Karen Liu
                                Inter China Network Software Co. Ltd
                                                   December 21, 2001


             Some Basic Requirements for Keyword Systems


From the user perspective, we believe the following would be the
basic requirements for keyword systems.

1. Keyword or name-string format
(i) Keyword or name-string should be syntax-free as much as possible,
ie. users should be able to input any form of free-text query (word,
phrase or sentence);
(ii) Certain characters should be excluded from keyword composition
(eg. the dot "." and slash "/"), otherwise this will add complication
to applications for identifying whether the user input is a keyword
or a url.

2. Keyword Facets
In addition to the name-string, a keyword record should include these
following basic facets:
(i) name-string
(ii) location (the location facet would have to be granular enough)
(iii) language
(iv) uri associated with the resource
(v) service provider

3. Facets Designation
Users should not be required to explicitly designate the above facets
when doing a keyword query, ie. they just type in the name-string, and
other facets could be left to the configuration of the applications.

4. Keyword Uniqueness
(i) For any given service provider, a unique combination of facets
MUST result in a unique keyword record;
(ii) Keyword uniqueness may not be required across different service
providers;

5. Keyword Matching Method
(i) If a user's query string exactly matches the name-string of a
keyword, the server SHOULD return directly one response result
(the result format may differ depending on applications, eg. in
the case of  web browsing, the result could be just the uri linked
to the keyword).
(ii) If a user's query string does not exactly match the name string
of a keyword, the server SHOULD return 0 result or a list of multiple
approximate results (this requirement is necessary because in many
cases people can not remember the exact name-string of the keyword).
But it should be up to the service provider to decide what degree of
fuzzy matching (sub-string matching or something else) it considers
appropriate to support for their users.

6. Service Discovery Mechanism and User Choice
There should be at least a simple discovery mechanism which is outside
of the keyword system itself. This mechanism could describe a keyword
service in a unified form (as Paul Hoffman suggested), thus applications
could apply this mechanism to provide users with options to select a
preferred service provider. 

Optional consideration, not basic requirement
(i) TC/SC conversion and other name-prep
A basic assumption here is that, except for the ASCII chars, users barely
combine characters from different character sets (eg. Chinese, Japanese,
Korean and so on) into one input string.  So some validation algorithms
as well as other name-prep method could be applied to address the TC/SC
conversion issue.