[tei-council] addition of <availability>
Martin Holmes
mholmes at uvic.ca
Tue Sep 9 13:40:06 EDT 2014
>
> * Kevin argues in favor of #3, and he's a librarian.
>
I read Kevin's comment as in favour of <availability> in <imprint>.
But I vote for #2 below.
Cheers,
Martin
On 14-09-09 10:33 AM, 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.
More information about the tei-council
mailing list