[Booki-dev] changes to booki-zip format

[Douglas Bagnall]

adam hyde wrote:

> * it seems we are leaving the metadata namespace quite open which is
> great, but should we define data that *must* be present and some that
> are also recommended? For example, "creator" should always be present
> even if they are to be listed as 'unknown' or 'orphaned', whereas
> "contact" (contact details of the creator) could be a recommended
> inclusion.


Yes, we should list required and recommended metadata.  The namespaces
are not open though.  We're using 2 namespaces: Dublin Core and Booki,
and will pass others through without touching them.  Dublin core is
limited (for instance your "contact" idea doesn't fit), and Booki is for
whatever we need that isn't in DC, but nothing more.

> * do we need to define the 'type' options in the TOC in this doc? ie.
> define the characteristics of the booki index structure

that was one of my questions.  I think either that or we drop it altogether.

> * can we eliminate references to 'Authors' and instead use
> 'Contributors'. 'Author' doesn't actually represent accurately the
> diversity of contribution types that people make, nor does it mirror the
> development model of collaborative authoring.

OK.  (The term isn't actually used anywhere in the format itself or the
metadata, just as a synonym for "writers" in describing a field.  The
field itself is a nameless list).

> * what is the relationship between the 'authors' listed in the manifest
> and 'contributors' listed in the example metadata? 'authors' is
> per-chapter? and 'contributors' is a list of all 'authors'. 

Yep.  FM produced books have per-file authorship information, which I
though we might as well keep.  Then the aggregate of all file authors
becomes the book contributor list.

Imported books might also have "creator" fields and probably won't have
chapter level attribution.

> * since it is intended some of the books will be taken into various
> formats do we have a way to define/link layout/css for various types of
> output?

No.  That's kind of beyond the scope of the document, because that is
metadata.  Essentially it would be a matter of defining Objavi options
as fields in the booki.cc namespace.

> * do we need to anticipate fields for forking/branching information for
> when we implement git?

possibly, but that is also metadata.

> * can we define cover graphics somewhere?

yes, kind of.  The way to do that would be put the cover page at the
beginning of the TOC and give it a '"role": "cover"' attribute.

> ---some license issues:
> * do we list the copyright owner in the manifest or the metadata?

Effectively both, but canonically in the metadata.  If the metadata says
something along the lines of "each file is copyright its contributors",
then the per-file contributor list is the copyright list.  If it says
"this book copyright these contributors:..." then the per-file list is
just informational.

> *  licenses should be defined on a per chapter basis and on a per book
> basis - is there a standard way to list licenses in short form?

Sort of.  The RPM format uses a list of abbreviations that has been
adopted by a few other projects.  They're the obvious ones: "GPL",
"GPLv2", "CC-BY-SA", etc.  Another way is use urls.  Objavi does both.

Douglas