<publisher> children

[TEITechnicalCouncil]

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>".

Original comment by: @nolda

[TEITechnicalCouncil]

This issue was originally assigned to SF user: sbauman Current user is: sydb

[TEITechnicalCouncil]

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.

Original comment by: @lb42

[TEITechnicalCouncil]

• status: open --> pending

Original comment by: @lb42

[TEITechnicalCouncil]

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).

Original comment by: @nolda

[TEITechnicalCouncil]

• status: pending --> open

Original comment by: @nolda

[TEITechnicalCouncil]

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.

Original comment by: nobody

[TEITechnicalCouncil]

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.

Original comment by: @nolda

[TEITechnicalCouncil]

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?

Original comment by: @lb42

[TEITechnicalCouncil]

• labels: --> 627819

Original comment by: @lb42

[TEITechnicalCouncil]

• assigned_to: nobody --> sbauman
• priority: 5 --> 6

Original comment by: @sydb

[TEITechnicalCouncil]

• labels: 627819 --> TEI: New or Changed Element

Original comment by: @sydb

[TEITechnicalCouncil]

• milestone: --> CO

Original comment by: @sydb

[TEITechnicalCouncil]

Logged In: YES user_id=1021146 Originator: NO

I think this ticket should now be closed

Original comment by: @lb42

[TEITechnicalCouncil]

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.

Original comment by: @sydb

[TEITechnicalCouncil]

• status: open --> closed

Original comment by: @sydb