[tei-council] addition of <availability>

[Syd Bauman]

While I appreciate Martin's "go for it" gusto, I don't have much
optimism that we can decide this quickly, precisely because it is
thorny. 

For the record, Elli did *not* add <availability> to <edition>. She
added <availability> to the part of the content of <monogr> where
details about an edition are encoded. (In addition to elsewhere for
the whole <monogr>, not a particular edition.) See [1].

We seem pretty much all agreed that <availability> should be a member
of model.biblPart. Good.

As for <availability> within <biblStruct>, we have several
possibilities:

 1. <availability> should be permitted as a direct child of <series>,
    <monogr>, and <analytic> as Elli has already implemented.

 2. <availability> should be permitted as implemented as a direct child
    of <series> and <analytic>, but as a grandchild of <monogr>
    inside <imprint>.

 3. <availability> should be permitted as a direct child of
    <biblStruct> (presumably along with model.noteLike, idno,
    model.ptrLike, relatedItem, and citedRange after the ultimate
    <monogr> or <series>), but not as a descendant of <series>,
    <monogr>, or <analytic>.
  
 4. <availability> should be permitted both as #1 and as direct child
    of <biblStruct>.

 5. <availability> should be permitted both as #2 and as direct child
    of <biblStruct>.

 6. <availability> should not be permitted inside <biblStruct> in
    this release, giving us time to figure out which of the above to
    do.

Some thoughts:

 * Kevin argues in favor of #3, and he's a librarian.

 * But #3 runs against my lay intuition as to what an "imprint" *is*. 
   Wictionary: "The name and details of a publisher or printer, as
   printed in a book etc.; a publishing house."
   Cowley (via Wikipedia): "A piece of bibliographic information
   about a book, it refers to the name and address of the book's
   publisher and its date of publication as given at the foot or on
   the verso of its title page."

 * Fabio argues in favor of #3, but I'm not sure I understand the
   position. My instinct is that Elli's Tisra example is good
   evidence that <availability> as a child of <biblStruct> alone is
   insufficient. But I may be wrong on that. If you were creating a
   bibliography of various Tisra publications, each analytic item
   that had a different availability would be in its own
   <biblStruct>, no?

Notes
-----
[1] http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-biblStruct.html

> By the way, one question from a slight distance - Fabio is
> approaching this from the point of view of standard bibliographic
> practice. And perhaps biblStruct is meant to satisfy the more
> stringent needs of that kind of bibliographer as opposed to to the
> ordinary "these are the relevant books" type of use, for which <bibl>
> is adequate.
> 
> However - I would think of the audience as well when deciding where
> to put the <availability> element, and draw on bibliographic practice
> as an aid to decision making, and not just as rule. Does this make
> the most sense?
> 
> As noted before, I like the generalization of <availabiltiy> as a top
> level element, but wonder if it would be a problem for resources that
> are broken up and are available in different ways.
> 
> As a side note - one of the things Tizra offers (David D.'s company)
> is a way for publishers to chop up longer works into chapters or
> articles and sell or license single ones to different audiences or at
> different prices. So that's a real life example of a book or
> proceedings whose constituent parts may have different
> availabilities.