Monday, June 1, 2020

Modest Proposal


Modest Proposal for Product Searching
June 1, 2020
 

Over the past few weeks ordering online has been the way to get groceries and non-food items, but I find the whole search process rather tedious and time consuming.  The item database and search process does not compare to the library search process, which is a combination of needing an exact match or a close match. This is a modest proposal of how to adapt library cataloging and searching to the retail experience. The idea is to make the search process fit both exact searching and fuzzy searching needs. 

In a real computer system, there will be one database for the item description, the second for the transactions, and a third for marketing.  These databases will be kept separate for security and performance reasons.  The people who deal with sales, inventory, and accounting functions do not need to know the rules and features of the description database.  The catalogers i.e. describers do not need to know the financials and inventory.  In this paper I am only concerned with the description and searching aspects of products.

The descriptive database is more static when compared to the transaction database.  To facilitate searching and maintenance the descriptive database needs to follow rules including authority work for names and places. The transaction database would handle the inventory, sales and purchasing activity.  The marketing database would include anything that would help in the sales process such as pictures, extended descriptions, and reviews. The display on the customer screen would have information from all of these databases presented in a way that customers could make a purchase decision, place an order or go on to other items.
I will use MARC fields as examples because it is the standard in libraries and that is what I know best.  The rules for library descriptions are complex, well known and can be looked up easily. The rules follow standards.  A commercial database does not have to follow any standards.  One need not reinvent a new system, but I will have to invent some new MARC field descriptions and subfields to better fit realia. 

The first example is an electrical cord that is sold in hardware and home improvement stores.


MARC field
Value
Description
001

Control number generated by the system.  A unique number for the system to use
024
877035760751
Other standard identifier.  This is the bar code on the item that uniquely identifies the item.  This number is supplied by the manufacturer or distributor
028
0242042
Vendor supplied part number
110 2
L.G. Sourcing $e distributor
The 100 level main entry is the maker or distributor of the item.  This is the name on the packaging that indicates the prime vendor (i.e. the vendor who sold the item to the retail store.) This will generally be a 110 for corporate name unless it is obvious that one person is responsible. Subfield $e indicates the type of responsibility
245
Light duty outdoor cord
The 200 level  is used for titles and related fields.  245 is the title statement supplied on the packaging
246 1 1
Cable para exteriors para trabajo livano
Alternate or variant title from packaging.  This is a parallel title in Spanish
257
China
Country producing item
258
30138
Model number
264 1
$a N. Wilkesboro, NC  $b L. G. Sourcing,
Production, distribution statement
270
P.O. Box 1535 $b N. Wilkesboro, $c NC, $e 28659
Address of company
300
$a15 feet, $c green
Physical description
360
$9.98
Trade price This is a descriptive price and may not be the sale price.
500

Brand name: Utilitech.
500

Three-pronged plug. 13 amp. Certified for use in the US and Canada.
650  4
Electrical supplies $xExtension cords
Subject
650 4
Cables $x110/120 volts
Subject
710
Utiitech
Added entry.  This is the brand name.

Here is an entry for food.  If this is sold in several sizes the information would be I the inventory database.


MARC field
Value
Description
001

Control number generated by the system.  A unique number for the system to use
024
4133102496
Another standard identifier.  This is the bar code on the item that uniquely identifies the item.  This number is supplied by the manufacturer or distributor
028
PP 20737-05
Vendor supplied part number
110 2
Goya Foods $e producer
The 100 level main entry is the maker or distributor of the item.  This is the name on the packaging that indicates the prime vendor (i.e. the vendor who sold the item to the retail store.)
245
Red lentils
The 200 level is used for titles and related fields.  245 is the title statement supplied on the packaging
246 1 1
Lentejas rojas
Alternate or variant title from packaging.  This is a parallel title in Spanish.
246 1 1
Lal masoor dal
Alternate title from packaging.  This is a parallel title in Hindi.
257
United States
Country producing item
264 1
$a Jersey City. NJ  $b Goya Foods
Production, distribution statement
270
$b Jersey City$cNew Jersey, $e07307
Address of company
300
$a16 oz, $a 454 grams $c red
Physical description
360
$1.89
Trade price This is a descriptive price and may not be the sale price.
500

No.1 grade.
586
$kKosher $c parve $c vegan $c gluten-free
Dietary status.  I redefined this field.  Subfields -- $k could be kosher or not kosher $c could have value of meat, dairy or parve.. $c could be repeated to include vegan, vegetarian, or gluten-free.
650  4
Foods $xBeans $xLentils
Subject

The search engine should allow searching on any of the fields or a combination of them.  The searchers could search on the vendor numbers.  This should mean when the searchers know the item number, the result should exactly match what they want.  A fuzzy search on all or part of the subject should get near matches. For foods the searcher should be able to make limits such as only kosher foods. If the searcher knows the Spanish name of the item, the alternative title should make a match. If items have alternative names or spellings, this can be taken care in an authority file.

This just a modest proposal because of the frustration I found when searching for items.  I would search by words for foods and the matches had nothing to do with the search terms.  If any company really wants my help to design their databases, please send me an e-mail.

No comments: