IOP Draft 2

Draft 2 instructions

(Sections 2.1 – 2.4, Appendixes A, B, C and G)

2. Representation of information objects

In section 2, you begin the process of determining the metadata necessary for adequately representing the information objects to serve users? needs. You also move into the role of database designer. The first step is to determine the entity level and determine the metadata elements to create a resource description of the object. Next you structure the actual database and explain its technical specifications, and then you write rules for data input.

For Draft 2, this section focuses on the description of the physical information container. Section 4 focuses on metadata elements necessary to represent information content (i.e., describe intellectual content, subjects, topics). When doing Draft 3, you will revise as appropriate the sections below to reflect a focus on representing both the container and the content.

2.1. Entity level

Tasks: Determine the entity level or unit of analysis represented by a single metadata record (e.g., book series, individual book, or book chapter). For simplicity, choose only one entity level.

Narrative: Explain the concept of entity level or unit of analysis and the purpose it serves. State the entity level for representing the objects in your collection. Explain why this entity level is appropriate for representing objects for your users. Your writing should reflect your understanding of the connection between entity level and metadata record. The reader should have a clear understanding of what one record in your database will equal an entity is, what an entity level is, what yours are, and how they relate to your objects.

2.2. Metadata elements and semantics

Representations of information objects are created using a set of metadata elements. These elements support a variety of user tasks, from finding database records to physically obtaining information objects. The metadata element set contains all the elements that represent the objects. There should be a strong correlation between the attributes in 1.3 and the fields in Libib. Elements tend to be more specific than attributes or general characteristics of the objects you discussed in section 1.3. Attributes that are important to your users, as indicated by their questions, should suggest metadata elements for your metadata element set.

Tasks: Translate attributes of the information objects into specifically named metadata elements for describing the objects. For Draft 2, focus on physical description, or elements that represent the information container, but mention all your elements in some fashion. In Draft 3, you will revise this section to include in-depth discussion on the elements that represent the information content. Avoid trying to describe every detail of the objects. If all objects share the same value of an attribute (e.g., all items are CDs, the attribute value for the attribute Format would be CD for all objects), that attribute has no discriminatory power for information retrieval and therefore should not be used as an element.

In addition to considering users’ questions in your choice of elements, consider how the elements assist users in these four tasks: finding information that corresponds to the search criteria, identifying the object described as being appropriate to the search criteria, selectinga specific object that meets the user’s needs, and obtaining or accessing the actual object for use. Note that the last three user tasks rely on the information contained in the metadata record. You may have some elements that do not support specific tasks, but these tasks provide a basis for choosing the most important elements. Consider how value can be added to your system by one or more of your elements, particularly elements that are not usually included in standard bibliographic description.

In section 4 you will focus on subject description, or representation of the information content of the objects. For now, simply add two placeholder elements called Subject and Classification. When you get to section 4, you may rename or add elements for representing intellectual content.

Create Appendix A: Metadata elements and semantics, which names and defines the elements in the metadata element set.

Write narrative.

Narrative: State the number of metadata elements that represent the information objects. Explain in general why the elements are appropriate for the users and objects. Define the four user tasks and discuss which elements or types of elements support each task. Do not list all the elements; summarize. Mention any less-traditional elements that add value to the system. Spell and capitalize element names exactly the same as they are listed in Appendix A.

Refer to Appendix A in an explanatory fashion, as in “Appendix A contains a complete list of metadata elements and semantics” or “(See Appendix A: Metadata elements and semantics.).” Use similar wording to refer to appendixes in subsequent sections.

When you are finished, it should be clear how many elements you have and what they are, how whichever ones support whichever of the four user tasks, and what purpose the elements that do not support any tasks serve. There should be a through discussion of each element.

2.3. Record structure and specifications

The metadata elements in your metadata scheme reflected in Appendix A provide the conceptual foundation for structuring the main database file and metadata records that represent the information objects. In the main database file, each metadata element translates into one or more database record fields. Selected record fields provide access points for searching the database. The record structure and related technical specifications determine the functionality of an information retrieval system. For this report section, you create Appendix B to show the record structure of the main database file, first as desired, then as actually created in Libib. .

Tasks: Decide whether each element in Appendix A translates into one or more than one field (e.g., Creator element may become Author and Illustrator fields). Write names for the fields that are the same or parallel to names of the metadata elements.

Create Appendix B: Record structure and specifications, which shows all the fields in the database record and their database specifications. In this section, you will think out how your fields should perform for the cataloger. Determine the specifications for each field and state these in the table in Appendix B part 1.. For each field, begin the thought process: Should the cataloger be required to input data in this field? How many terms should be allowed in this field? Should the field have a finite controlled vocabulary? Should this field be populated from a pull down list? Should this field be searchable by the end user? Appendix B part 1 is about how your DESIRED database should perform.

