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:
Post a Comment