Topics

Applying Metadata to Topics

punyanjan <psen@...>
 

Hi all,

I have some questions about best practices for applying metadata to
Topics.

1) Some metadata attributes can be assigned at the topic level (using
%select-atts;). But the prolog or metadata elements do not have (%
select-atts;) as valid attributes. This means that for each topic,
our authors have to apply some metadata at the topic level (eg.
platform, rev, status), and others within the metadata element (eg.
prodinfo, audience, othermeta). It would be nice to consolidate this
if possible.

2) We have additional metadata that we would like to enter for each
topic (eg. output, category, level), with enumerated choices for each
if possible. Should we specialize the metadata element to achieve
this? If so, I guess we would need specialized topics to achieve this.

Thanks,
Puny Sen
Developer, Adobe Systems

ehennum5 <ehennum@...>
 

Hi, Puny:

Good questions -- I've embedded some responses.


Hoping that's useful,


Erik Hennum


--- In dita-users@..., "punyanjan" <psen@a...> wrote:

I have some questions about best practices for applying metadata to
Topics.

1) Some metadata attributes can be assigned at the topic level (using
%select-atts;). But the prolog or metadata elements do not have (%
select-atts;) as valid attributes. This means that for each topic,
our authors have to apply some metadata at the topic level (eg.
platform, rev, status), and others within the metadata element (eg.
prodinfo, audience, othermeta). It would be nice to consolidate this
if possible.
Each metadata attribute takes a list of values, which can include
tokens valid for the corresponding elements within the metadata
subelements.

For instance, a topic element can be identified as an administrator
topic either by setting the audience attribute on the topic to the
"administrator" value or by setting the type attribute on the
audience element within the metadata to the "administrator" value.

In particular, the platform attribute is equivalent to the platform
subelement of the prodinfo element within the metadata.

That said, having more fully articulated metadata for the topic
revision level and status might make sense.

2) We have additional metadata that we would like to enter for each
topic (eg. output, category, level), with enumerated choices for each
if possible. Should we specialize the metadata element to achieve
this? If so, I guess we would need specialized topics to achieve this.
There are a few ways to handle metadata extensibility.

If the metadata breaks down into simple name-value pairs, you
can specialize the othermeta element within the metadata. You
might want to provide this specialization through a domain so it
can be used in any type of topic. In the specialization, you'd
probably set the name attribute to a default value that's the same
as the element name and set only the content attribute in each
topic to the value.

If specialization is too much trouble, you can establish a set of
names and use editorial vigilance to make sure everyone uses a
standard name.

DITA doesn't currently have a good basis for specializing metadata
with more structure than a simple name-value pair. A workaround
might be to use a kind of decimal notation in the othermeta name.

For instance, if the structure you really would like is

<output>
<width>8.5</width>
<height>11</height>
</output>

the workaround might be:

<othermeta name="output.width" content="8.5"/>
<othermeta name="output.height" content="11"/>

If you have standard metadata profiles, you might define those
outside of DITA and supply them to the processor, using a key for
the appropriate metadata profile in the otherprops attribute.

If the metadata category is a semantic categorization, you can use
the existing category element.

Anyone else have other workarounds for these problems?