Feature Request: <projectDesc> content model needs to be richer

[traceyeh]

According to the <projectDesc> definition, project description
"describes in detail the aim or purpose for which an electronic file was
encoded, together with any other relevant information concerning the
process by which it was assembled or collected." However, this element
only permits <p> and <ab> as children, thus not allowing specific
elements for encoding "any other relevant information."
Consider a project that is interested in crediting its team; a
<respStmt> is not available to encode such information, though it is
crucial to the description of the project. Note that neither <p> nor
<ab> allow for a <respStmt>. Below is an example of what a full
<projectDesc> would look like (information is pertinent to the Map of
Early Modern London project).

<encodingDesc>
        <projectDesc>
                <title>Map of Early Modern London</title>
                <respStmt>
                        <resp>Project Director</resp>
                        <name>Janelle Jenstad</name>
                </respStmt>
                <respStmt>
                        <resp>Lead Programmer</resp>
                        <name>Martin Holmes</name>
                </respStmt>
                <sponsor>University of Victoria</sponsor>
        </projectDesc>
</encodingDesc>

The information that is included in the <projectDesc> would be common
to the entire project, and would be distinct from information in the
<titleStmt>, which covers the host document specifically. Having the
appropriate <respStmt> and similar elements will allow for a richer
and more processable project description.

The most straightforward way of achieving this would be to use a similar
content model to that of <titleStmt>:

<content>
      <alternate>
          <classRef key="model.pLike" minOccurs="1"
              maxOccurs="unbounded"/>
          <sequence>
              <elementRef key="title" minOccurs="1"
                  maxOccurs="unbounded"/>
              <classRef key="model.respLike"
                  minOccurs="0" maxOccurs="unbounded"/>
          </sequence>
      </alternate>
</content>

[sydb]

I love this overall suggestion, but not the actual suggested content model:

 ( model.pLike+ | ( title+, model.respLike* ) )

For starters, we should not cripple <projectDesc> the way <titleStmt> is by requiring an alternation of either structured information (<title>, <respStmt>, etc.) or prose (<p> or <ab>). Rather, one should be allowed to put the project name, director, and lead programmer into structured slots, and still have a couple of paragraphs of description.
But also it seems to me the description of a project might certainly need an <address> and an <email>.
Perhaps the content model should be more like that of <org> than <titleStmt>.
And that makes some sense, because lastly, I don’t think of Projects having titles like books or record albums, but rather having names as organizations do.

[martindholmes]

@sydb I mostly agree, although I'm not sure whether what we call a project is a title or a name. If we can get the best of all worlds (all the required resp stuff, a usable field for title/name, address, email, and prose description too) then that would be a win. We also have to keep backwards compatibility. Do we need model.projectDescPart?

[ebeshero]

A model.projectDescPart seems like a great idea from here, with the pieces @sydb proposes: I was just thinking that the way I'm handling project description in my own headers is suboptimal. Not all projects have a separate "lead programmer" from the "director," or even use these terms, so I think we'll want some freedom in the designation of roles--something like a <listRole>?

[ebeshero]

I'm assigning this to me and @emylonas to think of some approaches to a new model.projectDescPart

[martindholmes]

@ebeshero If we have <respStmt>, surely there's no need to invent a new mechanism like <listRole>?

[ebeshero]

@martindholmes Good point--It was prompted, though, by @sydb suggesting specific elements for "lead programmer" and "project director" etc. respStmt works in a general sort of way, but what if we want to encode a list of people with various kinds of responsibility and some contact information for the project? There may be a simpler way of formalizing this without inventing new elements--hope we can figure it out.

[ebeshero]

Actually now that I look at @sydb 's comments more carefully, I think he's probably worked out a good way of doing this already. I was distracted by the phrase "structured slots" in the comment above.

[martindholmes]

If you use <resp> with a controlled vocabulary (we use Library of Congress codes), then you have very fine-grained options for <respStmt>.

[lb42]

RespStmt is explicitly for "intellectual responsibility" though? Wouldnt be appropriate e.g. for a funding agency, or a standards body, or a sponsor, all of whom might plausibly be included ina project description. I hope that if you do wind up with some kind of structured projectDesc it will (a) not be too culture specific (b) not preclude doing things ones own way.

[martindholmes]

@lb42 I think that's why we want a variety of elements, such as <sponsor>, <funder>, etc. in addition to <respStmt>. My objection to @ebeshero was that I don't think we need to invent new elements for this. Everything you need for <titleStmt> you might conceivably need for <projectDesc>, and vice versa.

[lb42]

@martindholmes yes: precisely. Define a model.projectDescPart class, and think carefully about what existing elements should go into it.

[raffazizzi]

F2F subgroup wonders if <titleStmt> should be a more appropriate location for these data:

(title statement) groups information about the title of a work and those responsible for its content.

[martindholmes]

@raffazizzi F2F subgroup surely misunderstands: this is for information about the project, not about the specific file which hosts it. There will be people who have responsibilities in the project but none at all for the content of a specific file. When a given file is lifted from its project context, it needs to carry project information with it, while keeping that distinct from the info about the host document itself. If all this information belongs in <titleStmt>, what on earth is the point of <projectDesc> at all?

[ebeshero]

@martindholmes Our subgroup looked up <projectDesc> and found it was supposed to describe the methods of a project, its purpose and aims. See https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-projectDesc.html. We were surprised by this rather clear distinction since the tagname does sound like it might contain a full general description of a project—but clearly according to the Guidelines its scope is more narrow—as befitting an element in <encodingDesc>.) We also discussed this in full Council and we were in agreement about this. Thanks for this nudge—we do intend to respond more thoroughly and supportively here with the examples and suggestions of how to encode information about an entire project up in the <fileDesc>.

[martindholmes]

In that case, I think the definition of <projectDesc> needs to be updated, because it doesn't match its name. <titleStmt> is definitely the wrong place for this info:

<titleStmt> (title statement) groups information about the title of a work and those responsible for its content.

We need a place for info which isn't related to the work at all, except that the work forms part of the larger project.

[ebeshero]

We were discussing a range of options that other projects have deployed in the larger <fileDesc>, and in a separate TEI document distinct to describing a large project and its multiple components and participants.

[martindholmes]

While it makes sense to centralize project information, when you're explicitly creating versions of your individual documents which are designed and intended to be taken out of the context of your project, that information has to travel with the document. And there is an element called <projectDesc>, whose name suggests that's exactly what it's for; if it's not for that, why does it exist?

[ebeshero]

Well, reading the element spec page and https://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD5 gives a pretty clear idea that <projectDesc> describes purpose and method, and that it has a special function inside <encodingDesc>—these are exposing document level encoding decisions. There will be a better place for the kind of info you want to include, and that may be the <fileDesc>.

[martindholmes]

@ebeshero You're right of course. I've been misunderstanding <projectDesc> all these years. I think it might be something to do with the fact that it's called <projectDesc>. I would suggest that we need a place to describe the project that gave birth to a file, but that would inevitably have to be called <projectDesc>, and we can't have that.

[ebeshero]

@martindholmes We were pretty surprised by the Guidelines ourselves last week on this (after all the positive replies earlier to your post--sigh). We do want to revisit this--I think the info we want probably belongs inside <fileDesc>, but I wonder if we can introduce something like a <projectStmt>?

[ebeshero]

Council F2F decides we're not proceeding with modifying <projectDesc>, but we'll work on refining the <titleStmt> to make it more expressive. See #1992.