Attributes and Values Describing Entities

Attributes and values Attributes—also known as characteristics, properties, or elements—are the categories we use to describe a specific kind of entity more precisely. Values are a way to describe the possible contents of an attribute.

Examples of attribute/value pairs For Web pages, some attribute/value pairs might be: Attribute Value Address A valid URL Date modified A date in MM/DD/YYYY format Links to other pages A list of valid URLs

More examples of attribute/value pairs For restaurants that I to which I might consider taking my sister when she visits Austin over spring break, potential attribute/value pairs might be: Attribute Value Sense of place A scale to represent the restaurant’s uniqueness as an Austin or Texas experience Grease quotient The number of margaritas required to cut through the richness of the food Ease of transport A percentage that represents the likelihood that I can get us there, park, and get us home without harming us, others, or property

Schemas, or attribute sets A schema is a set of attributes and associated value parameters designed to describe a particular type of entity. Schemas may be encoded in a particular syntax for manipulation by people or computers. Schemas may also be associated with rules for creating records (that is, assigning attributes and values to specific resources).

Dublin Core: a schema The Dublin Core is a metadata schema for describing (primarily) information resources. It includes a set of elements (attributes) and associated value parameters. A goal of Dublin Core is to provide a simple set of standard attributes that apply to most documents. By making it easy to comply with Dublin Core standards, interoperability of metadata between different collections may be facilitated. Interoperability is the term used to describe when two metadata systems can be easily federated, or aggregated. For example, because all library catalogs use the same basic set of attributes, because they follow the same rules for assigning values to those attributes, and because they use the same encoding syntax to express those values (MARC), the library here at the University of Texas can take the Library of Congress catalog record for a book and essentially just use it (there is actually a term for this: “copy cataloging”). Or, you can search all library catalogs in similar ways and get similar results (the interfaces to the catalogs may differ, but the structure of the records is the same). This is quite important for “digital libraries” which may be formed of multiple online collections. Ideally, one wants to just take a collection and its metadata and magically add it to one’s initial set of resources and have everything just...work. This is the dreamed-of goal of perfect interoperability. In practice, things get much more complicated. People find that Dublin Core, for example, doesn’t meet all their needs, so they adapt it, adding new attributes, not using others, interpreting some attributes differently than the Dublin Core usage guide suggests. Or even if they do “follow the rules,” they still have chosen to represent the Subject attribute with, for example, free keywords, while your digital library uses LCSH. The metadata will then interoperate to some extent, but there won’t be consistency in the semantics of what values in the Subject element actually mean. Some people might say that true semantic interoperability is essentially impossible. Others would say that may be, but the idea is too potentially useful not to try. We’ll talk about this more next week, when we delve into the idea of control, of picking one preferred term to be the authorized label for a concept and specifically designating potential synonyms for that defined concept. Syntactic interoperability can be an easier goal to achieve, just being able to translate from one encoding scheme to another, from MARC to XML, for example.

Dublin Core elements (attributes) “Simple” Dublin Core includes 15 basic elements. When assigning metadata to resources, all elements are optional and repeatable. In “qualified” Dublin Core, there are 3 additional elements, and some elements can be refined. For example, Abstract is a refinement of the Dublin Core Description element, making the element more specific. To support the interoperability goal, metadata authors must assume that qualifiers may be “dumbed down” if systems don’t support them. That is, an Abstract element may be “dumbed down” back to the Description element.

Dublin Core values The values for Dublin Core elements may come from controlled vocabularies. For some elements, potential vocabulary encoding schemes are identified (such as the “DCMIType vocabulary” for the Type element). For example, the creator of metadata for a particular collection might specify that values for the Subject element must be selected from the Library of Congress Subject Headings (LCSH) and not by entering free keywords.

Audience for Dublin Core records The “audience” for Dublin Core metadata may be a person, or it may be a computer, using the metadata to facilitate search or do other processing.

Dublin Core element descriptions Hillman’s usage guide provides a label, text description, usage guidelines, and examples for each element. You may find this format useful in thinking about how to create similar descriptions and guidelines for your schema assignment.

Title element Label: Title Element Description: The name given to the resource. Typically, a Title will be a name by which the resource is formally known. Guidelines for creation of content: If in doubt about what constitutes the title, repeat the Title element and include the variants in second and subsequent Title iterations. If the item is in HTML, view the source document and make sure that the title identified in the title header (if any) is also included as a Title. Examples: Title="A Pilot's Guide to Aircraft Insurance" Title="The Sound of Music"

Type element Label: Resource Type Element Description: The nature or genre of the content of the resource. Type includes terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the DCMIType vocabulary ). To describe the physical or digital manifestation of the resource, use the FORMAT element. Guidelines for content creation: If the resource is composed of multiple mixed types then multiple or repeated Type elements should be used to describe the main components. Because different communities or domains are expected to use a variety of type vocabularies, best practice to ensure interoperability is to include at least one general type term from the DCMIType vocabulary in addition to the domain specific type term(s), in separate Type element iterations. Examples: Type="Image" Type="Sound" Type="Text" Type="simulation”

Dublin Core power? Some Dublin Core elements may not be that easy to describe after all, but in its goal of facilitating interoperability, DC focuses on descriptive power, not exploitative.

Summary A schema is a set of attributes to describe a defined group of entities, along with associated value parameters and usage guidelines. We use the schema to produce metadata records that describe specific objects. Dublin Core is a schema for describing information resources in a way that facilitates interoperability between metadata systems. Defining attributes in a way that makes it clear how to create records with them can be quite challenging, even for seemingly basic descriptive attributes.