publisher of a work

[rettinghaus]

<work> allows the following elements as direct children:

• arranger
• author
• composer
• contributor
• editor
• funder
• librettist
• lyricist
• sponsor

Why then is <publisher> not allowed? IMHO this is an inconsistency. While some elements totally make sense as children of work, others don't, e.g. why is <editor> allowed whilst <publisher> isn't?

I want to compile a simple straight-forward list of works containing just title, composer and publisher. The only way I see now is to put the publisher in work/biblList/bibl/publisher. Way to go?

[pe-ro]

@rettinghaus, in the FRBR universe a work is an abstract concept. Therefore, publisher isn't necessary here because manifestations are published, not works.

We might consider removing <editor> from the list of allowed roles in this context, depending on whether the editorial role is considered a creative one.

Compiling a list of works inside <work> is highly questionable, so <biblList> should definitely not be used for this purpose. The proper role of <biblList> is documentary -- of a particular work in this case. Your so-called "simple straight-forward" list can be constructed from data recorded in the <work> and <manifestation> areas -- there's no real reason to compile it and store it separately in the MEI file.

Another approach would be to use the bibliographic descriptions of the data sources of the file; that is, fileDesc/sourceDesc/bibl or biblStruct (relying on recent changes proposed by the metadata and cataloging interest group). Traditional bibliographic descriptions mix data from the various FRBR entities. One possible down side of this approach, however, is the repetition of common data like author/composer and title info.

[rettinghaus]

Thanks @pe-ro. I was aware of the "abstract concept" of a work and completely agree. But coudn't one argue that the first edition of a work is somewhat documentary? Well, I'll rethink my structure.

Anyway the other point still remains: An edition is always a form of interpretation of a work. So even if you take an <editor> as a creative contributor this would then apply to a manifestation. On the other hand, a dedication could be seen as a "abstract concept" in itself. So even if there are several manuscripts of a work with different dedications in existence, the work by itself could be connected to a <dedicatee>, too. So my proposal is to remove <editor> from work, and instead introduce <dedicatee>.

[ahankinson]

A dedicatee is not a creator, it is the person to which the object is dedicated. I may dedicate a work to Queen Elizabeth II, and she may never know, nor ever even care.

[pe-ro]

As @ahankinson points out, a dedicatee is a passive participant in the creation of a work, so I see no reason to add <dedicatee> to <work>.

On the other hand, while its use should be rare, I think there's reason to keep <editor> because this person can be an active participant in a work's creation. I'm not thinking of the traditional editorial role in the creation of a manifestation, but rather an "editor" who is an active contributor, in the case of Barry Cooper's completion of Beethoven's 10th, for example. Whether this role is labelled "editor", "arranger", or simply "contributor" is left to the encoder.

That being said, I see the utility of allowing in <work> only those roles with "primary responsibility" -- author, composer, contributor, librettist, and lyricist -- pushing other roles -- arranger, editor, funder, and sponsor -- to <manifestation>. We could even reduce the elements allowed in <work> to describe responsibility to two -- <creator> and <contributor>. Such sweeping changes may raise objections from others, however, so I'd be interested in additional input.

[bwbohl]

Gathering from our past discussions about this I thought we kept those elements for library catalog "compatibility". @pe-ro 's proposal:

We could even reduce the elements allowed in to describe responsibility to two -- and .

Brings me back to my general thoughts about responsibilities, being:

• get rid of all "specialised" elements (those mentioned by @rettinghaus )
• generally stick to the concept of <respStmt>

[bwbohl]

of course always referring some standard controlled vocabulary to indicate the kind of responsibility

[axgeertinger]

