|I was just going to suggest the Dublin Core metadata. We are already using it in DITA Learning, so perhaps some of that work can be leveraged?|
Thanks and best regards,
Scott Hudson | PELCO by Schneider Electric | United States | Standards & Information Architect
Phone: +1 970 282 1952 | Mobile: +1 720 369 2433 | Email: email@example.com
Also looking at the standard metadata names
And the registered extensions here
Especially the dc./dc ones.
In map, we've just got navtitle and
data - maybe add othermeta and be done with it? Otherwise we end up overprescribing
metadata elements for the folks who don't need them.
But we might want to specifically add
metadata specialization to the allowed specialization axes.
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
"Don R. Day"
11/06/2014 09:30 AM
Example of "blog-equivalent prolog metadata"
By the way, I've been using the following full-DITA structure
to hold the kind of data that is normally/minimally used to track blog
publishing. Some of these fields are obviously useful for general content
tracking as well (wiki pages may use much of this other than "feature
image", for example).
whether the "creator" semantic merits a single name/value othermeta
slug instead. -->
that golive and expiry are needful as well; I'd get by if these were all
in othermeta slugs. -->
This is the image commonly associated with blurbs, carousels, banners,
etc. wherever the post is referenced. It is not simply an image in the
content because it needs to be regularly identified as a feature image
(and the name itself may be a key for thumbnails and alternate sizes in
The content atttype may use any tokens that a local organization prefers,
rather than trying to attach publishing workflows on DITA's topic/@status,
(which is not even with the rest of the prolog; I think that is a potential
2.0 reconsideration). -->
The HDITA equivalent could be simply a sequence of meta name/value elements,
which begs the question of why DITA had structured metadata in the first
place. That question belongs to the DITA 2.0 scope of discussion--we are
stuck, I think, with using what we have, although we could use othermeta
in the same way to simply replicate the author and date fields as part
of a simple sequence. It would still need to be nested twice for no apparent
reason, but that's invisible to the author if the XDITA editor uses a form
for the metadata inputs anyway.
Maps won't need quite the same data; I think that only dates and status
may apply since maps are more ephemeral in a direct-display workflow. (Search
results, bookmarks, subset print lists, posts by month or campaign, etc.
are all throw-away lists with little provenance, for example.)
The main nature of this metadata is direct publishing workflow; this is
different from standard DITA where the usual role for metadata is source
management (with some publishing slipped in). This may require some thinking
and discussion. One way to think of the difference is to contrast
the two-database workflows of techpubs (manage source/build concerns on
one, publishing concerns on another outside the firewall) with cases where
both source control and publishing are from a single database (like blogs
or wikis) and the DITA is consumed directly by the web application, whether
that be "render-in-browser" like Chris Depopulous's reader),
"transformed on the server" (a la expeDITA model), or "served
via API" to an app for data-munging or content republishing with local
For now, the main question is what other metadata might need to be considered
for other use cases outside the usual techpub model. We'll come across
those as we step through the scenarios. Hmm, do we need a callout for specific
new metadata considerations in the templates?
Founding Chair, OASIS
DITA Technical Committee
LinkedIn: donrday Twitter:
R. Day Skype: don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
This email has been scanned by the Symantec Email Security.cloud service.