Julia Chambers | Lib202-04 1 Assignment 1: Discussion of Group 2, TeamA …eportjuliachambers.weebly.com/uploads/3/8/5/6/38568707/privacy... · TeamA failed to specify what the new

Julia Chambers | Lib202-04

Assignment01_Individual Paper

1

Assignment 1: Discussion of Group 2, TeamA Database

In designing a refrigerator database for residents of a theoretical hospice facility, TeamA

let the user guide many of the architectural decisions. For that reason, TeamA spent a significant

amount of time defining the user and his or her needs. Nutritional information of each food item,

for instance, would be important to a hospice nutritionist, as would food allergy information, an

item’s vegetarian status, and the amount available for meal planning. TeamA knew that

unambiguous rules were critical for defining the values in the “Item Name” in particular, since

the user would likely always include this field in every search and rely heavily on the search

results to plan meals.

Yet despite careful planning, TeamA’s alpha test played a critical role in restructuring the

database and indexer rules. After entering test records, TeamA discovered several oversights in

the database design resulting in the elimination of some fields, such as “Food Group” and

“Organic: Y/N”. A sampling of mock queries during the alpha test revealed that these fields

either didn’t offer value to the user or were an unlikely option for a low-budget hospice facility.

The alpha test also gave TeamA the opportunity to see where the indexer rules lacked

clarity. For instance, each member of TeamA entered food names differently in the “Item Name”

field during the initial test. This resulted in more detailed information in the rules about

excluding brand names and entering the item as singular or plural, as well as additional examples

and guidelines.

The alpha test further revealed database programming hiccups. TeamA members noticed,

for instance, that some fields programmed to accept “text indexing” should be changed to

“number indexing.” Members also noticed that adding “term indexing” in addition to the “word

indexing” setting in the validation tab would increase the retrieval rate in some of the fields,



2

allowing users to retrieve records using the < and > search options, as the designers had

intended. Unfortunately, TeamA forgot to make these programming corrections in the final

database, and the results were noticed by TeamB in their critique.

Results of the Beta Test

Overall, TeamA was very pleased with TeamB’s critique of their database. TeamB

appreciated the thorough description of the database purpose and user group and mentioned that

the detailed information helped them make educated guesses when the indexing rules were

ambiguous. TeamB found the rules for “Item Name” especially strong. In particular, they liked

the specific instructions to use general names instead of brand names and adjectives to describe

an item’s variety or flavor. They mentioned that the guidelines for determining whether to record

a food as singular or plural were clear and helpful. TeamA had debated whether the rules for this

field were too detailed, too complicated, too overbearing, so it is a relief to know that they were

not perceived as such by the beta testers.

Additionally, TeamB found the “Common Allergens” and the numerous nutritional

information fields (“Total Fat,” “Sugars,” “Sodium”) an excellent idea, especially for our

intended user group. Their feedback for these sections indicated that they thoroughly understood

the purpose of these fields and how the user might maximize retrieval in a query. Finally,

TeamB’s records report revealed creative use of the Note Field, thereby substantiating its

importance to the overall database design.

Room for Improvement

Judicious in their feedback, TeamB suggested several valuable improvements for the

database and a few with which TeamA disagreed. Most beneficial was TeamB’s

recommendation to require the use of validation lists, thereby ensuring meaningful search results.



3

In reviewing TeamB’s records report, it became clear that validation lists would increase

retrieval rates. Since the user wasn’t limited to predefined terms in TeamA’s design, he or she

might misread the rules and input “no” or “yes” instead of “Food” or “Beverage,” for instance.

And if the indexer inadvertently misspelled “fod” or “bevrage”, a search for all “food” items or

for all “beverage” items would miss that record altogether. A validation list in the “Vegetarian”

field (yes, no, unsure) would have been equally simple to create. Using the software to require

entry for this field would ensure that all “yes” responses are retrieved in a search for vegetarian

foods. A validation list in the “Allergens” field is perhaps even more critical: If an indexer

misspelled “penut,” this item would not appear in a search for items containing peanuts.

TeamB’s records report further revealed that the indexers didn’t follow the rule for using the

term “none,” which indicated that no allergens were present in the item. One indexer input “no”

instead. In this case, the user would not retrieve the item that had been recorded as “no” and,

therefore, would not be able to consider it an option for a patient with multiple food allergies.

At one point, TeamA discussed whether or not to create validation lists. Because there

were only a few fields that allowed a limited number of choices, TeamA decided not to create

them. TeamA erroneously believed that because there were few choices and the rules were so

specific, there would be no need for a validation list. The suggestion for this improvement, in

retrospect, is the obvious choice.

A second valuable component of the critique relates to Fields 6-11, which record

different components of the item’s nutritional information. TeamB pointed out one major flaw:

the fields weren’t searchable as intended by TeamA. Because the fields were tagged as “text”

format instead of “number” format and because the fields were programmed for “word indexing”

instead of “term indexing,” a search using < or > qualifiers failed to retrieve appropriate records.



4

Forcing a number entry would also prevent users from entering “none” instead of “0”, which was

specified in the rules but not consistently followed in the beta test. TeamB’s suggestion to

