There are two "generic" types of metadata tags in DITA, the data element and the keyword element. Of course there's also the othermeta, but apparently that's supposed to be deprecated soon, and the name suggests its sort of a last resort anyhow.
So the keyword seems to closely resemble tags in web applications, i.e. what is commonly used for "folksonomies". But what is the exact difference between data and keyword, and when should you use which?
The <data> element is primarily for specialization so it's probably not wise to use it directly. The <keyword> element is better.
This:
<metadata> <keywords> <keyword>red</keyword> <keyword>green</keyword> <keyword>blue</keyword> </keywords> </metadata>
will render to this in the DITA-OT XHTML transform:
<head> <meta name="DC.subject" content="red, green, blue"/> <meta name="keywords" content="red, green, blue"/> </head>
If you want to add tags, I'd consider using subject scheme maps, which will allow you to include a list of controlled values.
If you specialize the @base or @props attribute, you can add metadata with much more control. Here, we have a @props attribute specialized to @era.
You can then add the @era attribute to an element in a topic, or to the <topicref> element in a map.
<subjectdef keys="era_attributedef">
<topicmeta>
<navtitle>Era of production by decade and producer</navtitle>
</topicmeta>
<subjectdef keys="producer">
<hasInstance>
<subjectdef keys="sixties">
<subjectdef keys="verity_lambert"/>
<subjectdef keys="john_wiles"/>
<subjectdef keys="innes_lloyd"/>
<subjectdef keys="peter_bryant"/>
<subjectdef keys="derrick_sherwin"/>
</subjectdef>
<subjectdef keys="seventies">
<subjectdef keys="barry_letts"/>
<subjectdef keys="philip_hinchcliff"/>
<subjectdef keys="graham_williams"/>
</subjectdef>
<subjectdef keys="eighties">
<subjectdef keys="john_nathan-turner"/>
</subjectdef>
</hasInstance>
</subjectdef>
<enumerationdef>
<attributedef name="era"/>
<subjectdef keyref="era_attributedef"/>
</enumerationdef>
You are a little off-track here; the keyword element is NOT a metadata element. The keyword element is a generic text element, often used for product names. I think the element that you probably wanted to specify here was the keywords element. Also, you really don't want to write off the othermeta element; it is not deprecated and quite useful.
keywords element
The keywords element can be used either at the topic or map level. It holds a list of terms from a subject vocabulary, tagged with either the keyword or indexterm elements. The keyword and indexterm elements are considered metadata elements, and they should be reflected in output as appropriate for the medium. The indexterm elements commonly generate indices; in XHTML output, the keyword elements generally are added to the XHTML and used for search-engine optimization. (This is standard functionality of the DITA-OT, although the free PDF rendering engine that ships with the DITA-OT does not generate an index.)
data element
Used as-is, the data element represents a property within a DITA topic or map. The following are the key aspects:
By default, processors ignore the content of data elements. However, custom processing can be built that uses the content of specific data elements for formatting and so forth.
Used as a basis for specialization, the data element is especially useful. It enables more precise semantics, as well as enumerations of controlled lists of attributes for specific elements. You can see many examples of its use as a specialization base if you examine the metadata elements used in the bookmap and learning & training specializations.
See the data element topic in the DITA 1.2 specification for some concrete examples.
othermeta element
The othermeta element is designed to hold content for which no existing metadata element seems to apply. It essentially holds a name and value pair. You use the @name attribute to name the property and the @content attribute to hold the value.
When should you use which particular element?
The data element has the @href and the @name and @value attributes that the key.
So you can define any kind of property you may need for your build.
<data name="currentTopNavSection" value="profil"/>
I have a couple of scenarios where I need to provide some path information depending the audience of my documentation. I can use the data element for this.
<data audience="lifeg" name="active-audience" value="lifeg"/>
This one allows me to know which is the active audience when I filter the documentation
Another example would be to attach a javascript which would be specific to a map
I am currently working on a webmap specialization where I specialized data to include javascript and css .
* update 2 *
the data element could be nested. Eliot Kimber explains this in a post. I can not remember which one. The idea is that it can represent a collection of properties
<data name="parent">
<data name="chilproperty1" value="abc"/>
<data name="chilproperty2" value="abc"/>
</data>
this structure is very usefull for specialization purpose.
In my understanding, the data element is not specific. It is a way for authors to document very specific need, specialized or not. It is easy to retrieve the values with xsl later in the build process.
The exact difference? There are many differences. Read the spec (sorry, I don't mean to sound unfriendly).
Here is one difference from the spec that has already been mentioned, but I think is worth highlighting, because it might help you decide which to use (or rather, help you decide whether or not to use <data>):
Processors should ignore the content of the <data> element by default, so the <data> element should only be used for properties and not to embed text for formatting as part of the flow of the topic body.
(See also text elsewhere in the spec beginning: "custom processing may...".)
You can use <keyword> "to embed text for formatting as part of the flow of the topic body", but you should not do that with <data>.
Can you describe your specific use case? (What information do you want to mark up?)
