[tei-council] constraints on <publicationStmt>

Wed Oct 1 04:03:54 EDT 2014

Carved in stone on my iPad

On 1 Oct 2014, at 01:00, Martin Holmes <mholmes at uvic.ca> 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
> 
> 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
> -- 
> 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