specifying the unit of measurement in the field name instead of requiring the indexer to use it in

the data entry was another excellent point, since it would save the indexer time and also prevent

formatting mistakes. A secondary issue pointed out by TeamB was that the rules didn’t specify

how to quantify the nutritional amounts. TeamA assumed it would be obvious to record the

nutritional data per serving, as indicated on all nutritional labels. This apparently was not evident

to the indexers, although they ended up recording the information per serving anyway.

In addition to these two suggestions, TeamB offered feedback in other areas. For

instance, why not include “Vegan” as a field if there is a “Vegetarian” option? TeamA originally

did have “Vegetarian/Vegan” as a field name. Our rules at that point had asked indexers to

indicate if the food was “vegetarian, vegan, or none,” and had included guidelines for

determining the status. However, TeamA decided to simplify the database, which seemed

increasingly unyielding, and took the “Vegan” out, thinking that vegan residents were less likely

in a hospice facility. However, TeamB’s point was well taken. In retrospect, this author would

advocate adding a “vegan” option back in.

TeamB’s suggestion to add an “other” option to the “Common Allergens” field was

another area of debate in the original database design. Understanding that there are more

allergens than the eight listed in the rules, one member of TeamA did further research on “other”

allergens. Because any food can potentially be an allergen to someone, TeamA decided to stick

with the eight that are legally required on nutritional information labels, and not include “other”

as an option. To compensate, TeamA instructed indexers to input that information into the “Note

Field,” thereby putting the onus of determining other allergens on the user, not the indexer.



5

Another suggestion from TeamB in the “Item Name” field is one TeamA would chose to

ignore. TeamA had instructed indexers to conduct a search for the item before entering a new

record. If the item already existed, the indexer would simply update the quantity with one caveat

– if the item had significantly different nutritional information, then the indexer should create a

new item. TeamA failed to specify what the new item’s name should be, though they did provide

an example that indicated that the item should have the same name. TeamB suggested that the

new entry have a unique name: i.e, “1% milk” or “low-fat milk” instead of “milk”. TeamA

disagrees and advocates sticking with the general item name, since the nutritional data fields and

the “Note Field” already indicate nutritional differences.

Finally, TeamB suggested that the “Quantity” field contain a consistent unit of

measurement to make the field meaningful. TeamA agrees with the idea in theory, however, the

user of this database is sometimes searching for servings, and sometimes searching for

cups/pints/gallons, and sometimes searching for the number of individual items. If “butter,” for

instance, was only quantified as 8 servings, but the user was trying to see if the refrigerator had

½ cup for a recipe, the serving unit of measurement would not offer meaning. TeamA discussed

this problem in the design phase and decided that including different variations of measurement

would be the catch-all solution, especially since the field was designed to be informational, not

searchable. However, more examples and an explanation of TeamA’s reasoning could better

clarify the goal of this field to indexers.

Conclusion

The main take-away from the project for this author concerning information organization

is that the real design of an information retrieval system occurs during the testing phase. Prior to

taking individual items out of her refrigerator and plugging their attributes into specific fields,



6

this author only half-grasped the importance of choosing attributes that fit the needs of TeamA’s

specific user group. It became clear during that initial testing that “Food Groups” are subjective

and therefore less important than “Protein” content and “Total Carbohydrates.” Until this author

had a packet of sliced turkey in her hands, it hadn’t occurred to her whether it was important to

indicate that a food was processed. Nor had the problem of determining quantity been fully

evaluated or expressed meaningfully in the index rules.

The overriding lesson regarding information retrieval is the need to ensure consistency in

indexing. Based on the beta test feedback, TeamA could have taken better advantage of

DBTextWorks software in improving consistency. Rather than simply indicating which fields

were required in the indexer rules, TeamA should have programmed the corresponding fields as

a “required field” in DBTextWorks, thereby eliminating the opportunity for indexing mistakes.

Likewise, including validation lists for the “Food or Beverage,” “Vegetarian,” and “Common

Allergens” fields would have been an equally valuable use of software resources.

In conclusion, the author of this paper has learned the importance of testing – and beta

testing – as well as the need to take full advantage of software to enforce indexer consistency.

These two elements of database design are critical to any information retrieval design project. In

fact, the more complicated the data, the more these two tools of design become true assets.

Group Dynamic Analysis

TeamA maintained a democratic, professional, and respectful process throughout the

project. We communicated through email, Googledocs, scheduled Elluminate sessions, and

conference calls. We all brought ideas to the table, took turns initiating next steps in the project,

and we shared the editing process. By stroke of luck, we all had strong negotiation skills and

were able to listen respectfully to each other. By double stroke of luck, we each came to the



7

project with a certain level of flexibility and willingness to compromise – a rare attribute in

group dynamics. We worked by consensus – if two of us felt strongly about something but the

other didn’t, we talked it through until all of us were able to live with the decision, even if we felt

a different direction would be better for the project.

Regarding my own contribution to the project, I pushed to establish a user group that had

a meaningful need for a refrigerator database. While my teammates were content with a user

group that consisted of college roommates, I advocated for a group with medically related

