Web Writing That Works!

           A Project of
           The Communication Circle

Guidelines Rants Patterns Poems Services Classes Press Blog Resources About Us Site Map

HomeRants > Goodbye documents, hello objects! > Modeling informative objects > Describe what you create--with metadata




What metadata does for us

What metadata looks like

An attribute describes a particular element

Planning attributes

Planning values

Problems with metadata

For each object specify the relevant attributes

Create guidelines for authors

Describe what you create--with metadata

Metadata is information about information. We need metadata about each object so we can track, customize, personalize, search, and publish that content.

  • Meta means beyond, above, more comprehensive, transcendent.
  • Data refers to any kind of code or content.

You may have heard metadata called

  • Dimensions of information types and content units (JoAnn Hackos)
  • Attributes of elements (XML)
  • Attributes of objects (Object-oriented databases)

What metadata does for us

Creating metadata that describes an object allows us to

  • Find the object, display it, or hide it to your staff, or your audiences
  • Share that object across applications and media
  • Apply transformations to the object using a tool such as the eXtensible Style Language
  • Explain to a human being what the object is, where it comes from, whatever you need to know about it, behind the scenes
  • Identify who wrote the object, where, and when

Related content:

Form for Modeling Metadata (PDF)

eBook: Making an XML DTD Step by Step (PDF, 384K)

Form for Modeling an Object (PDF)

A rhetoric of objects

Complexity theory as a way of understanding the Web

Structuring complex interactive information


 What metadata looks like

Metadata consists of a name and a value.  For example

author ="Susan"

The name of an attribute is the type of information it provides (creation date, modification date). The name, therefore, is generic, like a standard question:

  • Who wrote this?
  • When was it created?
  • What version is this?

The value is the answer to the question. The value is local to the object. If Susan wrote this object, her name gets plugged into the Author attribute as its value.

<description author="Susan">

Programmers, then, describe an attribute and its value as a "name/value pair."

Generally, if you want your audiences to read some text, you make that into an element. If you want to hide this information from your audiences (such as internal pricing, or author name), you often put that information into an attribute. Attributes are behind-the-scenes descriptions of your elements.

An attribute describes a particular element

An attribute describes a particular instance of an element, so, like a parasite fish, it swims along with the object. The attribute lives inside the object, and goes wherever it goes.

You might think of an attribute as a characteristic of the element, an adjective modifying the noun. Example: Color is an attribute, and red may be a reasonable value for that attribute, but in reality, redness cannot be detached from the object itself. You cannot separate the paint from the barn.


Planning attributes

During planning, your job is to figure out what questions an administrator, an author, or a user might ask about an object, in order to operate on it.

You need to create a taxonomy (an ordered hierarchy) of attributes, with standards for their values.

Key question: What criteria would an author, a production person, an administrator, or a member of one of your audiences use to find this particular object?

  • An author may want to locate all objects she created in May of 2003, on the subject Server API.
  • Your marketing folks may want to make sure that you grab and display any objects that have a top priority for a group known as Purchasing Agents.
  • Your production person may need to pull up all JPGs posted in the last hour, to see what is going wrong in production.
  • Your users may want to find all info about the Propeller B Product issued in the last month.

Here are a number of attributes:

Unique attribute of an object

  • ID (unique identifier for this instance of the object class)


  • Creation date
  • Modification date
  • Conversion due date
  • Editing due date
  • Metadata due date
  • Localization due date
  • Legal review due date
  • Approval date
  • Production due date
  • Publish date
  • Expiration date

Staff Attributes of an Object

  • Author(s)
  • Vendor (if any)
  • Owner
  • Editor
  • Approver
  • Bio or credit

Administrative Attributes of an Object

  • Status
  • Version Number
  • Number of versions
  • Size
  • Conversion types needed
  • Rights and permissions
  • Attribution Required?
  • Format
  • Source (of an image, for example)
  • Related elements (pointers to their IDs)

Audience Attributes of an Object

  • Audience Niches
  • Privileges (who can see this)
  • Personal Priority
  • Business rules that apply
  • Work role (job category of people who may need this object)
  • Tasks (actions that involve the information in this object)

