Skip to content

Personal tools
You are here: Home » writing » Why Semantic Structures

Why Semantic Structures

Document Actions

Why Semantic Structures

What the heck is a Semantic Structure?

Semantic structure is a fancy term for an organization that represents meaning. For example, an English sentence is a semantic structure. Consider the following sentence structure:

subject - verb - object

Now, before you object, saying "The words have meaning, not the structure!", consider two examples of the previous structure:

Dog bites man.

Man bites dog.

Now, obviously the words have meaning. But, two sentences containing the same words in the same structure can have very different meanings - depending on where in the structure the words appear. So in the first case it is the dog who bites the man, and in the second case the man who bites the dog. Changing the position of the words (or "terms") within the structure changes the meaning of the structure.

So, you ask, how do I know which position means what? To grossly oversimplify, in the case of our three-word sentences above, English grammar tells us that the word before the verb is the subject, and that the word after the verb is the object. The subject is the "doer," the verb is the "done," and the object is the "done-unto." Systems that use other semantic structures (like languages other than English) also need to supply a grammar, or way of interpreting meaning based on structure, in order to be useful.

What does a Semantic Structure have to do with metadata?

Let's say I ask you to build a house out of blocks, and give you your choice of two different sets of blocks. The first set only contains five pieces: three solid walls, a wall with a door, and a roof. The second set are Lincoln Logs, i.e., several different small pieces which can be hooked together by lining up the ends in a certain way. Now consider the answers to the following questions:

  • With which set could you build a house the quickest?
  • With which set could you build a house that best suits you?
  • With which set could you most easily add a new wing or garage if the need arose?

Clearly, the set of Lincoln Logs allows you the highest degree of individuality and flexibility, as well as the greatest possibility for future expansion.

The IMS metadata standard is written like a set of Lincoln Logs, as illustrated in the Table 1 below.

IMS TerminologyLincoln Log Terminology
dictionary of termsbag of differently shaped logs
grammar / structurerule for getting logs to stack properly
schemablueprint (one way of organizing the blocks)
Table 1. Mapping terms from the IMS metadata standard to those of Lincoln Logs.

The IMS metadata standard contains a Master schema, or listing of many possible cabin features like walls, doors, windows, hot tubs, covered porches, tennis courts, etc. It also defines a Base schema (outlining the absolute necessities like walls, windows, and doors) and sample schemas, or specific arrangements of features in the Base schema. These are called Item, Module, and Tool, and are each designed to serve a slightly different purpose (like blueprints of a one-room cabin, ranch, or fort).

That's about enough of that wooden metaphor. Let's look at an example.

There is a term in the IMS metadata dictionary called "person," meaning, "a specific human being." So, as in the dog bites man example, the term "person" itself has some meaning. However, it gets greater meaning by being placed in the following context:


The context, or structure, tells us that this particular person is the "person who created the metadata." In another position in the metadata structure, such as:


Person now means "person who contributed to the creation of this version of the resource."

Now, you may ask, 'if the IMS is recommending specific metadata schemas, like Item and Tool, then why don't they just give us three walls, one wall with a door, and a roof instead of forcing us to build a metadata implementation from small, recombinant terms organized in semantic structures?

Recall from the previous discussion that while the 5 piece approach is the fastest, it is also a dead end. If we want to leave room for ourselves to improve the IMS metadata house in the future we need to build it from little blocks.

What are the benefits of a Semantic Structures approach to metadata?

There are a number of benefits to be reaped by utilizing a semantic structure approach to metadata -- many more than the extensibility issue addressed above.

Say, for example, that your organization decides it needs to extend the Base metadata set in some way. If that extension is done using terms from the IMS dictionary, a search agent who has never before encountered your particular metadata set could still understand it. How? Because it knows the meaning of the dictionary terms and the rule by which they are structured, it can infer meaning from your unencountered (arbitrary) metadata schema. Think about it. When you saw the example meta-metadata.create.person above, if you knew the meanings of the words meta-metadata, create, and person, you probably had a pretty good idea what it meant even before I explained it.

What if you choose to extend the metadata set using terms outside the IMS dictionary, or structures other than that in the grammar? As long as you provide a dictionary or grammar that the search agent can access in order to learn the "meanings" of your terms and structure (link types), the agent could again infer meaning from the structure and interpret your metadata accordingly.

Some thought will show that the Semantic Structure approach to metadata is the same approach being advocated for the instructional resources themselves by the DLE Group at Brigham Young University and others -- the underexplored item of the IMS Item metadata schema. But let's save that discussion for another time. : )
Feedback to

Created by admin
Contributors :
Last modified 2004-06-14 10:08 PM