nutritional needs so we could establish fields that relied on concrete data attributes, such as the

item’s nutritional content. As a professional writer, I knew my strength would lie in writing the

Statement of Purpose and Rules, so I split the initial draft for that with another team member. I

was an active participant in the database design and architecture discussions and offered valuable

design feedback during our group’s initial alpha-test. Another personal contribution included my

strong attention to detail. I was able to predict several problems that indexers might encounter

while inputting information into our database. In some cases, my teammates strongly felt that my

concerns did not warrant a change in design, so it was satisfying (on a personal level) to see my

concerns articulated as areas for improvement in the beta test critique.

1

Lib202_Assignment1

Group2_TeamA (Jonathan Cornforth, Rob Crippin, Julia Chambers)

March 13, 2012

Group 2 Team A: Assignment 1

Statement of Purpose

A hospice facility needs an easy way to monitor the inventory of a communal refrigerator

so that nutritionists can consider the individual dietary requirements of their residents when

planning meals and snacks. Some of these residents must monitor their cholesterol or sodium

intake, others are diabetic or have other health concerns, like food allergies, that require

deliberate and careful meal planning.

Using this database, nutritionists can quickly assess the availability and quantities of food

and beverage items in the refrigerator, while refining their search for items that have, for

instance, low cholesterol and no total fat. This database includes all food items and beverages

stored inside a refrigerator. It does not include other objects or items inside a freezer.

Indexing Rules

Important Indexer Note:

Due to the nature of this database, it is preferable to avoid duplicating records with the

same “Item Name” (see definition of “Item Name” below). So before any indexer enters a new

record, he or she must perform a search to see if the item already exists in the database. Then, the

indexer has two options:

○ If the item does not already exist, the indexer may proceed entering the item into

the database using the indexing rules stated below.

○ If the item already exists in the database, the indexer must compare the existing

record with the item in hand to see if there is discrepancy in the required data

fields. If there is discrepancy, a new record must be created.

Julia Chambers

Highlight

2

Lib202_Assignment1


March 13, 2012

For example, if an indexer is examining a stick of butter, the indexer should first see if

there is already a record for “Butter” in the database. If a record already exists and the nutritional

facts are the same, the indexer should simply update the existing record’s “Quantity” field (see

FIELD 12: Quantity) to reflect the increased quantity of butter. If a record already exists but the

nutritional facts are different (for example, butter with more sodium or less fat), indexers should

create a new record for the butter. A query for “Butter” would then return both records for the

user.

FIELD 1: Record ID

REQUIRED: Yes

POSSIBLE VALUES: unlimited

The “Record ID” is an automatically generated number which attaches itself to a record

at the record’s creation. These numbers reflect the order of entry for records and can be used to

distinguish records which appear similar. Indexers do not need to enter anything in this field.

FIELD 2: Item Name

REQUIRED: Yes

POSSIBLE VALUES: unlimited

“Item Name” refers to the generic name of the food or beverage (e.g., milk, eggs, butter,

ketchup, tea, chicken, and broccoli.) The “Item Name” is not the name of a food group. For

example, “Chicken Wings”, “Eggplant” and “Buttermilk” are acceptable terms, whereas “Meat”,

“Vegetable” and “Dairy” are not. The “Item Name” does not include brand names (Coke, Jif,

Julia Chambers

Highlight

3

Lib202_Assignment1


March 13, 2012

Kraft, etc.). Indexers should exclude brand names in this field, but may include them in the note

field (see FIELD 13: Note Field).

Enter the “Item Name” as you would refer to the item in everyday conversation:

“Olives,” “Bacon,” “Ground Beef.” Use adjectives if they identify the item’s flavor or variety.

For instance, enter “Orange Juice” or “Apple Juice” in lieu of “Juice.” Enter “Chocolate Soy

Milk” instead of “Milk” or “Soy Milk.” Enter “Pinot Noir Wine” or “Red Wine” instead of

“Wine”.

While the adjectives are not essential to the functioning of the database, they offer useful

information to the user. A search for “Juice” will retrieve both “Orange Juice” and “Apple

Juice”, but if the user only wants to know if the refrigerator has “Orange Juice,” entering the

item as such will eliminate the need for the user to review all the “Juice” records. In short, the

item’s generic name is most critical in this field, but adjectives that enable discrimination are

welcome additions.

Indexers should always pluralize the “Item Name” if it is countable. "Countable" means

you would normally ask "how many" of an item there is, rather than "how much." Examples

include eggs, oranges, peaches, burritos, fruit roll-ups, and candy bars. Indexers should use the

singular form of the name if the item is considered uncountable. The item is uncountable if the

indexer must ask "how much" of the item someone has. Examples include milk, soda, oatmeal,

sugar, and cheese. In cases of ambiguity, such as whole watermelons (plural) vs. watermelon

which has been cut into pieces (singular), the indexer can use their best judgment by applying the

“much vs. many” rule. In cases where doubt still remains, indexers may use either form.

Julia Chambers

Highlight

4

Lib202_Assignment1


March 13, 2012

FIELD 3: Food or Beverage

Required Field: Yes

Possible values: Food, Beverage