This discussion started long ago, but it came up once more at the MEC in Vienna (see the group's report on the mail list). The current change from <respStmt> as the place for those "responsible for creation or realization of the intellectual or artistic content" (MEI 3) to <contributor> for "individuals, institutions, or organizations responsible for contributions to the intellectual content of a work" not encodable with the specially named elements (MEI 4) has not widened the field of possible agents related to a work (or expression). Why must the list of agents at work and expression level be limited to only those that actively contribute or are responsible? Why not allow MEI to describe any relation between a work/expression and an agent? The dedicatee is probably the most relevant one in this discussion. Claiming that the work itself cannot be dedicated to a person is disputable, I'd say, but first of all I am not comfortable with MEI making that decision for the encoder. What about "Für Elise", for instance? And what if the composer actually did dedicate a work to someone but never wrote down an actual dedication on any manifestation or item? Does that make the dedication non-existent? My second point: I agree with @bwbohl that a generic concept for the encoding of relations between FRBR entities and agents is generally better than using specifically named elements like <composer>, not least for the sake of simpler processing. But I'd like to take it one step further and generalize the concept of responsibility (as in <respStmt>) to simply <relator> or <relators> which makes sense especially when using standardized vocabularies such as MARC relators. As it is, I would actually need to restrict the list of available relator roles inside <respStmt> or <contributor> to only contain those that describe some sort of responsibility or intellectual contribution, respectively. I don't, and it wouldn't seem right to me to do it. I regard it as the encoder's responsibility to make sure that the encoded information makes sense in any given context. So, what are my suggestions? Apart from accepting the current limitations I see the following options:

1. Change the name of <contributor> to <relator> to generalize its scope (obviously breaks compatibility).
2. Introduce <relator> as an additional element to support the very generic encoding of relations between entities and agents. This doesn't break compatibility but introduces more fuzziness to the schema and may lead to some confusion about when or why to use <relator> or <contributor>.
3. Change the description of the <contributor> element to be a little less restrictive (but it will still have certain limitations, given the name). This doesn't solve the dedicatee issue.
4. Shamelessly abuse <contributor> - at the encoder's discretion - to describe any related agent, whether contributing to the intellectual content or not (current MerMEId approach).

[axgeertinger]

BTW, I agree with @pe-ro that a publisher can never be a relator at work level, at least not literally in the role of the actual publisher of a work. That's happening at manifestation level. Not so sure about the editor; isn't the modern critical editor, for instance, creating a new expression through the process of editing? But again: I am not sure we are the ones to dictate such limitations.

[kepper]

I also never liked the "shortcuts", and personally wouldn't stand against their scheduled removal from MEI. From my perspective, the ideal workflow for that would be like so:

1. Ask people on MEI-L to fill a form on their current use of these elements – if a majority of MEI users uses them, and prefers to do so in the future, it's a harder sell to remove them, I think.
2. Mark them as deprecated in the next major version of MEI (v5), but still include them.
3. Remove them from MEI v6.

Of course, the outcomes of 1. may influence the speed of the following process. From @axgeertinger's proposals, only 1) seems to be sensitive:

1. Change the name of <contributor> to <relator> to generalize its scope (obviously breaks compatibility).

No. 2. makes it harder to decide which element to use in which situation, 3. doesn't solve the problem, and 4. is close to recommended tag abuse. However, I wonder if we don't have that concept requested by 1. already baked into MEI: <relation> (the following taken from https://music-encoding.org/guidelines/v4/elements/relation.html):

Desc: Describes a relationship or linkage amongst entities.

Remarks: The plist and target attributes identify the participants in a relationship, while the rel attribute describes the nature of their relationship. A mutual relationship can be described using only the plist attribute – the target attribute is not necessary. In a non-mutual relationship, plist identifies the entities pointed "from", while target specifies the entities pointed "to". If the target attribute is present, but the plist is not, the relationship is presumed to exist between the parent of the current relation element and the entities identified by target.

The only problem I see is that it's not allowed within <respStmt> so far, and that we need to clarify the difference between the current use of <relation> and it's intended use as <relator>-replacement. However, this would allow us to consistently use one single element for relations between entities of all FRBR-groups. If we decide to do changes on this part of MEI, I would probably prefer to go that way…

[axgeertinger]

@kepper, interesting thought. I am a little worried, though, that <relation> may actually be too generic, heading us in a direction where everything may be described as a relationship between two things/entities/persons/whatever. Also, <relation> must not have any content, so what would the encoding of the composer's name, for instance, look like? Something like this?

<persName>
    Mozart
    <relation rel="composer"/>
</persName>

Not pretty with mixed content, and also somewhat vague perhaps. With <relator> as a wrapper, we could avoid the mixed content:

<relator>
    <persName>Mozart</persName>
    <relation rel="composer"/>
</relator>

but then we might just as well use

<relator rel="composer">
    <persName>Mozart</persName>
</relator>

which seems simpler and clearer to me.

[kepper]

Admittedly, I haven't thought a whole lot about it yet ;-) I was thinking of it as independent pieces of information, so something like

<persName xml:id="WMA">Wolfgang Amadeus Mozart</persName>

and elsewhere

<work xml:id="KV525" label="Eine kleine Nachtmusik"/>

and again elsewhere

<relation rel="cmp" plist="#WMA" target="#KV525"/>

I agree that this isn't really well-thought so far, and has the potential to feel rather clumsy. However, there is the encoding style to wrap every statement about responsibility into a separate <respStmt>, and within them always provide one <name> and one <resp>. Wouldn't it be possible to always mix them like so:

<respStmt>
    <persName xml:id="WMA">Wolfgang Amadeus Mozart</persName>
    <relation rel="cmp" plist="#WMA" target="#KV525"/>
</repsStmt>

Yes, we could add a statement that in such situations @plist defaults to the sibling name (as we do for group 1 entities in FRBR already), but I'm not sure if that's really necessary? If we'd want to do that, we could also default the @target to the relevant ancestor of this <respStmt>, so that we'd end up with a simple <relation rel="cmp"/>… Not sure if that's a way to go?!?

[kepper]

Obviously, this also suffers from the need for a rather loose interpretation of responsibility in "responsibility statement"…

[axgeertinger]

I don't know. I like the straightforwardness of

<relator rel="cmp">
    <persName>Mozart</persName>
</relator>

which works without any idrefs (assuming that the target of the relation defaults to the relevant parent like with <composer> etc.), but let's have some more opinions on it.

[bwbohl]

I don't know. I like the straightforwardness of

<relator rel="cmp">
    <persName>Mozart</persName>
</relator>

which works without any idrefs (assuming that the target of the relation defaults to the relevant parent like with <composer> etc.), but let's have some more opinions on it.

Yes, indeed this seems quite straight-forward. One could even use @class for pointing to the individual term page of https://id.loc.gov/vocabulary/relators.html. On the other hand, why not allow relation at this level, or just use the already allowed relationList?

[KristinaRichts]

Building on the considerations above, this issue was further discussed at the metadata workshop in November 2020. The Metadata IG would like to put the following proposal to a vote:

Agent (vs. Contributor)

Contributor: https://music-encoding.org/guidelines/v4/elements/contributor.html

Contributor in MARC Relator List: https://id.loc.gov/vocabulary/relators/ctb.html

Last proposal by Axel TG:

<relator rel="cmp">
      <persName>Wolfgang Amadeus Mozart</persName>
  </relator>

New proposal: possible:

<agent role="Komponist">
    <persName xml:id="WMA" >Wolfgang Amadeus Mozart</persName>
</agent>

but:

<agent role="jumpthegunguy">
    <persName xml:id="WMA" >Wolfgang Amadeus Mozart</persName>
</agent>

recommended (use most specific role, if possible):

<agent role="Komponist" auth="MARC_List_of_Relator_Terms" 
        auth.uri="http://id.loc.gov/vocabulary/relators/" codedval="cmp">
    <persName xml:id="WMA" auth="GND" auth.uri="http://d-nb.info/gnd/" 
        codedval="118629662">Wolfgang Amadeus Mozart</persName>
</agent>

For the Guidelines/MEI-all: Take out <contributor> and dedicated tags like <composer> etc. and replace them with <agent>. Allow <agent> on every level of the WEMI hierarchy. Leave the option to define such specific “syntactic sugar” for customizations. The role attribute is not considered to be based on a controlled vocabulary but rather provide a human readable role description. If a controlled vocabulary is necessary for this specific attribute, a closed list of values should be defined in a customization or the specification should be documented in the <encodingDesc>. Recommendation for better machine-processability in role attribute: use of auth.uri/codedval mechanism to link to Marc Relator List (or Marc code list) for controlled roles (use most specific role possible).

Examples:

Composer:

<agent role="Komponist" auth="MARC_List_of_Relator_Terms" 
        auth.uri="http://id.loc.gov/vocabulary/relators/" codedval="cmp">
    <persName xml:id="WMA" auth="GND" auth.uri="http://d-nb.info/gnd/" 
        codedval="118629662">Wolfgang Amadeus Mozart</persName>
</agent>

Lyricist:

<agent role="Textdichter" auth="MARC_List_of_Relator_Terms" 
        auth.uri="http://id.loc.gov/vocabulary/relators/" codedval="lyr">
    <persName xml:id="WMA" auth="GND" auth.uri="http://d-nb.info/gnd/" 
        codedval="118629662">Wolfgang Amadeus Mozart</persName>
</agent>

Dedicatee:

<agent role="Widmungsträger" auth="MARC_List_of_Relator_Terms" 
        auth.uri="http://id.loc.gov/vocabulary/relators/" codedval="dte">
    <persName xml:id="WMA" auth="GND" auth.uri="http://d-nb.info/gnd/" 
        codedval="118629662">Wolfgang Amadeus Mozart</persName>
</agent>

Contributor (unspecified role):

<agent role="Contributor" auth="MARC_List_of_Relator_Terms" 
        auth.uri="http://id.loc.gov/vocabulary/relators/" codedval="ctb">
    <persName xml:id="WMA" auth="GND" auth.uri="http://d-nb.info/gnd/" 
        codedval="118629662">Wolfgang Amadeus Mozart</persName>
</agent>

Same as: possible:

<agent role="Komponist">
    <persName xml:id="WMA" >Wolfgang Amadeus Mozart</persName>
</agent>
<agent role="Textdichter">
    <persName sameas="#WMA"/>
</agent>

---

recommended:

<agent role="Komponist" auth="MARC_List_of_Relator_Terms" 
        auth.uri="http://id.loc.gov/vocabulary/relators/" codedval="cmp">
    <persName xml:id="WMA" >Wolfgang Amadeus Mozart</persName>
</agent>

<agent role="Textdichter" auth="MARC_List_of_Relator_Terms" 
        auth.uri="http://id.loc.gov/vocabulary/relators/" codedval="lyr">
    <persName sameas="#WMA"/>
</agent>

Multiple agents with same role:

<agent role="Komponist" data="#mdiv-01">
<persName xml:id="JSB" >Johann Sebastian Bach</persName>
</agent>
<agent role="Komponist" data="#layerDesc3B">
<persName xml:id="CPE" >Carl Phillip Emanuel Bach</persName>
</agent>

Example: Groupe des Six

L’Album des Six „Prélude“ (22. Dezember 1919) – Auric „Romance sans paroles“, op. 21 (August 1919) – Durey „Sarabande“, H 26 (Januar 1920) – Honegger „Mazurka“ (1914) – Milhaud „Valse en ut“, FP 17 (Juli 1919) – Poulenc „Pastorale“ (4. September 1919) – Tailleferre

<workList type="collection">
      <head>
        <title>L’album des Six</title>
      </head>
      <work data="#mdiv-Prelude" >
          <title>Prelude</title>
          <agent role="Komponist">
              <persName xml:id="auric" >Auric</persName>
          </agent>
     </work>
     <work data="#mdiv-Romance" >
          <title>Romance</title> 
          <agent role="Komponist">
                <persName xml:id="durey" >Durey</persName>
          </agent>
    </work>
    <work data="#mdiv-Sarabande"> Sarabande </work>
    <work data="#mdiv-…"> … </work>
    ...
</workList>

Collective agents (?)

<agent role="funder">
    <corpName >DFG</corpName>
</agent>

<agent role="composer">
    <name >Groupe des Six</name>
</agent>

Unknown agents (?)

<agent role="Federtintenlieferant">
    <name class="unknown"/>
</agent>

or

<agent role="Komponist">
    <name class="siglum">Anonymous</name>
</agent>

currently available:

<composer>unknown</composer>

<contributor role="composer">
          unknown
</contributor>

<contributor>
          <name class="siglum">Anonymous</name>
</contributor>

 <contributor>
          <name type="unknown" />
</contributor>

[ahankinson]

A few thoughts (Thanks @KristinaRichts !)

1. It would be great if auth.uri were a complete value, and was not split across that and @codedval. I know this is already possible, but it would be great if we could establish that as a 'best practice'.
2. The RDA Registry can also be used, as well as the MARC relator codes: e.g., http://rdaregistry.info/Elements/u/P60426 (would need to choose between the constrained and unconstrained properties!)
3. Getting rid of the specialized elements is fine with me.

[kepper]

At today's ODD Friday, we were much in favor of @KristinaRichts' last proposal, in conjunction with @ahankinson's additions. It seems important to have solid documentation on this, so we hope to see a PR that will include the Guidelines and best practices as well, to be discussed (and merged?) in April.

[kepper]

I'm afraid I haven't had the time to work on this one and prepare something together with the Metadata IG. I propose to push it one more month, assuming that no one else has done some work on this.

[musicEnfanthen]

Same here, @doerners and I wanted to support this PR, but didn't find the time either. Yes, let's prepare it for the May meeting.

[doerners]

Yes, thank you @musicEnfanthen, I indeed didn't find the time to work on this yet as well. So I fully support pushing this one more month.

[kepper]

Many thanks to @doerners and @musicEnfanthen for the great work on this. Now it seems time to get back to the Metadata IG and revise how your proposal aligns with their understanding. @KristinaRichts, will you take care of forwarding? We can then have another look at the next ODD meeting.

[musicEnfanthen]

Please see also the comments in the related PR: https://github.com/music-encoding/music-encoding/pull/799#discussion_r640353011

[pe-ro]

The proposal to remove <composer>, <editor>, etc. conflicts with traditional cataloging practice; e.g., AACR2, which breaks responsibility for a bibliographic entity into a single primary access point (composer, author, editor, etc.) and added access points for secondary responsibility (lyricist, illustrator, etc.) I understand the desire to break away from this particular tradition, but I have objections:

1. conversion to/from systems which employ the traditional methodology (MARC, TEI header) may be hindered; and
2. replacing the current role-based elements with <agent>, which has essentially the same content model as <respStmt>, is redundant & confusing.

[doerners]

Thank you for your insight @pe-ro!

In regard to the discussion within this issue and also to the discussion in #799 there are still some points that are not quite clear to me:

In my understanding the specalised elements like <composer> etc. are just shortcuts for something like <persName role="composer"> or alike. Thus I don't see why there shouldn't be the possibility to come up with a crosswalk for schemes like TEI with the <agent> element, especially if the community can come to an understanding of making use of controlled vocabularies for the @role attribute.

Furthermore I find it somehow troubling to model role based elements with <respStmt>. Even if we rework the definition to what @bwbohl suggested in #799 comment I feel it still denotes that the encoded individual or group of individuals has some responsibility. What if a user wants to encode a dedicatee. Does a dedicatee really have responsibility in regard to e.g. a work? <agent> in my opinion wouldn't imply this and thus might be better suited as a neutral wrapper for all sorts roles (be it roles of responsibility or not).

I would also argue that terminology-wise having an <agent>element is in alignment with IFLA LRM (which superseded FRBR, FRAD and FRSAD) and RDA (the successor of AACR2 and for the German-speaking countries RAK) which both are being widely applied and aim at standardisation in an international context. This might be desirable for the MEI community if we want – as is my understanding – to be able to have an interoperable format to library formats and data or at least understand each other in respect to the underlying concepts we refer to.

[pe-ro]

Thank you, @doerners , for your response.

Like I said, I understand that there is a desire to move away from all things traditional and that there are multiple approaches to this -- LRM, RDA, etc. And I don't object to that impetus. I just want to make sure that the intended path is clear. To that end, a possible path forward is --

1. remove <respStmt>;
2. replace <composer>, etc. with <agent>, where <agent> has essentially the same content model as <respStmt>; that is,

   <rng:zeroOrMore>
   <rng:choice>
   <rng:ref name="name" />
   <rng:ref name="role" />
   <rng:ref name="model.nameLike.agent" />
   </rng:choice>
   </rng:zeroOrMore>

   This can be done everywhere <respStmt> is currently allowed.

However, this is going to have ripple effects with regard to bibliographic description in places other than the header; for example, within <pubStmt>. When a publisher can be an agent, then the need for a structured publication statement is diminished, and when <pubStmt> is tampered with, then traditional bibliographic citations become difficult to model.

If, on the other hand, <respStmt> is removed and replaced only within the header (itself a bibliographic citation), then conflict is introduced between how agency is modeled in the header versus other bibliographic contexts.

[ahankinson]

An agent is not a person -- it is a person's role in relation to some action (their "agency"). In other words, an agent does not exist unless and until a person takes an action: composes a musical works, writes lyrics, publishes a book, etc. If I was born, lived, and died without doing a single significant thing, I would still have been a person, but I may never have been an agent. (More likely, I would have been an agent in other places, but I may have never been a composer or a lyricist or a publisher).

Given this, the mapping of agent to an existing pattern is not <persName role="composer" ...> as suggested by @doerners. Instead, <agent> seems to be replacing <resp ...> within a <respStmt> (but this isn't entirely clear). Currently we use resp within a respStmt to model a person's relationship to a thing, so it seems that <agent> is mixing these domains -- personhood and agency.

Wrapping <persName> as a child of <agent> is also problematic, since it means that we cannot easily define one person having multiple agencies -- we wither have to repeat <persName> or have a separately defined <persName> somewhere else with an ID pointer.

To be clear I'm not arguing for keeping <composer> -- I think it's not really great to have specific elements for roles -- but I do think there needs to be some more work on modelling how this works with respStmt, in line with what @pe-ro is suggesting. For example, what is the difference between agent and resp within a respStmt? If we adopt agent should we deprecate resp?

I've tried looking back at the comments here and in #799 to see if there is a mock-up of how agent might look in context, and particularly how it works within <respStmt>, or whether it is trying to replace <respStmt>. Are there any longer-length examples that can be linked here?

[pe-ro]

@ahankinson, I don't have any specific examples. I would suggest creating a few based on traditional chief sources of information and via transcoding from other already-encoded metadata, existing MEI, TEI, MARC or MODS files, for example.

You may have missed the fact that in the content model I proposed for <agent>, <resp> is replaced by <role>. In this model, <role> may be repeated as many times as necessary to capture all the roles/responsibilities/whatever that a single agent may have. It's also important to note that multiple nameLike elements are allowed to capture multiple (i.e., variant names) that an agent may possess. Typically, however, multiple and/or variant names would be specified in the authority record pointed to by @auth.uri.

I believe that once the decision is made to replace <composer>, etc. with <agent>, <respStmt> must also be removed to avoid confusion. But, as I said in my previous comment, this may have serious consequences in places other than just the header.

Anticipating what I think your next question might be, <agent> must be a member of att.authorized, but the nameLike elements must continue to be members of att.authorized as well. This will allow the use of <agent @auth.uri> without <persName>, etc. or <persName auth.uri> without the use of @auth.uri on <agent>. The either-or-ness of where to put @auth.uri (if it's used at all) can be enforced with Schematron.

Also, the @role attribute must be retained on <persName> for capturing a name where bibliographic agency isn't necessary, for example --

<annot>
  <p><persName role="gadfly">Perry Roland</persName> is a pain in the ass.</p>
</annot>

Again, the use of @role versus <role> in the bibliographic context can be clarified with Schematron.

[pe-ro]

The simplest answer to @rettinghaus's original question -- one I failed to give long ago -- is that publisher is captured elsewhere; i.e., in <pubStmt>. Adding <agent> in order to capture the name of the publisher will result in obliteration of the meaning of <pubStmt> and, in turn, traditional cataloging norms that go back centuries.

[doerners]

Thank you @pe-ro and @ahankinson for your comments!

@pe-ro: Yes I agree that replacing <composer> etc. with <agent> will have ripple effects and that the definition of <agent> should keep that in mind to avoid any unwanted consequences. To that end I want to stress that #799 is the first time for me actually defining an element and really dealing with ODD. The PR is still a draft and I'm certain that it isn't perfect yet but I'm also still learning and hope to get input from more experienced community members as to avoid messing up the schema.

@ahankinson: I would disagree with the statement that agent is not a person. My understanding of agent is similar to what is defined in IFLA LRM which says an agent is:

An entity capable of deliberate actions, of being granted rights, and of being held accountable for its actions

Therefore I like to understand agent is an entity (or you may say an individual or group of individuals) capable of deliberate actions or being acted upon and thus I would understand that agent could be a person acting within the context of a specific role, e.g. an individual acting as a composer in regard to a specific work. Since the context (e.g. the work we refer to) is also significant for the encoding I can't think of any use cases – at least not from the top of my head – where this would create conflict with individuals that are persons but are not doing anything of significance.

I do understand that it might be cumbersome to have to repeat <agent> for the same person to delineate different roles/responsibilities, however is there (right now) a better way if one uses the specialised elements? So if the composer is also the lyricist, wouldn't you still have to encode it as something like:

<composer>
    <persName>Awesome composer dude<persName>
</composer>
<lyricist>
    <persName>Awesome lyricist dude who is the same as awesome composer dude</persName>
</lyricist>

@pe-ro again: Concerning the examples, @KristinaRichts posted some proposed examples that the metadata IG came up with during the workshop in 11/2020 in this comment, however I think that we didn't cover anything for <respStmt> there.

[pe-ro]

Looking back at this issue.

I think it's useful to retain <respStmt> with its current model. It serves a bibliographic purpose; that is, the association of a responsibility/role/task with a name, e.g.,

<respStmt>
  <resp>composer</resp>
  <persName>Bach, Wolfgang</persName>
</respStmt>

or

<respStmt>
  <persName role="composer">Bach, Wolfgang</persName>
</respStmt>        

However, <respStmt> is not the place to record detailed characteristics/traits of the person, corporation, etc. holding responsibility.

Even though they haven't been used this way so far, the respLike elements, like <arranger>, <composer>, <librettist>, etc., placed outside <respStmt>, can be used to contain detailed information about an entity (often but not always a person), such as those allowed by TEI --

affiliation
age
education
faith
floruit
gender
...

Even though it would break backwards compatibility at this point, I'd be ok with replacing the respLike elements, <composer>, <editor>, etc. with an <agent> element, which has a mandatory @role attribute (with a semi-open list) and a content model allows the capture of elements similar to those allowed by the TEI model class model.persStateLike.

[pe-ro]

I want to revise my earlier comments about removing entities without primary responsibility for the intellectual content of a work from the <work> element. At this point, I don't think they can / should be removed. For example, removing <sponsor> and <funder> would make it difficult to describe a patron who, while not primarily responsible for it, at least "enabled" the creation of a work. Likewise, I now think adding <dedicatee> to <work> is ok. In my view, a dedicatee, like a patron, is part of the creative process even if they don't actively create anything. On a practical level, without <dedicatee> directly in <work>, there's no other easy (read, database-like) method of recording this info.