Subject: CNRP Usage Scenrios

From: Ben Schepens <[email-masked]>
Date: Wed, 1 Dec 1999 12:22:03 -0500

Below are potential usage scenarios drawn from 
the Goals and Requirements document.  The purpose
is to test the protocol document for completeness
and accuracy.
 
Some examples below, may also be determine, to 
be specifically not handled by the protocol.  
Others may me refined to more accurately reflect 
the real intended use.
 
Please review and comment.
 
================================================
Set A
================================================
 
================================================
Common Name Resolution Protocal Usage Scenarios:
================================================
 
----------------------------------------------------------
Registering a new CNRP server with a client
----------------------------------------------------------
 
  The client would specify the specific URL for the CNRP
  server.  At this time, the client would request from the
  server the query and answer schemas that the server supports.
  These schemas could be 'well known' schemas that have
  been registered with IANA or Custom schemas unique
  to that server.
 
  All schema types would support some basic registered sets
  of properties like location, language, and business type.
 
  The client could also query the server  for the data 
  type specifications for each property type supported by its
  schema if the client has not encountered this schema type before.
  This would include the valid values that each type may use.
 
  For example, a well known 'Medical' schema type might also support
  a property for 'FieldOfStudy' with defined values of 
  'Internal Medicine', 'Surgery', 'Epidemeology', etc.
 
  A well known 'Astronomy' schema type might also support a
  property for 'MassOfCelestialBody' that allows integers between
  1 and 10000 Earth Masses.
 
  Property names could be registered with IANA so that if a client
  saw that two different server schemas included the 
  'IndustryAssociation' (i.e. IEEE, IETF, AMA) the client would 
  know that both schemes are refering to the same data type.

----------------------------------------------------------
Client Common Name Queries
----------------------------------------------------------
 
General query notes:
  NOTE (1):  Any client querying multiple servers with differing
supported
  schemas could only specify properties that all servers' schemas
  have in common.  
 
  NOTE (2): For Common Name matches, individual servers determine if the
  string match is an exact match OR a substring match.
 
  NOTE (3): Each of the scenarios below is shown as a separate search
type
  for clarity; However, a given query could combine more than one of 
  the property types described below.
 
1) Simple Common Name lookup
 
User specifies:  
    Common Name, Server(s) to query
 
Servers return:
   All records that have a match (see NOTE 2 above) for that 
   common name

2) Common Name lookup with preferred language(s) specified
 
User specifies
   Common Name, Server(s) to query, preferred language 
   of client
 
Servers return:
   All records that have a match (see NOTE 2 above) for that
   common name and that the server deems
   is compliant with any of the preferred language(s) 
   specified.  The server may be very strict and 
   match the preferred language exactly, or may 
   match on languages it deems similar to the 
   preferred language (e.g.  English  could match 
   UK English and US English)

3) Common Name Lookup with business type specified 
    (e.g. NAICS code) 
 
User specifies
   Common Name, Server(s) to query, particular business 
   type(s) to match
 
Servers return:
   All records that have a match (see NOTE 2 above) for that
   common name and exact match of any of the 
   specified business types

4) Common Name Lookup with geographical location property specified
 
User specifies
   Common Name, Server(s) to query, particular geographical 
   location(s) to match
 
Servers return:
   All records that have a match (see NOTE 2 above) for that
   common name and within any of the geographical 
   location specified.
 
   The geographical location specification would be valid common
   geographical subdivisions for the countries to which they belong.
   For instance, for the USA, location codes would be Country (USA), 
   State, County, City OR Zip Code.   

5) Common Name Lookup with custom property types
 
User specifies
   Common Name, Server(s) to query, particular property to
   match.   The property could be any property defined in the 
   schema that the server(s) support. The server being queried 
   would be responsible for determining which results qualified
   as a match for custom properties.
 
Servers return:
   All records that have a match (see NOTE 2 above) for that
   common name and that the server(s) deemed matched custom
   properties.

 

================================================
Set A
================================================
 
Scenario 1)
A CNRP server provides clients with gaming servers information.  
Specifically, a client uses the common name "Unreal" and specifies 
a TEAM property of the search.  The client uses this to find Unreal 
servers associated with that TEAM for joining online games.

Scenario 2)
A university sets up a server to allow clients to locate classes given 
the class name.  An additional TERM property may be specified to 
ensure that appropriated details for that class (professor, syllabus, 
time, etc.) will be located.
 
Similarly, the same server could provide resolution of names of 
published research papers when the client enters the beginning of 
the paper name.  An additional property of AUTHOR could be 
specified to help more quickly specify the particular paper being
sought.  
 
Scenario 3) 
A server provides resolution of unique tradenames or trademarks.  
For instance, the client specifies a common name of 'Zippy Cola' 
to locate information about Zippy Cola, Inc.  Alternately, the 
client enters one of the well known registered trademarks of Zippy 
Cola, Inc., 'Drink Zippy Cola'.   It is possible that Zippy Cola 
has the only valid registration for its common name and trademark; 
however, it may have multiple references with local information based 
on geographical location.  Therefore, a client might also specify a 
GEOGRAPHICAL LOCATION property to get localized data for Zippy 
Cola, Inc.
 
Scenario 4)
A server might provide clients with the ability to locate audio files 
(MP3, wav, au, etc.) given the specific name of a song.  Additionally, 
an ARTIST, DATE RECORDED, FORMAT properties may be specified to locate 
a particular recording of a song.
 
Similarly, a server might provide that ablility for a client to locate 
online streaming services given the name of the services.  An additional

property of the search might be the FORMAT of the streaming source.
 