“Food” constitutes any consumable, processed or unprocessed, natural or artificial item

that is eaten on its own, like an apple or steak, or items that are used in combination with other

foods, such as “Mayonnaise,” “Active Yeast,” “Butter,” and “Ranch Dressing”.

“Beverage” constitutes any item that can be consumed as a drink: “Pomegranate Juice,”

“Mineral Water,” “Chardonnay Wine,” “Soda.” It excludes liquids not typically consumed as a

drink, such as “Vinegar” or “Soy Sauce” which are all considered items used in combination

with other foods and should therefore be indexed as “Food.”

In the unique case of vitamins or supplements that contain macro nutrients, such as fish

oil and protein powder, indexers should consider these non-food items, which fall outside the

domain of this database. Indexers can therefore exclude them from entry.

FIELD 4: Vegetarian

Required field: Yes

Possible values: Yes, No, Unsure

This field is designed to allow nutritionists familiar with the database to quickly narrow

their search to items that are strictly vegetarian. Nutritionists may also exclude all items which

are not vegetarian, allowing them to consider all items confirmed as vegetarian as well as items

which cannot be easily indexed.

Julia Chambers

Highlight

5

Lib202_Assignment1


March 13, 2012

Vegetarian foods are all foods that contain no animal tissue or byproducts of animal

slaughter, including gelatin (present in some candies) and animal-based rennet (present in some

cheeses). For the purposes of this database, egg and dairy products are considered vegetarian so

long as they fall under these guidelines.

If the product is labeled “Vegetarian”, the indexer may input “Yes”. Indexers unsure of a

product’s vegetarian status at first glance should consult the ingredients list. If any animal tissue

ingredients are on the label, indexers should input “No.” If there is no ingredient list to consult

and indexers are unsure about the item’s vegetarian status, they should input “Unsure.”

FIELD 5: Common Allergens

Required: No

Possible Values: Eggs, Fish, Milk, Peanuts, Shellfish, Soy, Tree Nuts, Wheat, None

This field is designed to allow nutritionists to sort through available foods and beverages

to ensure they contain no ingredients to which individual residents may be allergic. By law,

nutrition labels are required to list the following major allergens: eggs, fish, milk, peanuts,

shellfish, soy, tree nuts, and wheat. On the label, these allergens will either be listed separately,

usually below the ingredients list, or included in the parenthesis next to relevant ingredients, for

example “whey (milk)” or “lecithin (soy).” In cases where an item’s label mentions that it has

been processed in a facility or on the same equipment with one of these allergens, include the

allergen in this field. Foods which are themselves allergens, such as eggs or milk, must also be

indexed as containing those allergens.

Julia Chambers

Highlight

6

Lib202_Assignment1


March 13, 2012

Indexers must enter all allergens which are printed on the item’s label, separating each

item with a comma. For example: “Milk, Soy, Wheat”. Alternatively, indexers may use the

“Edit: New Entry” function to add each individual allergen. Indexers must consult the printed

nutritional facts on an item’s label to determine potential allergens and may not rely solely on

their own knowledge in cases where that information is available.

Indexers may rely on their own knowledge to include known allergens for items which

have no label. For example, a grilled cheese sandwich may be indexed as containing “Milk,

Wheat”. If an item has a nutrition label and no allergens are present, indexers should enter

“none” in this field. Indexers may only enter a value of “None” in the case of items with printed

nutrition facts. “None” is an exclusive value and cannot be combined with other values. In cases

of whole or unlabeled foods which do not appear to contain any allergens, such as an apple or

leftovers, indexers should leave this field blank. The onus of determining the allergen content of

those items will rest on the users, not the indexers.

FIELD 6: Total Fat

Required: No

Possible values: unlimited

If the item has a nutrition label, indexers must record the total fat in grams by typing in

the number followed by the abbreviation for grams (g), with no space in between. Examples:

“4g”, “1.5g”, “60g”, and “0g”. It is important that indexers enter “0g” where appropriate rather

than leave the field blank.

Julia Chambers

Highlight

7

Lib202_Assignment1


March 13, 2012

If the item does not have a nutrition label, as is the case with most produce, indexers may

attempt to locate the nutritional data by consulting this website: http://nutritiondata.self.com.

Indexers may use the search bar on this site to find a close match for the food in question and

then input the relevant nutritional facts in this field.

If the item is unavailable here or the item is too ambiguous to accurately record nutritional

information, (e.g.: half-eaten spring roll doused with sweet & sour sauce), then the indexer may

leave the field blank.

FIELD 7: Cholesterol

Required: No


If the item has a nutrition label, indexers must record the cholesterol content in milligrams

by typing in the number followed by the abbreviation for milligrams (mg), with no space in

between. Examples: “20mg”, “50mg”, and “0mg”. It is important that indexers enter “0mg”

where appropriate rather than leave the field blank.








http://nutritiondata.self.com/
















Julia Chambers

Highlight

8

Lib202_Assignment1


March 13, 2012

FIELD 8: Sodium

Required: No


If the item has a nutrition label, indexers must record the sodium content in milligrams by

typing in the number followed by the abbreviation for milligrams (mg), with no space in

