The Benefits of
Semantically Structured Metadata
(Part One)
You mean there are benefits?
Last week I compared the semantic
structures approach to metadata with
the modularized approach to building homes from Lincoln Logs. I also contrasted this
method with the approach to building homes from monolithic, prefabricated parts.
I hinted at my feeling that flexibly providing for future extensibility should be a
goal of any metadata standard. This week I would like to propose some future
scenarios that demonstrate the benefits of a flexible, semantically structured
metadata standard.
My, what an intelligent tool you have!
People (including myself) have been playing up the relationship between the metadata implementation and
the tool that searches through it. We keep implying that there's some way that the tool can
understand the metadata. What could we possibly mean by that? Let me give an example.
The IMS metadata dictionary contains a list of terms (or little notched logs, in last week's
example) from which metadata can be built. Last week I used the examples
Meta-metadata.Create.Person, and
LifeCycle.Create.Contribute.Person,
the person who created the metadata, and a person who contributed to the creation
of the resource, respectively.
See how I got the meanings? Basically just by reading backwards - seems easy enough.
You might say, "So how does that make semantically structured metadata special?
I could just read the field name backwards regardless of whether the metadata is
semantically structured or not." Sure you could. But unless there was a dictionary and grammar,
as I described last week, your search tool couldn't.
Say I took some terms from the IEEE LOM dictionary and arranged them in a new way
(recognizing, of course, that a monolithic metadata standard won't
even let me create this new arrangement -- it only provides me with predetermined parts), like this:
Technical.Format.Description
Now even if a structured metadata
implementation would let me create this kind of entry, the information in this
metadata field is worthless to a tool that doesn't know how to use a dictionary and grammar
-- the tool has no way of interpreting it. The "dumb" tool only understands
the metadata fields defined by the "master schema."
So how could an understanding, or "intelligent" tool help me use metadata based on this new combination of terms?
Imagine yourself searching through an archive of learning objects,
looking for an image of the Mona Lisa. Your search tool might know the
most common image formats and return only search
results that describe an object of one of those types (say, .jpg or .tif).
If the only Mona Lisa available was in a format your
search tool wasn't aware of it might not report it.
And if the metadata was built from large prefab parts,
you and your intelligent search tool would be left out in the cold.
However, if the metadata was semantically structured, then
your intelligent tool might see a metadata entry like Technical.Format.Description
and be able to infer that there is a description
of this file format it doesn't recognize. It might then respond:
"I found one Mona Lisa entry in an unknown format -- however, the word 'image' appears in the format
description. Would you like to read the description?" You could then learn about a wonderful new image format,
and get the object you needed to support your instruction.
You can't have one without the other...
When used in combination, semantically structured metadata and a tool that understands
semantic structures have enormous potential. Even if the kind of interface to information I described
above were the only application of the structured approach it would be well worth it. I should stress
here that these benefits a reaped only when the semantic structure approach is applied to both
the metadata and the tool. Separately, a structured metadata standard and a tool that understands structure
are about as useful as a key without a lock, or vice versa. I believe that the additional functionality
and improvements in user interface that semantic structures make possible justifies the additional effort
necessary to create client and server implementations.
But perhaps you prefer a doomsday argument.
I mean, if everyone in the world will just implement the
IEEE LOM standard exactly as specified, as long as
the standard keeps pace with users' needs
functionality like this will never be required.
However, as long as there is a chance of people "extending"
the standard (as web browser vendors have done with HTML, for example),
I believe we should provide for these "improvements," legitimate and otherwise,
to the degree that we can.
Compared with a monolithic approach,
semantic structures allow us to achieve greater
functionality while providing an cleaner, easier path to extension.
| 
