[tei-council] constraints on <publicationStmt>

Tue Sep 30 20:00:21 EDT 2014

> 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

Encoding relationships through mere contiguity is a dreadful principle, 
especially in the context of markup language founded on hierarchy. It 
always makes me nervous to see this sort of thing. Another example is:

<list type="gloss">
  <head>Report of the conduct and progress of Ernest Pontifex.
    Upper Vth form — half term ending Midsummer 1851</head>
  <label>Classics</label>
  <item>Idle listless and unimproving</item>
  <label>Mathematics</label>
  <item>ditto</item>
  <label>Divinity</label>
  <item>ditto</item>
  <label>Conduct in house</label>
  <item>Orderly</item>
  <label>General conduct</label>
  <item>Not satisfactory, on account of his great
    unpunctuality and inattention to duties</item>
</list>

We should be replacing this sort of thing with properly-nested structures.

Cheers,
Martin

On 14-09-30 12:37 PM, Paul Schaffner wrote:
> 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