<HTML><FONT FACE=arial,helvetica><HTML><FONT COLOR="#000000" FACE="Verdana" LANG="0" SIZE="4">all pooped out, are you?<BR>
oh well, the conversation this time lasted longer<BR>
than it ever has before, in my memory, so maybe<BR>
you're just working up your stamina for next time...<BR>
so let me finish off this round...<BR>
</FONT><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4"><BR>
christoph said:<BR>
&gt;&nbsp;&nbsp;  A Markdown document may contain metadata<BR>
&gt;&nbsp;&nbsp;  in a human readable form that the parser converts<BR>
&gt;&nbsp;&nbsp;  to a machine readable form of metadata automatically. <BR>
&gt;&nbsp;&nbsp;  A casual reader will understand the content directly<BR>
&gt;&nbsp;&nbsp;  and without distraction.&nbsp;  Bowerbird will love this.<BR>
indeed, christoph...&nbsp;  because you've begun to describe<BR>
the very system that i use, for the very reason i use it.<BR>
i'll describe it more fully below, but first other stuff....<BR>
i'm not sure i fully understand the mentality that says<BR>
"implementations of markdown 2.0 can toss metadata".<BR>
isn't the objective to dispense with implementations that<BR>
act differently from each other?&nbsp;  ok, sure, i'm not naive;<BR>
i realize that once a "standard" for "markup 2.0" is made,<BR>
someone will come along and "tweak" it for their benefit,<BR>
and then we are once again on the path toward fracture.<BR>
but still, the goal for here and now is to unify all.&nbsp;  right?<BR>
i feel the same way about command-line switches that<BR>
turn on different "modes", like "quirks" and "extensions".<BR>
isn't it our zeitgeist to gather everyone under one roof?<BR>
you'll just ignore (or never learn) features you don't need.<BR>
so everyone gets what they want.&nbsp;  and if it's not possible,<BR>
if you want to use the system you have been using which<BR>
is tweaked the way you want it, just continue to do that...<BR>
it's not like those scripts will stop working or something.<BR>
but manufacturing a situation where all of the differences<BR>
are _blessed_ (rather than removed) is counterproductive.<BR>
now on to "metadata"...<BR>
as for the color of the metadata bikeshed, we have one<BR>
shade of paint -- "simple" -- so that's what it must be...<BR>
you've probably over-discussed it already, without even<BR>
getting to the meat of the matter.&nbsp;  for _most_ purposes,<BR>
the "metadata" is relatively unimportant, which you'll see<BR>
quite clearly if you only begin to concentrate on specifics.<BR>
in a .pdf, for example, the "metadata" consists merely of<BR>
title, author, subject, creator, and keywords.&nbsp;  that's it...<BR>
in an .epub or a .mobi, you can specify a ton of metadata,<BR>
if you want, but there's no standardized way of getting it,<BR>
so you're basically whistling at a noisy construction site...<BR>
(or doing pantomime in the dark, if you prefer that image.)<BR>
unless/until the "microformat" people get an upper-hand<BR>
-- and lord help us if that kind of bureaucracy wins out --<BR>
"metadata" in .html continues to be a rather iffy thing, so<BR>
at least for now, i think this issue needs little attention...<BR>
as for the matter of "tags" or "keywords", they're _lame_,<BR>
to a large degree, because they can be gleaned from the<BR>
text itself in most cases.&nbsp;  and perhaps more importantly,<BR>
such descriptive judgments need to be accumulated over<BR>
the input from hundreds or thousands of "objective" users,<BR>
rather than plugged in by a document's author or publisher,<BR>
or the specter of gaming the system makes it all worthless...<BR>
i'm not telling people not to use tags, but i think it's obvious<BR>
that any worthwhile recommendation system will ignore 'em.<BR>
your metadata often tries to tell lies; google knows the truth.<BR>
there are a lot of consultants selling metadata as a cure-all.<BR>
it's more like snake-oil.<BR>
as for my system...<BR>
as i said, my focus is on _books_, so for me, the concept of<BR>
the "title-page" (plus the "cover") is the one that rules here.<BR>
the first "section" or "chapter" in a .zml file is the title-page,<BR>
and _everything_ on that page is considered as "metadata".<BR>
remember that my first pass consists of separating "chunks"<BR>
-- a sequence of non-blank lines bordered by blank lines --<BR>
so the top chunk (of one or more lines) is defined as the title.<BR>
the second chunk is considered to be the subtitle, and the<BR>
third is considered to be the author.&nbsp;  the "author" chunk is<BR>
required to start with the word "by", so if the second chunk<BR>
starts with "by" and the third chunk does not, my routines<BR>
assume that the book has no subtitle, so the second chunk<BR>
is considered to be the "author" chunk.&nbsp;  subsequent chunks<BR>
are required to be labeled appropriately, such as "edited by"<BR>
or "illustrations by" or "plus additional contributions by" or<BR>
"with preface by", and so on.&nbsp;  you get the picture; it's clear.<BR>
other things which commonly appear on the title-page are<BR>
the publisher's name and often the city where it is located,<BR>
publication date, contact information for the author(s), etc.<BR>
none of this is particularly difficult to parse.<BR>
nor does it sacrifice any power _or_ flexibility.<BR>
other info about the document is obtained in the course of<BR>
analyzing it, like the number of chapters and illustrations,<BR>
the size of the file, the number of references, and so forth.<BR>
you also have to acknowledge, at some point in time, that<BR>
no matter what you do, you ain't gonna make a professional<BR>
book-cataloger happy...&nbsp;  and one of my close friends is just<BR>
such an animal, working in the library system over at u.c.l.a.<BR>
their cataloging workflow can summon hundreds of variables,<BR>
depending on the unique characteristics of a particular book,<BR>
and that's a complexity that we could never hope to replicate.<BR>
at the same time, though, we can get 80% of the utility with<BR>
2% of the effort (yes i did say 2%, and not the expected 20%),<BR>
so that's the sweet spot we need for maximum cost-benefit.<BR>
as i said, there are a lot of consultants selling metadata as<BR>
snake-oil, and the most common pitch is that metadata will<BR>
give better discovery.&nbsp;  that's hogwash.&nbsp;  discovery will always<BR>
be inferior until we develop good collaborative filtering, and<BR>
that's necessary anyway, and fully independent of metadata.<BR>
there's something else that i generally put under "metadata"<BR>
-- which other people do not -- which are the specifications<BR>
used to create the output-formats.&nbsp;  these include things like<BR>
straight-quotes vs. curly, indented paragraphs vs. block, and<BR>
the pagesize (for .pdf), the font, fontsize, leading, and so on.<BR>
this allows the end-user who receives the z.m.l. file to create<BR>
outputs matching what the author intended them to look like.<BR>
in accordance with the all-text-in-one-file mandate of z.m.l.,<BR>
these specifications should be included in the text-file itself,<BR>
and can fall in the "metadata" section, the "colophon" section,<BR>
or in their own "output specifications" section, as you desire...<BR>
and, of course, end-users can also change the specifications,<BR>
so as to create output that is formatted to their own desires...<BR>
</FONT><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4"></FONT></HTML>