Search Attributes of an Object

  • Subject Matter
  • Product line
  • Product ID
  • Product internal cost
  • Pricing scheme (by customer type)
  • Solution or bundle
  • Knowledge Domains
  • Keywords
  • Description
  • Title

Planning values

You must set some standards for the values you will accept for each attribute.

Once defined in your Document Type Definition or Schema, an attribute can only have the type of values you specify there. You may set constraints like these:

Constraints checked by XML parsers

  • The value can be any form of text using any characters in the encoding you use (Ascii, Unicode 8, Unicode 16).
  • Enumerated values (a list of acceptable values, so that authors and editors can pick a value from the list)
  • A unique identifier (a code)
  • A pointer to another object, using that object's ID
  • Pointers to multiple objects, using their IDs
  • A number, or several numbers separated by white spaces
  • The name of a pre-defined entity, such as a reference to a special character, a chunk of boilerplate, or an external file. Or several entities.
  • A notation of file format, such as jpg, bmp, gif.

Constraints subject to software verification

  • Dates (accurate, four-digit years, in sequence)
  • Times (accurate format, within parameters)
  • Boolean values (true or false)
  • Binary Large Object (BLOB), such as an image (rare)
  • Value lists (based only on values in some field in a database, or a predefined list, or open to addition and modification)
  • Compound values (made up of two other values, to create a unique identifier for the object)

Problems with metadata

To get the benefits of metadata, it must be

  • Complete (no object is lacking the metadata)
  • Consistent (the same label is applied over and over to the same kind of object)
  • Manageable (you must be able to confirm that the values are legitimate, through software)
  • Useful (tied to business rules, customization, personalization, search forms)

But most people are erratic in the way they enter metadata.

  • They use different terms to describe the same subject.
  • They forget to mention synonyms.
  • They overlook some attributes, leaving the old, inaccurate values.
  • They make mistakes in spelling, or spell the same word differently in different objects.

So don't count on your authors to get all the metadata right. Even if you force them to check in a new object by filling out a form designed to collect the metadata, they will find ways around you.

Some ways to get more complete metadata

  • Forms that demand only the simplest facts from authors, filling in whatever can be entered automatically.
  • Software that analyzes the situation during creation, and enters its best guesses to fill in more values.
  • Software that analyzes the content, the format, the properties of the object to fill in more values for the attributes.
  • A human being who is dedicated to metadata, and reviews every object for correctness and completeness. An obsessive editor, or, as Boiko calls it, a metator.

You need a metadata group

What if an author discovers that, really, there ought to be another attribute, to distinguish this object from others she has worked on?

What if marketing comes up with a new business rule that depends on a new attribute, such as Flavor?

You need some kind of committee to supervise metadata, resolving questions such as

  • Should we add a new attribute, and if so, what values do we assign to all the objects created before we thought of this attribute?
  • How many values we should insist that authors enter by themselves?
  • Which values should be checked by an editor?
  • Which values can be entered by software, automatically?
  • Should we merge two attributes into one, because they are redundant (very difficult after the system launches)
  • Now that we are adding a new language, should we translate all the values, or leave them in English?

Because metadata affect workflow, searching, assembly, and publication, this committee needs to be open to requests from the rest of the content management team, and from your stakeholders in marketing, documentation, tech support, sales, and throughout the enterprise.

For each object specify the relevant attrihutes

Some attributes must be attached to every object; others may depend on the nature of the object.

And every time you bring in a new group to contribute content, they bring with them new categories of information, ways of thinking about their content. Sometimes your existing attributes will do, perhaps plumped out with some new values. Other times, you have to create new attributes just for them.

You need an attribute if you want to use those values as criteria, to find it, display it, hide it, transform it, or send it to some other system.

Create guidelines for authors

1. Explain why metadata is critical to the success of your system.

2. List every attribute, with the constraints on the values. Give examples of acceptable values, and unacceptable values.

3. Show how to enter the values, in your system.

Next: Create a formal model


Home | Guidelines | Rants | Patterns | Poems | Services | Classes | Press | Blog |
Resources | About Us | Site Map

Web Writing that Works!
  200, 2004 Jonathan and Lisa Price
The Communication Circle
Discuss at HotText@yahoogroups.com
Email us directly at ThePrices@ThePrices.com
Order Hot Text (the book) from Amazon