It is important to note that Libib may not be able to actually impose the decisions you feel are relevant for each field. Later, you will conduct a SWOT (Strength, Weakness, Opportunity, Threat) analysis of your Libib database, and you may use that opportunity to suggest improvements for the Libib software.

Write narrative. Note? you are to write this narrative from the perspective of what you would like for your desired system. If you mention Libib in 2.3, you will lose points.

Narrative: State the total number of fields in the database record. State how metadata elements in the metadata scheme are structured into fields in the database record, which is then reflected in Appendix B. If each element maps one-to-one to a single field, simply say so. If not, state which elements translate into which multiple fields. (Hint: If the translation is complex, show it in a table with one column for elements and a second column for fields.)

Spell and capitalize field names exactly the same as they are listed in Appendix B part 1.

For each field in your desired database, discuss the following:

• what type of data is cataloged into the field (Text, number, date, image, etc.)
• should the cataloger be required to enter data into the field (i.e., can it be left blank in certain records)
• how many terms total are allowed in the field?
• should the field have a controlled vocabulary?
• should the field have a drop down list?
• should the field be searchable?

This should be a full discussion, not a bullet list with answers. Discuss why you made these judgements for each field. One paragraph per field is recommended.

Generally, this section should demonstrate your understanding of the purpose and functional results of the database specifications and functions. You need to provide sufficient information for the reader to make sense of how you would build your system.

Refer to Appendix B.

When you are through with this section, your instructor should be able to get a good sense of how you would want your database to perform if you had the perfect DMBS. Note that Libib may not meet the expectations here. Further, the instructor should have a good understanding of your decision process for each specification you put on every field.

This is one of the most critical parts of the IOP. If this is less than a page, you are probably not addressing all that is expected.

IMPORTANT: Throughout the report, use terms accurately. If you are referring to the database, talk in terms of fields. If you are referring to the metadata scheme, talk in terms of elements.

2.4. Record content and input rules

Important transition note. In this section, you begin talking about your Libib database. The rules you write in Appendix C and the discussion here are about the fields in the Libib database, not your desired database.

ALSO

These are rules about manually entering data. Do not write rules about downloading records from another source.

To provide consistency in the creation of records, you need to develop rules for the content of database record fields and how data are to be entered into the records. Record content refers to the data contained in the records, while record content rules discuss where to get that information; input rules address directions to put the data into records. The input rules are explicit instructions for the person who enters data values in individual records: the indexer or cataloger. These rules are used only by the technical user to create the records, not by the end user to search the records. They are essentially, your cataloging rules.

Tasks: Create Appendix C: Record content and input rules. The rules cover every field. Each rule identifies the chief source of information, or where data are obtained, for the field. Note that some rules will be revised or added later in the project.

Write narrative.

Narrative: Explain and discuss the purpose of input rules and what these rules address.

Define the concept of chief source of information and explain how it assists in data quality and consistency. State the most common chief source(s) of information in your system: the location of data for the majority of fields. Discuss any rule with unusual or problematic aspects related to your information objects (e.g., locating information that is not in/on the object) and the rationale for the rule. Do not reiterate each rule in the narrative.

When you are finished with this section and Appendix C, a cataloger should be able to catalog any book likely to be added to your collection, without having to come to you for questions on how to do it. The reader should know what input rules are, what content rules are, what a chief source of information is, and why those are important.

Refer to Appendix C. Also refer to Appendix G, sample records showing application of the rules (see below).

Project Appendixes

IMPORTANT: Position all appendixes together following the last narrative section. Start each appendix on a new page (insert a page break). Appendix A begins on a new page after the last narrative section of the current draft. Omit pages for appendixes not yet developed. Use tables included in the template.

Appendix A. Metadata elements and semantics

Tasks (Draft 2): Copy the table format below.

Name and list the metadata elements that represent attributes of the information container. Element names should be descriptive, simple, and distinctive. Use regular words, not abbreviations. Avoid meaningless generic names such as Type, Category, or Description, which can apply to any element.

Write semantics (definitions). Definitions should be broad and not circular (i.e., don’t define a word with itself). Avoid listing data values unless necessary to clarify meaning. An example of semantics for an element named Creator is “Entity responsible for original content, such as author or illustrator.”

Tasks (Draft 3): Complete the table with semantics for Subject and Classification (you may also rename these or add other subject-related elements).

Appendix: Insert this table under the Appendix A heading and fill it in with your own elements, adding as many rows as necessary. Subject and Classification are placeholders to be completed later.

You add rows to this chart as needed.

Appendix B. Record structure and specifications

Here you begin developing the main database for the IR system. Appendix B consists of two parts:

• A table that illustrates the desired plan for the record structure and specifications for each field
• A table that shows how the Libib fields will be used to approximate your desired fields

Tasks (Draft 2): Copy the headings and table format below.

