Problems introduced by content models of bibl and imprint.

[TEITechnicalCouncil]

I was recently tasked with adding <respStmt> to <imprint> (ticket #3408897). In the process of doing that, I encountered some difficulties with the model system which forced me to add <respStmt> manually to the content model of <imprint>, rather than using a class. I think this reveals some problems that need to be addressed.

model.imprintPart "groups the bibliographic elements which occur inside imprints." model.biblPart "groups elements which represent components of a bibliographic description."

model.imprintPart contains: distributor publisher biblScope pubPlace model.biblPart contains: model.respLike [sponsor funder principal author editor respStmt meeting] model.imprintPart [distributor publisher biblScope pubPlace] edition extent series bibl relatedItem msIdentifier

In other words, model.biblPart includes model.imprintPart as well as model.respLike; that was the root of my difficulty, because if I added <respStmt> to model.imprintPart, it would end up being included twice in model.biblPart, once as part of model.respLike and once as part of model.imprintPart. I think there are two specific issues here:

1. Other elements in model.respLike deserve to be in model.imprintPart. Sponsors and funders can perfectly well be associated with an imprint. However, these would also have to be added as individual elements to avoid this conflict.

2. Some elements currently in model.imprintPart (distributor and publisher) actually deserve to be in model.respLike, because they are "responsibilities" in the same way that sponsor or funder are.

I think the cleanest solution to this problem would look like this:

1. Add distributor and publisher to model.respLike.

2. Remove model.imprintPart from model.biblPart.

3. Replace the remaining two elements of model.imprintPart (biblScope and pubPlace) in model.biblPart.

4. Remove respStmt from the content model of imprint, and add it instead to model.imprintPart.

This would have the desired effects of making model.imprintPart and model.biblPart logically complete (they contain everything that they look like they ought to contain), and make them both useful as models.

Original comment by: @martindholmes

[TEITechnicalCouncil]

This issue was originally assigned to SF user: kshawkin Current user is: kshawkin

[TEITechnicalCouncil]

I am not sure that I agree with your premises. <respStmt> is for indicators of "intellectual responsibility" which would not normally include agencies such as distributor or publisher. And sponsors don't sponsor an imprint, they sponsor the publication itself. This is quite a venerable bibliographic distinction, even though there are plenty of counter examples. We should discuss it.

Original comment by: @lb42

[TEITechnicalCouncil]

• milestone: --> AMBER

Original comment by: @lb42

[TEITechnicalCouncil]

Regarding Martin's two specific issues in his ticket:

(1): Martin writes, "Sponsors and funders can perfectly well be associated with an imprint." By "imprint", does he mean "a particular edition" (as people sometimes use "imprint" to mean) or actually "the publication or distribution of an item"? If he means a particular edition, then <sponsor> or <funder> should just be a sibling of <edition>. If he really means the latter, I'm skeptical that there are any title pages out there that really state that a particular sponsoring or funding organization was responsible for publication or distribution but not for the production of the item.

(2): I believe model.respLike was created for those children of <titleStmt>, <bibl>, and later <msItem> that indicate responsibility. Despite its name, it is not for all elements indicating responsibility. Now, I see that <meeting> is a member of this group, which goes against my characterization that these all "indicate responsibility", but I imagine it was added to this model class simply because it should be allowed in the same places as the other elements in this class -- which is evidence that what really characterizes this model class is that it's for children of <titleStmt>, <msItem>, and <bibl> that are not included in other model classes.

So I agree with Lou that <distributor> and <publisher> should not be added to model.respLike, but I also think that we should rethink inclusion of <meeting> in model.respLike. Either we redefine this model class to describe what it actually contains (which would end up being ex post facto) or we create more complicated content models for <titleStmt>, <msItem>, and <bibl> in order to include <meeting> in these directly.

Original comment by: @kshawkin

[TEITechnicalCouncil]

• assigned_to: nobody --> kshawkin

Original comment by: @jamescummings

[TEITechnicalCouncil]

James assigned this ticket to me, but would first like to hear Martin respond to my point (1) below and both Lou and Martin's thoughts on my point (2) below.

Original comment by: @kshawkin

[TEITechnicalCouncil]

Re (1): I suppose I meant sponsoring or funding an edition. You're right that it makes no sense to sponsor or fund an imprint, which is just the bit of the title page carrying the publisher's information. I have no idea if there are any title pages which have sponsorship or funding information alongside the publisher's name, publication place etc.

With regard to (2), when you say "Despite its name, [model.respLike] is not for all elements indicating responsibility,", I have to confess that I assumed it was, and I still think it should be. If not, then it should be renamed to something like model.publicationRespLike, or something like that.

Original comment by: @martindholmes

[TEITechnicalCouncil]

There are definitely title pages that include sponsorship or funding information. But since Martin meant a particular edition and not the publication of an item, I think we can agree that <sponsor> or <funder> should just be a sibling of <edition>.

I would still like to hear Lou's thoughts on (2) before I act on this.

Original comment by: @kshawkin

[TEITechnicalCouncil]

re (2) -- the members of model.respLike are all meant to be agencies which have or wish to claim some degree of specifically intellectual responsibility for the content of the item. So <meeting> is clearly appropriate in cases like minutes of a meeting or (at a stretch) proceedings of a conference, whereas <publisher> is not.

Original comment by: @lb42

[TEITechnicalCouncil]

Argh, my mistake. I hadn't read the definition of <meeting> closely enough and thought it was mentioned for including the name of a conference in a citation, not for the specific case of a document emanating from a meeting. So I withdraw my request from (2) to reconsider the membership of <meeting> in model.respLike.

This leaves (1) to be resolved so that Martin can go ahead and implement ticket http://purl.org/TEI/FR/3408897 . No, wait, Martin has already implemented http://purl.org/TEI/FR/3408897 . So now the question is whether anyone thinks we should allow <sponsor> and <funder> as a sibling of <edition> (in <editionStmt> and <monogr>) so that you can specify a sponsor or funder of a particular edition. The need for this would only arise if a title page (or other source of information) made it clear that a sponsor of funder supported only that particular edition and not previous editions of a work. While it's possible, now that I think about it, I find this fairly far-fetched and would prefer to do this only if someone can present a use case.

I'll close this ticket but leave open comments in case anyone wants to reopen.

Original comment by: @kshawkin

[TEITechnicalCouncil]

• status: open --> closed

Original comment by: @kshawkin

[TEITechnicalCouncil]

Funding agencies regularly fund digital editions of texts, through grants. E.g. all the editions of Early Modern French texts on http://mariage.uvic.ca were funded by SSHRC. Previous editions were obviously not so funded, and future ones may not be either.

Original comment by: @martindholmes

[TEITechnicalCouncil]

Reopening the ticket.

Original comment by: @kshawkin

[TEITechnicalCouncil]

• status: closed --> open

Original comment by: @kshawkin

[TEITechnicalCouncil]

Kevin to go away and replace respStmt with model.respLike in <editionStmt> and review <monogr> with the idea of simplifiying it and including model.respLike. (Council Face 2 Face 2012-09)

Original comment by: @jamescummings

[TEITechnicalCouncil]

First part of this ticket (model.respLike) done at revision 11008. -JC

Original comment by: @jamescummings

[TEITechnicalCouncil]

At the Technical Council meeting in September 2012 in Oxford, it was suggested that we place <respStmt> with model.respStmt wherever it appears in the content model of <monogr> unless it leads to a non-deterministic content model. This would have made <sponsor> and <funder> available as siblings of <edition> in order to specify the sponsor or funder of a particular edition.

However, this would also lead to many other elements being available at the locations where <respStmt> currently is, breaking <monogr>'s complex and content model, which is meant to allow only certain elements in certain combinations.

Instead, at revision 11196:

http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/monogr.xml?r1=11196&r2=11195&pathrev=11196

a) I have allowed <sponsor> and <funder> as siblings of< edition> in order to specify the sponsor or funder of a particular edition.

b) Since the meaning of <meeting> was discussed earlier in the ticket, I have also added <meeting> as a sibling of <title> in order to record that a work emanated from a meeting when there is no other responsible party. Compare this with the example at the end of section 3.11.2.3 (#COBICOR), which emanates from Geoffrey Leech.

Original comment by: @kshawkin

[TEITechnicalCouncil]

• status: open --> closed

Original comment by: @kshawkin

[TEITechnicalCouncil]

Non-deterministic content model fixed at revision 11200 (by removing <meeting> as sibling of model.noteLike). This is no longer needed to support the encoding we want now that <meeting> has been added elsewhere.

Original comment by: @kshawkin