Resending because the reply-to did not include the list; strange.
And I'll add that Dublin Core is certainly a candidate domain for
role-specific metadata. Each such community-specific domain may not
cross over much into others, so I would strive to isolate their
inclusion into editor pick lists by intentional inclusion into
specializations in that domain. In general, metadata screams for
assisted authoring support regardless of the domain, butt the
implementation is very much up to the organization's guidelines
about which fields and values are required. Anarchistic folksonomy
is as religious a viewpoint as value-controlled Dublin Core!
-------- Forwarded Message --------
On 11/6/2014 9:16 AM, Michael
Priestley wrote:
Also looking at the
standard metadata names here:
http://www.w3.org/TR/html5/document-metadata.html#standard-metadata-names
I think those can be a definitive set of recommended names, but I
would not declare an enumerated list, but rather good old CDATA so
that users can supply their own values as well. The "cool factor"
for specialization would be to enable semantic specialization into
simple named containers, which helps defray some of Mark Baker's
very acerbic messaging about DITA. I can envision those standard
names as a domain of named data elements, leaving either othermeta
or data available for as-is use or specialized new domains. I'd
settle on othermeta in general just so that all metadata
processors need only look at topic/othermeta rather than trying to
rationalize two different bases. Let data represent structured
metadata, perhaps, but not by itself compete with othermeta. Maybe
the SC can suggest ways to evaluate that suggestion.
And the registered extensions
here
https://wiki.whatwg.org/wiki/MetaExtensions
Same handling, for simplicity. While this set is interesting, it
is the values on http;//schema.org that drive the Web's business
activities and Google's ranking engine. These will apply to
conscious content word choice for authors as well as to
vocabulary-controlled keyword packing in the header. I think the
issues are more for authoring affordances than for markup design
other than to make sure we enable specializing into the containers
that are easiest to author in.
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.
Perfectly fine with that--fits the usage model I expect--one
common pattern for any and all name/value properties a user or
application may need to manage.
But we might want to
specifically add metadata specialization to the allowed
specialization axes.
That!!
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/michael-priestley
From: "Don R. Day" <donday@donrday.com>
To: dita-lightweight-dita@lists.oasis-open.org
Date: 11/06/2014 09:30 AM
Subject:
[dita-lightweight-dita]
Example
of "blog-equivalent prolog metadata"
Sent by:
<dita-lightweight-dita@lists.oasis-open.org>
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).
<prolog>
<author type="creator">Michael
Priestley</author><!--
Consider whether the "creator" semantic merits a single
name/value othermeta slug instead. -->
<critdates>
<created date="2014-07-12"/><!-- Note that golive and expiry are
needful as well; I'd get by if these were all in othermeta
slugs. -->
</critdates>
<metadata>
<category>documentation</category>
<othermeta name="featureImage"
content="generic.png"/><!--
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
db)..-->
<othermeta name="status" content="draft"/><!-- 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). -->
</metadata>
</prolog>
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 (non-browser) services.
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?
--
Don R. Day
Co-Founder, ContelligenceGroup.com
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday Twitter:
@donrday
About.me: Don
R. Day Skype:
don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in
information?"
--T.S. Eliot
--
- "Where is the wisdom we have lost in knowledge?
- Where is the knowledge we have lost in information?"
- --T.S. Eliot
|