Add a row to the table for each field based on the fields you are have conceived. Fields must follow the same order as your metadata elements. Note that field numbers in Appendix B will probably differ from element numbers in Appendix A ?In the same order? does not mean ?numbered the same?.

Use the columns to indicate desired specifications for each field.

Tasks (Draft 3): Complete the table in part 1, filling in every cell with a specification or a dash. Revise database as needed,

Appendix: Insert subheadings and table below under Appendix B heading and fill it in with your own fields, adding as many rows as necessary. Subject and Classification are placeholders to be completed later.

IMPORTANT: The specifications you list in the table in Part 1 are those you wish for your ideal database.

1. Record structure Desired specifications [ Add rows as needed.]

1. Field comparison [add rows as needed]

?n? means ?continue numbers sequentially?

In this chart, you list your desired fields in the second column. Then in the third column list the corresponding Libib field. For example, if you are using Libib?s tag field as your subject field, then ?subject? goes in Desired Field and ?Tags? goes in Libib Field. The fourth column is for you to make any notes you feel you need to explain the transition from Desired to Libib. For example, if you have a field in the second column that has no corresponding field in Libib, you might enter ?This field cannot be executed in Libib?. This then becomes fuel for your SWOT in draft 4.

Appendix C. Record content and input rules

Reminder? these rules are about your Libib fields

Tasks (Draft 2): Input rules follow a strict five-part format. They must be written for every field in the record structure, in the same order as in Appendix B. For guidance, consult the Input Rules Tutorial. To summarize:

Field #: The number of the field

Field name: Spellings of field names exactly as in Column 3, Appendix B Part 2.

Semantics: Copy from Appendix A, or revise where an element has been structured into more than one field, or when the purpose of the Libib field is significantly different from a desired field

Chief source of information: Primary location of the data needed for the field, usually in/on the object itself.

Input rules: Prescription for how to enter data, including spelling, capitalization, punctuation, how many, etc.

Example: One or two data values for the field drawn from sample objects.

Remember that these rules are for the technical user who creates the records, not the end user who searches them. Hint: Test rules by having someone else try to follow them.

Note: Rules are purely practical: write them as succinctly as possible. Use simple, active verbs in an imperative sentence structure (e.g., “Use sentence-style capitalization.”)

Tasks (Draft 3): Write/revise rules for subject field(s), especially fields under control of the thesaurus and classification field.

Tasks (Draft 4): Write/revise rules for name fields for which the name authority file serves as source of data.

Appendix: Copy the six-part format below for every field in the record structure in the exact order of Appendix B part 2 column 3, inserting appropriate field numbers.

Field#:

Field name:

Semantics:

Chief source of information:

Input rules:

Example:

Use the format just above in your IOP.

The idea here is to provide enough rules to allow your cataloger to enter data without asking any questions. Simple rules such as ?Enter author?s name as seen on source? are not well thought out and will result in point reductions.

Special note:

If you are using a Liblb field such as Notes or Description to contain data from multiple Desired database fields, format your entry for that Libib field in this manner:

Field#:

Field name:

Semantics:

Desired field A (ß here you substitute the name of the field in question) :

Desired field B:

Desired field C:

Chief source of information:

Desired field A:

Desired field B:

Desired field C:

Input rules:

Desired field A:

Desired field B:

Desired field C:

Example:

Desired field A:

Desired field B:

Desired field C:

Appendix G. Sample records

This appendix contains screen shots of records from your Libib database. The screen shots should include every used field, even if this takes multiple screen shots per record. The records should accurately reflect all specifications and rules. You submit a version of this appendix with every draft except the first.

Tasks (Draft 2): Create 3 database records to demonstrate the system so far. Enter data to represent 3 objects in your sample collection, following your own rules. Take screen shots of each record and insert in draft. Use the screen view that shows all the fields in the record. It is OK if you need more than one screen shot per record. Check records as follows:

• Field order and field name spellings must match Appendix B.
• Tag and Call Number fields may be left empty. Note that empty fields do not show in the record display.
• The best way to create these records is a screen cap.

Tasks (Draft 3): Create seven more records for a total of 10 database records to represent all 10 objects in your sample collection, following your additional rules and any other revisions. Take screen shots of records and insert in draft . Check records as for Draft 2, plus:

• All terms in the field controlled by the thesaurus must come from the thesaurus (Appendix D) and must match the thesaurus in form, spelling, and capitalization.
• In the classification field, the classification code in one record must match the example in Appendix E, and all codes should follow the rules in Appendix E.

Tasks (Draft 4): Revise and take screen shots of 10 database records to reflect all final fields, specifications, and rules, including name authority rules and any other revisions. Check records as for Draft 3, plus:

• Although any given record may have empty fields, each field in the record structure must be filled (and therefore displayed) at least once somewhere in the 10 records.
• Data in name fields (e.g., Author, Publisher) must include names from authority records in Appendix F.as