#19 <publisher> children
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>".
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.
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).
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.
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.
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?
Logged In: YES
user_id=1021146
Originator: NO
I think this ticket should now be closed
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.