Scenario 5)
A server might provide doctors with the ability to locate medical sites 
given the specific name of an illness, medicine, research study, etc.  
Additionally, a MEDICAL GROUP, LAST DATE UPDATED, GEOGRAPHICAL LOCATION 
properties may be specified to locate particular records.
 
Scenario 6)
A server might provide astronomers with the ability to locate 
astronomical data given the specific name of a celestial body, research 
paper name, scientific organization, etc.  Additionally, properties,
such 
as LAST DATE UPDATED, may be specified to locate a particular 
resource.
 
Similarly, a server could be set up to provide other scientific data,
such 
as botany, chemistry, etc.
 
Scenario 7)
Alternative to the scenario 6, is a single server that provides
comprehensive 
scientific data for multiple fields of study.  In this case, the client 
would be able to specify a name of a particular entity, paper name,
research 
group name.  Properties for this search would include the FIELD OF STUDY

(e.g. CHEMISTRY, PHYSICS, BOTANY, and ASTRONOMY) and LAST DATE UPDATED.

Scenario 8)
A private company could set up a CNRP server to allow employees to
locate 
internal reports and employee data given the name of the report and the
name 
or nickname of the employee.

Scenario 9) 
A server could be set up to allow a client to locate a specific company
given 
its name.  Additional properties of GEOGRAPHICAL LOCATION, and TYPE OF 
BUSINESS could be specified to locate Joe's Pizza Parlor which is a 
RESTURAUNT in Suwanee, GA.
 
Similarly, a CNRP could allow a user to specify the name of a registered
store 
or online store to location information about that store.  An example
would 
to be to locate BrandX Widgets in Long Beach, MS.

Scenario 10)
A client specifies that the user speaks English and French.  It also 
specifies that the user is located in Alaska.  He requests results for
the Common Name, "Fuel".  The user expects to get back only results that
he 
can read pertinent to his area.   
 
One server determines that he should be able to understand results in US
English, UK English, Canadian French, and native French but not
Australian
English.  The server also determines that he would be interested in
results
related to areas in Canada, as well as, Alaska because of geographical
proximity.
 
A different server determines that he only receive results related
directly
to Alaska in US English, since Alaska is part of the USA.

Scenario 11)
A client specifies that the user is physics professor at the Georgia 
Institute of Technology.  It does not specify which language she speaks.
The client request results for the Common Name, "Black Hole".  
 
One server, which specializes in scientific data, determines that the
client
wishes to see all related results regardless of the language the results
are written in.  It prioritizes results with those related to physics
preceding
other ares of study, such as literature.  It also prioritizes results
from 
the Georgia Institute of Technology above other results.

A second server, which specializes in general information, returns
results 
referring to businesses registered with the common name, "Black Hole".  
It only returns values that are associated to businesses within the 
continental US.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 1 Dec 1999 22:37:32 PST

# Below are potential usage scenarios drawn from
# the Goals and Requirements document.  The purpose
# is to test the protocol document for completeness
# and accuracy.

Just to clarify goals here; I'm all for completeness
and accuracy, but I'd judge simplicity and likelihood
of deployment as higher in value.

I'm not sure that the scenarios you've laid out are
realistic to expect to work well, or even particularly
important.

It would seem more important to focus on defining a
well-known common schema that all clients and servers
are expected to support, and then having a simple
extensibility mechanism.

# For example, a well known 'Medical' schema type might also support
#   a property for 'FieldOfStudy' with defined values of
# 'Internal Medicine', 'Surgery', 'Epidemeology', etc.

This example is quite problematic and points to some
of the problems in trying to create what seems like a
general property-based search system with controlled
vocabularies. For example, are the various fields of crystal
therapy and mesmerism considered "Medical"? Shouldn't
they be categorized as "FieldOfStudy" of "Superstition"
instead of "Medical"?

I think, in addition to location & language, we need
one other property which is generally known as "Topic"
and whose values are taken from a careful subset X
where there is a book in print with title "Dictionary of X".
(Now, Amazon.com reports 16672 books with the word
'Dictionary' in the title, so that may not be restrictive
enough, and seems to also leave out place names, directories,
etc.

The general idea is that the categories actually need
to be very broad. There's no use in having a directory of
"types of shoes". It's not even clear to me that it's useful
to have more than a few broad categories... the more you
require the user to specify, in advance, the category, the
more you're asking for a complex directory search rather than
a Common Name lookup.

Perhaps it's useful to distinguish between the names of
things as they might appear in a dictionary (if sufficiently
well known), which would include people names, plant names,
organizational names, place names, etc. and the titles
of creative works, but even that distinction isn't always
clear.

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 2 Dec 1999 18:52:10 -0500

Hello all,

By way of retro-introduction, let me say that Ben's scenario work
is an outcropping of the meeting in Washington, wherein we agreed
that we should settle on some common scenarios and make sure that
whatever developed protocol would handle those correctly.

My sense is that 5-6 scenarios, or even fewer, will be adequate
for making sure we hit the high points for things like

        . making an assertion about what one is looking for,
          as opposed to the directory-service-like query that
          tightly binds the scope of valid answers

        . how to handle matching of common names/property values
          in the light of character set encodings and complete,
          partial, or nonexistent information about language of
          data, query.  As was pointed out in Washington, we're
          not going to solve here what people have been unable to
          solve anywhere else -- that kind of matching! -- so
          what is the appropriate behaviour?

So, with that in mind, I'd like people to consider Ben's draft of
scenarios and propose changes/alternates/deletes/additions so that
we can have a core set of agreed-upon scenarios as some kind of
common knowledge.

Sound reasonable?

Leslie.

--

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

"Square peg, round hole:                         Leslie Daigle
   Social reality, or engineering problem?"      [email-masked]
                       -- ThinkingCat

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