[tei-council] addition of <availability>

[Mylonas, Elli]

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.

 --elli

On Tue, Sep 9, 2014 at 12:27 PM, Mylonas, Elli <elli_mylonas at brown.edu>
wrote:

> Hi all: adding it into biblStruct, outside the series, monogr or analytic
> is one more general way to go. It's completely out of the scope of the FR,
> however, which only mentions the sub elements.
>
> I like the idea of generalizing, but this is a new discussion. It's also
> true that as these are sibling elements, we may want to hold off on all of
> them. if we hold off on <monogr>.
>
> On the other hand, Fabio is implying that we should rethink bibliography
> which much larger and more fraught.
>
> We added it to model.biblpart for the other types of bibliographic entries
> and were trying to get some parallelism in structured bibliography. --elli
>
> On Tue, Sep 9, 2014 at 12:20 PM, Fabio Ciotti <fabio.ciotti at uniroma2.it>
> wrote:
>
>> > On 14-09-09 08:31 AM, Syd Bauman wrote:
>> >> Well, we *have* already discussed it at a face-to-face, but
>> >> apparently we didn't do anywhere near a thorough enough job.
>>
>> There is always space for more discussion.... ;-)
>>
>>
>> > Having re-read the ticket, I'm not sure about that. It would mean that
>> > <availability> is not available anywhere in <biblStruct>. Council
>> > already agreed that it should be in <analytic>, <series> and <monogr>.
>> > Elli decided also to put it in <edition>, but I think we could roll that
>> > one back on the basis that we haven't had a chance to discuss it, and it
>> > may not be necessary given the other locations it will be available.
>> >
>> > There's no dispute about <analytic> and <series>, so we should implement
>> > those as we decided. The remaining issue is only about where it should
>> > go in <monogr>, so I'd suggest deciding right now by email whether it
>> > should go directly in <monogr> or in <imprint>, as Kevin argues. If we
>> > can't decide, then we should hold off on the decision about <monogr>,
>> > but still put it in <analytic> and <series> for now.
>> >
>> > Let's have a quick poll, in case it turns out we're all actually in
>> > agreement anyway:
>> >
>> > Kevin says that "Since <publicationStmt> is akin to <imprint> just as
>> > <editionStmt> is akin to <edition>, I suggest that if we want to support
>> > use of <availability> inside <monogr>, it should be allowed only as a
>> > child of <imprint>, which contains information relating to "[. . .]
>> > distribution of a bibliographic item". Just as bibliographies sometimes
>> > describe editions and sometimes copies, bibliographic items may be
>> > editions or copies."
>> >
>> > I find that quite convincing, so I vote for <availability> as a child of
>> > <imprint> and not a direct child of <monogr> (since a <monogr> must
>> > always have an <imprint>).
>>
>> I do not agree since in any bibliograhic metadata schema that kind of
>> info goes in the notes area or is a  top level element, but definitely
>> it is not part of  the publication area (ex in MARC21 is 506 or 540
>> and in MODS or DC is a top level element). I still vote for putting it
>> as a top level inside <biblStruct> model.biblPart, since in that way
>> we can say that the particular item object of the bibliographic
>> description is under certain access condition without going the Occam
>> razor rule.
>>
>> f
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>>
>
>