[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-irnss Home]
Subject: Re: "so-called" keyword and layer 3
On Wed, Dec 05, 2001 at 08:20:18PM +0800, James Seng/Personal wrote: > I believe there is also a korean user requirements document. Is it > possible to share that document with this group? It would certainly help > to give some insight to why this is so. Dear James Seng and other, I copied and pasted some portion of our user requirement document. We are using the term "name lookup service" to avoid unnecessary confusion with existing keyword services. * * * 3 List of Service Requirements 3.1 Return 0 or 1 result Since the name lookup service is based on the lookup repository that is defined in [1], the result to a successful lookup is a single group of information. 3.2 Input is a word or a phrase One of the main purposes of the name lookup services is to allow users to use more intuitive and familiar names. In this sense, the services should permit the use of phrases as well as the words. These names can be in all languages. Further discussion includes the maximum words in a phrase, the length of a phrase, whether permitting special characters (i.e., slash, comma, blank space, parenthesis, and so on) as part of the input. 3.3 No explicit attribute Users provide only the naming attribute of the object that they want to find. No other attributes of the object are required explicitly from users. Instead, the implicit use of attributes of the name is permitted for the sake of efficiency and flexibility. 3.4 User profile may be provided (optional) As mentioned in Section 3.2, some attributes are used to efficiently handle the name lookup services. For instance, the following attributes could be used in user's profile. * The language * The locality (or preference location) * The name lookup service provider In addition to the attributes listed above, the current location of mobile terminal might be an important attribute in mobile Internet environments. Consequently, the name lookup services can provide a context-sensitive service that can enhance user's convenience. Moreover the name lookup services can enlarge the limitation of the DNS naming space by using context- ensitive naming scheme. 3.5 Auto completion (optional) In order to reduce the query error by typing incorrect names, the service can complete the full names by matching them partially even before finishing typing while users type names. 3.6 Optional link to keyword search The keyword search [3] , CNRP[5] and Directory systems [6] are different from the name lookup service in that the former three schemes return 0 or more results while the last one returns 0 or 1 result. The keyword search can be effectively used with the name lookup in cases that the name lookup fails to find the name or user wants to see different results. 3.7 List of applications Service should be designed independent of any applications so that any application can use this name lookup service if it wants to do. 3.8 Input The name lookup service allows such inputs as business names, brand names, personal names, telephone numbers, or even barcodes. It should include as many forms as possible for the input. * * * Regards -- /*------------------------------------------------ YangWoo Ko : newcat@spsoft.co.kr ------------------------------------------------*/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-irnss Home]
Powered by eList eXpress LLC