Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#19 <publisher> children

CO
closed
Syd Bauman
6
2007-03-03
2004-08-20
Andreas Nolda
No

According to P4, <publisher> "provides the name of the
organization responsible for the publication or
distribution of a bibliographic item" and <pubPlace>
"contains the name of the place where a bibliographic
item was published".

Consider the following <biblStruct> example, which
includes two pairs of publishers and publication places:

<biblStruct>
<monogr>
<editor>
<persName>
<forename>Johan</forename>
<forename>F.</forename>
<forename>A.</forename>
<forename>K.</forename>
<nameLink>van</nameLink>
<surname>Benthem</surname>
</persName>
</editor>
<editor>
<persName>
<forename>Alice</forename>
<nameLink>ter</nameLink>
<surname>Meulen</surname>
</persName>
</editor>
<title lang="eng" level="m">Handbook of Logic and
Language</title>
<imprint>
<pubPlace>Amsterdam</pubPlace>
<publisher>Elsevier</publisher>
<pubPlace>Cambridge, Mass.</pubPlace>
<publisher>MIT Press</publisher>
<date>1997</date>
</imprint>
</monogr>
</biblStruct>

As the example shows, the <pubPlace>-<publisher>
pairs cannot be explicitly stated.

As a consequence, bibliographic stylesheets have to
rely on some document order convention in order to
determine which <pubPlace> applies to which
<publisher>:

Benthem, Johan F. A. K. van and Alice ter Meulen
(eds.) (1997). _Handbook of Logic and Language_.
Amsterdam: Elsevier and Cambridge, Mass.: MIT Press.

The xml-biblio group (cf. the archives of the
xml-biblio-discuss@lists.sourceforge.net mailing list)
proposes to reformulate the above-mentioned
meta-language definition of <publisher> in a way that
covers the following alternative markup of the example:

<biblStruct>
<monogr>
<editor>
<persName>
<forename>Johan</forename>
<forename>F.</forename>
<forename>A.</forename>
<forename>K.</forename>
<nameLink>van</nameLink>
<surname>Benthem</surname>
</persName>
</editor>
<editor>
<persName>
<forename>Alice</forename>
<nameLink>ter</nameLink>
<surname>Meulen</surname>
</persName>
</editor>
<title lang="eng" level="m">Handbook of Logic and
Language</title>
<imprint>
<publisher>
<placeName>Amsterdam</placeName>
<orgName>Elsevier</orgName>
</publisher>
<publisher>
<placeName>Cambridge, Mass.</placeName>
<orgName>MIT Press</orgName>
</publisher>
<date>1997</date>
</imprint>
</monogr>
</biblStruct>

(P4's content model for <publisher> already allows for
<placeName> and <orgName> children.)

As an alternative, P5 could introduce a wrapper element
for <pubPlace> and <publisher>, e.g. "<publication>".

Discussion

  • Lou Burnard
    Lou Burnard
    2004-08-20

    Logged In: YES
    user_id=1021146

    It is explicitly stated in P4 that "although not enforced by the
    DTD, it is a requirement for TEI conformance that information
    about publication place, address...date be given in that order,
    following the name of the publisher, distributor, or authority
    concerned" (see reference for <publicationStmt>).

    Introducing an additional wrapper just to group these two
    therefore seems unnecessary to me.

    The proposal to include <placeName> *within* <publisher>
    would be a radical re-interpretation of the semantics of the
    element. It is meant to include only the NAME of the
    publishing organization. There is quite a difference between
    that and the place of publication. The only circumstance in
    which (with current definitions) it would make sense to
    include a placeName would be if the name was somehting
    like "Oxford University Press", and then you might choose to
    tag "Oxford" as a placeName -- irrespective of the actual
    place of publication.

     
  • Lou Burnard
    Lou Burnard
    2004-08-20

    • status: open --> pending
     
  • Andreas Nolda
    Andreas Nolda
    2004-08-20

    Logged In: YES
    user_id=950793

    The P4 order convention for <publicationStmt> (in particular,
    <publisher> preceeding <pubPlace>) appears not to apply to
    <imprint> (cf. the reference for <imprint> and the examples
    in 6.10.2.3).

     
  • Andreas Nolda
    Andreas Nolda
    2004-08-20

    • status: pending --> open
     
  • Logged In: NO

    Yes, that is correct. The order of items within an <imprint> is
    not constrained. Nor should it be, since the purpose of
    <imprint> is to represent the imprint on a (probably pre-
    existing) title page which is very likely to vary greatly from
    one book to another. I don't see the relevance of your
    comment.

     
  • Andreas Nolda
    Andreas Nolda
    2004-08-20

    Logged In: YES
    user_id=950793

    Without a wrapper element nor an order convention for the
    publisher's organization name and place name, ambiguous
    cases can arise. Consider the following <imprint>, where only
    one of the <publisher>s has a corresponding <pubPlace>:

    <imprint>
    <publisher>Universitt Stuttgart</publisher>
    <publisher>Universitt Tbingen</publisher>
    <pubPlace>Heidelberg</pubPlace>
    <publisher>IBM</publisher>
    <date>2003</date>
    </imprint>

    Without an document order convention, a formatting
    stylesheet could not know to which <publisher> occurrence
    <pubPlace>Heidelberg</pubPlace> applies.

    Our proposal (either defining a wrapper element for
    <publisher> and <pubPlace> or including both informations
    into <publisher> as an <orgName> and, if any, a
    <placeName>) would resolve the ambiguity without falling
    back on an order convention.

     
  • Lou Burnard
    Lou Burnard
    2004-09-01

    Logged In: YES
    user_id=1021146

    <imprint> can be used in two different scenarios.
    1. When it is used within e.,g. <titlePage>, i.e. when
    encoding an existing published resource. It records what the
    imprint of that resource says. If it is ambiguous in the source,
    it should be ambiguous in the encoding.

    2. When (as in your first example above) you are creating a
    new bibliographic description. Here you have the opportunity
    to organize the information a bit better. I would suggest, for
    this example, that you should supply two imprints, one for
    each publisher.

    However, as we appear to be going round in circles on this
    one, would you mind moving the discussion to TEI-L?

     
  • Lou Burnard
    Lou Burnard
    2004-09-01

    • labels: --> 627819
     
  • Syd Bauman
    Syd Bauman
    2006-09-25

    • assigned_to: nobody --> sbauman
    • priority: 5 --> 6
     
  • Syd Bauman
    Syd Bauman
    2006-09-25

    • labels: 627819 --> TEI: New or Changed Element
     
  • Syd Bauman
    Syd Bauman
    2007-02-02

    • milestone: --> CO
     
  • Lou Burnard
    Lou Burnard
    2007-02-18

    Logged In: YES
    user_id=1021146
    Originator: NO

    I think this ticket should now be closed

     
  • Syd Bauman
    Syd Bauman
    2007-03-03

    Logged In: YES
    user_id=686243
    Originator: NO

    This proposal obviously requires thought and discussion, and particularly the input of the TEI-in-libraries community, many of whom have other TEI commitments at the moment. So it seems very unlikely that we will have the time to create, flesh out, discuss, and implement a proposal by the 1.0 release of P5. Nonetheless, I am concerned that if this proposal isn't handled prior to that, it will be tabled until if & when there is a P6 due to backward-compatibility concerns. I have created a ticket (#300) in trac, the TEI's new method for tracking progress on P5, and am closing this request.

     
  • Syd Bauman
    Syd Bauman
    2007-03-03

    • status: open --> closed