between. Examples: “7mg”, “120mg”, and “0mg”. It is important that indexers enter “0mg”

where appropriate rather than leave the field blank.








FIELD 9: Total Carbohydrate

Required: No


If the item has a nutrition label, indexers must record the total carbohydrates in grams by

typing in the number followed by the abbreviation for grams (g), with no space in between.









Julia Chambers

Highlight

9

Lib202_Assignment1


March 13, 2012

Examples: “6g”, “36g”, and “0g”. It is important that indexers enter “0g” where appropriate

rather than leave the field blank.








FIELD 10: Sugars

Required: No


If the item has a nutrition label, indexers must record the sugars in grams by typing in the

number followed by the abbreviation for grams (g), with no space in between. Examples: “8g”,

“14g”, and “0g”. It is important that indexers enter “0g” where appropriate rather than leave the

field blank.





















Julia Chambers

Highlight

10

Lib202_Assignment1


March 13, 2012




FIELD 11: Protein

Required: No


If the item has a nutrition label, indexers must record the protein in grams by typing in the

number followed by the abbreviation for grams (g), with no space in between. Examples: “13g”,

“9.5g”, and “0g”. It is important that indexers enter “0g” where appropriate rather than leave the

field blank.








FIELD 12: Quantity

Required: Yes










Julia Chambers

Highlight

11

Lib202_Assignment1


March 13, 2012

For the purposes of this database, it is important to offer meal planners an idea of the

quantity of each available item. However, because different items are quantified in vastly

different ways, this field will not have a standardized unit of analysis. Instead, the indexer must

determine the most logical unit on a case-by-case basis, adhering to the guidelines below. This

field is not designed to be searchable.

Quantities should be entered in the following format: a number then a space followed by the unit

of measurement. For example: “14 Servings” or “3 Pounds”.

Where servings are available, that unit of analysis is preferred. For example, for a record

of eggs, “12 Servings” or “12 Eggs” is preferable to “1 Dozen”. Likewise, “16 Servings” of milk

is preferable to “1 Gallon.” In ambiguous cases, such as a whole watermelon, indexers may

weigh the item and record it (example: “5 Pounds”) or simply count the item as a single unit

(example: “1 Watermelon”). If the watermelon is sliced, “25 Slices” would also be a valid

option.

Indexers must always include a unit of measurement. For example, in a record for oranges,

indexers must enter into this field “3 Servings” or “3 Oranges” rather than just “3”.

In the case of partially used containers where serving information is not available,

indexers can emulate the following examples, using 0 followed by a decimal point: “0.5

Pitchers” (in the example of iced tea) or “0.75 Tamales” (in the case of leftover tamale).

FIELD 13: Note Field

Required: No

Possible Values: unlimited

Julia Chambers

Highlight

12

Lib202_Assignment1


March 13, 2012

This field is for the indexers’ individual and subjective notations. Indexers may place any

note or notes they deem potentially relevant to residents or meal planners who might need to

search the facility’s refrigerator. Indexers who happen to be aware of resident-specific allergens

that are not included in the common allergen list are welcome to add notes pertaining to those

allergens (example: “This contains sesame seeds. Jon Smith is allergic to sesame.”)

Other examples of potential notes include: “This orange is bruised,” “This leftover cake

belongs to Carol Smith,” “Jif Creamy (brand of peanut butter)”, or “This meat is certified

Kosher.” Complete sentences and standard sentence structure are both encouraged, but neither is

required.

Indexers who wish to add multiple notes may do so either by simply typing multiple sentences or

by separating notes using the “Edit: New Field” option. In the latter case, a series of notes for a

bag of homemade cookies might look like this:

○ Baked for Sally Owens, room 219

○ Communal (limit 2 per resident)

○ Contains walnut

This field is not strictly designed to be searchable, but it can be searched for useful

information. A query for “sesame” in this field would, for example, turn up the note about Jon

Smith’s sesame allergy.

Julia Chambers

Highlight

13

Lib202_Assignment1


March 13, 2012

Data Structure & Validation Lists*

*Note: Team A chose not to create validation lists in their design.

Textbase Structure

Textbase Information

Textbase: C:\Users\jcornforth\Desktop\final docs\Team2A-beta

Created: 2/27/2012 3:43:44 PM

Modified: 2/27/2012 3:43:44 PM

Field Summary:

1. Record ID: Automatic Number(next avail=1, increm=1), Term

2. Item Name: Text, Word

3. Food or Beverage: Text, Word

4. Vegetarian: Text, Word

5. Common Allergens: Text, Word

6. Total Fat: Text, Word

7. Cholesterol: Text, Word

8. Sodium: Text, Word

9. Total Carbohydrate: Text, Word

10. Sugars: Text, Word

11. Protein: Text, Word

12. Quantity: Text, Word

13. Note Field: Text, Word

Julia Chambers

Highlight

14

Lib202_Assignment1


March 13, 2012

Log file enabled, showing 'Record ID'

Leading articles: a an the

Stop words: a an and by for from in of the to

XML Match Fields:

1. Record ID

Textbase Defaults:

