[tei-council] addition of <availability>

[Kevin Hawkins]

**I believe I'm on the short list of people who can post to tei-council 
even though I'm not a member of this list.  Syd, if you don't see a 
second copy of this, please forward to the list.**

In my comment at 
https://sourceforge.net/p/tei/feature-requests/484/#d072 , I actually 
argued for:

7. <availability> should be permitted as a grandchild of <monogr> inside 
<imprint>.

But the recent discussion on tei-council now leads me to support option (2).

--Kevin

On 9/9/14 12:33 PM, Syd Bauman wrote:
> 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.