[tei-council] constraints on <publicationStmt>

[Paul Schaffner]

Ahh, of course. Grouping. MARC 260 has the same problem,
and adopts the same sequence-based solution, albeit by putting 
place first, rather than agency. Neither solution is of course perfect,
since a
single publisher can exist in multiple places and a single place
may (and does) house many different publishers. pfs

On Tue, Sep 30, 2014, at 15:13, Lou Burnard wrote:
> I am pretty sure this was discussed extensively at Council before the 
> change was introduced. The issue may be summarised as follows:
> (a) publicationStmt contains multiple occurrences of th 
> sometings-like-publisher and things-like-publication-details
> (b) there is no grouping element to say which occurrences of the first 
> class go with which occurrences of the second class, i.e. nothing 
> corresponding with "act of publication"
> (c) in its absence we rely on the ordering
> So if something is published by snipcock and tweed at 12 Albemare St, 
> and also distributed by the Oxford Text Archive with idno 345, we give 
> the data in that order, and we know that as soon as we meet a second 
> agency (the OTA in this case) we are talking about a second act of 
> publication.
> 
> You may ask "why not use publicationStmt to do this grouping?" (since 
> publicationStmt is repeatable). I can't remember, but I am pretty sure 
> people didn't like that idea at all.
> 
> So, no, nothing to do with SGML ampersands. For once.
> 
> 
>   On 30/09/14 19:35, Paul Schaffner wrote:
> > Historically speaking, I imagine that need (or at least the perceived
> > need) to choose a sequence arose when XML-ifying the SGML
> > "&" operator in the P3 DTD. I.e., at the P4 stage
> >
> > (p+ | ( (publisher | distributor | authority) & (pubPlace?, address?,
> > idno*, availability?, date?)+ )+ )
> >
> > pfs
> >
> > On Tue, Sep 30, 2014, at 14:13, Fabio Ciotti wrote:
> >> I don't see any reason for enforcing the sequence agency - detail
> >> (leaving aside the fact that I would take away  <availability> from
> >> here...).
> >> It sounds like a sort of "presentational" way of modelling descriptive
> >> metadata elements. For instance, in MODS <originInfo> children are a
> >> repeatable choice.
> >> And it's odd the the fact that agency is mandatory, since we can have
> >> a lot of bibliographic item for which there is no publisher (or it's
> >> unkonwn). Probably <date> should be seen as a more fundamental
> >> element.
> >>
> >> Fabio
> >>
> >> 2014-09-30 0:03 GMT+02:00 Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk>:
> >>> On 29 Sep 2014, at 22:57, Paul Schaffner <PFSchaffner at umich.edu> wrote:
> >>>
> >>>> I think there is actually a rule for this (broken in this case), namely
> >>>>
> >>>> 4B6.5 "If a place of publication ... associated with an earlier
> >>>> edition appears together with the actual place of publication ..
> >>>> of the edition being described, transcribe the places as a single
> >>>> element in the order in which they appear. [example:]
> >>>> "Philadelphia printed, London reprinted."
> >>>>
> >>>> i.e.
> >>>>
> >>>> <pubPlace>Printed at London ; and reprinted at Glasgow : </pubPlace>
> >>>> <publisher>by Robert Sanders...</publisher>
> >>>
> >>> hmm. this is problematic. When converted to valid TEI P5, it would come out as
> >>>
> >>>> <publisher>by Robert Sanders...</publisher>
> >>>> <pubPlace>Printed at London ; and reprinted at Glasgow : </pubPlace>
> >>>>
> >>> which is a bit nonsensical.
> >>>
> >>> This mixture of transcription and controlled order of elements
> >>> isn’t going to work. Bleeargh.
> >>> --
> >>> Sebastian Rahtz
> >>> Director (Research) of Academic IT
> >>> University of Oxford IT Services
> >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> >>>
> >>> Não sou nada.
> >>> Nunca serei nada.
> >>> Não posso querer ser nada.
> >>> À parte isso, tenho em mim todos os sonhos do mundo.
> >>>
> >>> --
> >>> 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
> >> -- 
> >> 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
> 
> -- 
> 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
-- 
Paul Schaffner  Digital Library Production Service
PFSchaffner at umich.edu | http://www.umich.edu/~pfs/