Default indexing mode: SHARED IMMEDIATE

Default sort order: <none>

Textbase passwords:

Master password = ''

0 Access passwords:

No Silent password

Julia Chambers

Highlight

15

Lib202_Assignment1


March 13, 2012

Team A’s Records for Team A’s Database

Record ID 1

Item Name Whipped Cream

Food or Beverage Food

Vegetarian No

Common Allergens Milk

Total Fat 1g

Cholesterol <5mg

Sodium 0mg

Total Carbohydrate 1g

Sugars 1g

Protein 0g

Quantity 33 Servings

Note Field Canister is opened, but feels full.

Record ID 2

Item Name Apple


Vegetarian Yes

Total Fat 0g

Cholesterol 0mg

Sodium 1mg

Julia Chambers

Highlight

16

Lib202_Assignment1


March 13, 2012


Sugars 13g

Protein 0g

Quantity 3 Apples

Note Field Fuji, organic

Record ID 3

Item Name Turkey


Vegetarian No

Total Fat .5g

Cholesterol 20mg

Sodium 400mg


Sugars 1g

Protein 12g

Quantity 4 Servings

Note Field Serving size 2 oz; Columbus brand; sliced roasted turkey breast.

Record ID 4

Item Name Tamale


Julia Chambers

Highlight

17

Lib202_Assignment1


March 13, 2012

Vegetarian Yes

Quantity 1

Note Field Left over zucchini and beans

Record ID 5

Item Name Romaine Lettuce


Vegetarian Yes

Common Allergens None

Total Fat 0g

Cholesterol 0mg

Sodium 110mg


Sugars .33g

Protein .33g

Quantity 1 Cup

Record ID 6

Item Name Ranch Salad Dressing


Vegetarian Yes

Common Allergens Milk, Soy, Egg

Julia Chambers

Highlight

18

Lib202_Assignment1


March 13, 2012

Total Fat 49g

Cholesterol 35mg

Sodium 2100mg


Sugars 14g

Protein 7g

Quantity 7 Fl. Oz.

Record ID 7

Item Name Baby Carrots


Vegetarian Yes


Total Fat 0g

Cholesterol 0mg

Sodium 130mg


Sugars 10g

Protein 2g

Quantity 50 Sticks

Julia Chambers

Highlight

19

Lib202_Assignment1


March 13, 2012

Record ID 8

Item Name Havarti Cheese Slices


Vegetarian Yes

Common Allergens Milk

Total Fat 100g

Cholesterol 250mg

Sodium 2100mg


Sugars 0g

Protein 60g

Quantity 10 Slices

Note Field Contains rennet

Record ID 9

Item Name Almond Milk

Food or Beverage Beverage

Vegetarian Yes

Common Allergens Tree Nuts

Total Fat 2.5g

Cholesterol 0mg

Sodium 140mg

Julia Chambers

Highlight

20

Lib202_Assignment1


March 13, 2012


Sugars 9g

Protein 1g

Quantity 4 Servings

Note Field Pacific Natural Foods, Organic

Record ID 10

Item Name Hot Sauce


Vegetarian Yes


Total Fat 0g

Sodium 190g


Protein 0g

Quantity 10 Servings

Note Field Frank's Red Hot

Expiration date not visible

Record ID 11

Item Name Chicken and Vegetables


Julia Chambers

Highlight

21

Lib202_Assignment1


March 13, 2012

Vegetarian No

Common Allergens Fish, Soy, Wheat

Quantity 3 Servings

Note Field Leftover roasted chicken and vegetables from 2/27/12. Original label for the chicken

(bought from the meat counter at Sprouts) lists "Fish" as a potential allergen.

Record ID 12

Item Name Eggs


Vegetarian Yes

Common Allergens Eggs

Total Fat 4.5g

Cholesterol 215mg

Sodium 65mg


Sugars 0g

Protein 6g

Quantity 9 Servings

Note Field Sprouts brand Omega-3 eggs.

Julia Chambers

Highlight

22

Lib202_Assignment1


March 13, 2012

Team B’s Test Records of Team A’s Database

Record ID 1

Item Name broccoli florets, raw

Food or Beverage food

Vegetarian yes

Common Allergens no

Total Fat 0.2g

Cholesterol none

Sodium none

Total Carbohydrate 3.7g

Sugars 0g

Protein 2.1g

Quantity 6

Record ID 2

Item Name miso paste

Julia Chambers

Highlight

23

Lib202_Assignment1


March 13, 2012


Vegetarian yes

Common Allergens soy

Total Fat 1g

Cholesterol 0mg

Sodium 770mg


Sugars 4g

Protein 2g

Quantity 37 servings

Note Field akamiso (red); barley, soy. No wheat.

Record ID 3

Item Name turkey burgers


Vegetarian no

Julia Chambers

Highlight

24

Lib202_Assignment1


March 13, 2012

Total Fat 37.5g

Cholesterol 358mg

Sodium 426mg


Sugars 0g

Protein 79.2g

Quantity 6 servings

Record ID 4

Item Name avocado


Vegetarian yes

Total Fat 35.4g

Cholesterol 0g

Sodium 18.4mg


Julia Chambers

Highlight

25

Lib202_Assignment1


March 13, 2012

Sugars 0.7g

Protein 4.5g

Quantity 3 avocados

Record ID 5

Item Name apple pie


Vegetarian yes

Common Allergens wheat

Quantity 6 servings

Record ID 6

Item Name Swiss cheese


Vegetarian unsure

Common Allergens milk

Julia Chambers

Highlight

Julia Chambers

Highlight

26

Lib202_Assignment1


March 13, 2012

Total Fat 7.1g

Cholesterol 49mg

Sodium 2002mg


Sugars 1.9g

Protein 35.7g


Note Field pasteurized; low-fat

Record ID 7

Item Name quiche w/ broccoli


Vegetarian yes

Common Allergens wheat, eggs, milk

Total Fat 25g

Cholesterol 178mg

Julia Chambers

Highlight

27

Lib202_Assignment1


March 13, 2012

Sodium 50mg


Sugars 6g

Protein 16g

Quantity 6 servings

Record ID 8

Item Name jello salad w/ fruit


Vegetarian no

Total Fat 2g

Cholesterol 0mg

Sodium 9mg


Sugars 2g

Protein 4g

Julia Chambers

Highlight

28

Lib202_Assignment1


March 13, 2012

Quantity 6 servings

Note Field blueberry jello salad

Record ID 9

Item Name green beans


Vegetarian yes

Total Fat 0.1g

Cholesterol 0mg

Sodium 6.6mg


Sugars 1.5g

Protein 2g

Quantity 6 servings

Note Field cooked

Julia Chambers

Highlight

29

Lib202_Assignment1


March 13, 2012

Record ID 10

Item Name prosciutto


Vegetarian no

Total Fat 2g

Cholesterol 20mg

Sodium 480mg


Sugars 0g

Protein 8g

Quantity 3 servings

Note Field Prosciutto di Parma

Record ID 11

Item Name pizza margherita


Julia Chambers

Highlight

30

Lib202_Assignment1


March 13, 2012

Vegetarian yes

Common Allergens milk, wheat,

Total Fat 12g

Cholesterol 20mg

Sodium 520mg


Sugars 2g

Protein 12g

Quantity 3 servings

Note Field leftovers from Pizza Rock

Record ID 12

Item Name steamed rice


Vegetarian yes

Total Fat 2g

Julia Chambers

Highlight

31

Lib202_Assignment1


March 13, 2012

Cholesterol 0mg

Sodium 2mg


Sugars 0g

Protein 5g

Quantity 3 cups

Note Field brown rice

Record ID 13

Item Name frittata w/ mushroom


Vegetarian yes

Common Allergens eggs, milk

Total Fat 6g

Cholesterol 116mg

Sodium 401mg

Julia Chambers

Highlight

32

Lib202_Assignment1


March 13, 2012


Sugars 0g

Protein 13g

Quantity 6 servings

Record ID 15

Item Name milk


Vegetarian yes


Total Fat 2.9g

Cholesterol 9.8mg

Sodium 143mg


Sugars 0g

Protein 9.7g

Julia Chambers

Highlight

33

Lib202_Assignment1


March 13, 2012


Note Field 1% milkfat

Record ID 16

Item Name spinach bolani


Vegetarian yes


Total Fat 3g

Cholesterol 0mg

Sodium 346mg


Sugars 1g

Protein 4g

Quantity 6 servings

Julia Chambers

Highlight

34

Lib202_Assignment1


March 13, 2012

Record ID 17

Item Name whipped cream


Vegetarian yes


Total Fat 60g

Cholesterol 0mg

Sodium 0mg


Sugars 3g

Protein 0g


Note Field cool whip lo-fat

Record ID 18

Item Name Caesar salad dressing w/ anchovy

Julia Chambers

Highlight

35

Lib202_Assignment1


March 13, 2012


Vegetarian no

Common Allergens egg, fish

Total Fat 136g

Cholesterol 91.7mg

Sodium 2533mg


Sugars 6.6g

Protein 5.1g

Quantity 6 servings

Record ID 19

Item Name India Pale Ale

Food or Beverage beverage

Vegetarian yes

Total Fat 0g

Julia Chambers

Highlight

36

Lib202_Assignment1


March 13, 2012

Cholesterol 0g

Sodium 0mg


Protein 1.5g

Quantity 1

Note Field 5.6% ABV

Record ID 20

Item Name falafel


Vegetarian yes


Total Fat 8g

Cholesterol 0mg

Sodium 380mg


Julia Chambers

Highlight

37

Lib202_Assignment1


March 13, 2012

Sugars 2g

Protein 6g

Quantity 4 servings

Note Field chickpeas, carrots, wheat bread crumbs. No fava beans.

Record ID 21

Item Name green curry paste


Vegetarian no

Common Allergens fish

Total Fat 0g

Cholesterol 0g

Sodium 500mg


Sugars 0g

Protein 1g

Julia Chambers

Highlight

38

Lib202_Assignment1


March 13, 2012


Note Field shrimp paste; Mr. Smith is allergic

Record ID 22

Item Name whole wheat bread


Vegetarian yes


Total Fat 1.5g

Cholesterol 0mg

Sodium 210mg


Sugars 4g

Protein 6g


Julia Chambers

Highlight

39

Lib202_Assignment1


March 13, 2012

Team A’s Critique of Team B’s Database

Team B’s statement of purpose is clear and describes the user group adequately. Their

rules are simple, succinct and well-organized which should allow indexers to work quickly.

However, some of their rules may require elaboration to address unique cases or to minimize

subjective interpretations on the part of the indexer.

The database structure appears to have been designed to keep values within fields as

standard as possible and the use of validation lists serves this purpose well. Indexers know

exactly what they need to type in each of the relevant fields and users benefit from consistent,

easy-to-comprehend values. The fields are also all named well.

However, not every field’s rules explain its purpose, and some fields seem to overlap. For

example: “already prepared,” “eaten raw,” and “served cold.” It would seem that, given the

intended users, the relevant information is simply whether or not someone can pull it out of the

fridge and eat it right away.

The following is a brief analysis of each field and accompanying rule.

● Item name -- The item name is subjective, which is fine, but it is difficult to determine

what “common” means, other than perhaps that the brand name is not necessary. For

example, is “romaine lettuce” a common name or should that entry simply be “lettuce”?

This field also requires the indexer to note whether certain items are cooked or raw, but

this information is addressed in separate fields and doesn’t necessarily need to be

recorded twice.

● Food group -- This is overall an understandable and clearly written rule. However, it

would be helpful to have more examples for each food group. Almond milk, for example,

Julia Chambers

Highlight

40

Lib202_Assignment1


March 13, 2012

is difficult to classify because it’s not an actual dairy product and it doesn’t fit well into

the other categories. Clarifying how users might be expected to use this field might guide

indexers to the correct choice. Another potential solution is adding a “miscellaneous”

value or something similar.

● Vegetarian or vegan -- The general definition of vegan vs. vegetarian is adequate and

succinct. Some elaboration could help indexers address items which they may be unsure

about. For example, the rule mentions that animal by-products may appear in certain hard

cheeses, but it doesn’t explain what these by-products might be or how indexers can

check for them. An “unsure” value might provide some leeway for indexers, although it

isn’t necessary.

● Beverage -- This rule is simple and straightforward. Examples may be warranted for

unique cases, but it’s probably safe to leave this field to the discretion of the indexer.

● Servings -- While this is somewhat subjective, it is adequate to determine quantity. One

question which comes up: should the indexers rely solely on their own idea of what a

serving is? For example, many people eat two Pop-Tarts at a time but a serving is

actually only one.

● Already prepared -- This rule requires elaboration, specifically as to what “prepared”

encompasses. Examples which may need clarification include dishes that need to be

heated up, produce that needs to be washed or packaged foods or beverages which do not

clearly indicate how processed they are. This field might also be combined with the

following two or addressed differently.

Julia Chambers

Highlight

41

Lib202_Assignment1


March 13, 2012

● Can be eaten raw -- This is perhaps a redundant field, since it is partially addressed in the

“Item name” category as well. This area also needs more clarification since there are

exceptions such as whipped cream or cookie dough.

● Can be served cold -- This is a field that clearly has its users in mind but nevertheless is

another gray area. It is unclear if this refers to food which poses a health risk when not

heated or simply to food which tastes better when heated, such as leftover pizza.

● Meal type -- This is a good category for meal-planning; however the rule is very

subjective. It’s a judgment call on behalf of the indexer since “commonly” held ideas

about food are difficult to determine. For example, are carrots a snack or an ingredient in

part of a meal? Is hot sauce most commonly used with eggs for breakfast or on meat at

lunch or dinner? Beverages, such as milk, are also difficult to place. One possible

solution is to allow indexers to choose as many values as they feel is appropriate, similar

to how the “Food group” category works.

● Expiration date -- This category meets the general purposes of the user group. It is clear

but perhaps difficult to determine for some items, such as produce or processed foods

with worn labels. It would be helpful if the rule explained how these exceptions should be

addressed.

● Junk food -- This category has the user group, potential healthy eaters, in mind. The

definition, while certainly generalized, is succinct and adequate. However, there is

potentially some overlap in purpose with the “fats and sweets” food group value and

opinions may vary from indexer to indexer as to what constitutes “little nutritional

value.”

Julia Chambers

Highlight

42

Lib202_Assignment1


March 13, 2012

Overall, Team B’s statement of purpose, database design, and rules offer indexers and

users a quick and simple experience. It is clearly written with the intended user group in mind.

They have chosen to rely on the discretion of the indexers and, in cases where the indexers and

users are the same people, this should prove very efficient. In cases where multiple indexers may

be involved, or where the indexing group is different than the user group, more elaboration and

clarity may be necessary. Team B may also consider combining some of their fields or

elaborating on each field’s intended purpose.

Julia Chambers

Highlight

Documents

Julia Chambers | Lib202-04 1 Assignment 1: Discussion of Group 2, TeamA …eportjuliachambers.weebly.com/uploads/3/8/5/6/38568707/privacy... · TeamA failed to specify what the new