Consider extending the cardinality of role to "zero or more"?

[rdeltour]

The same person can play different roles in the making of a book; for instance with Media Overlays, the author can well be the narrator too.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:creator id="creator01">Herman Melville</dc:creator>
    <meta refines="#creator01" property="role" scheme="marc:relators">aut</meta>
    <meta refines="#creator01" property="role" scheme="marc:relators">nrt</meta>
    …
</metadata>

(I know, I know… but what if we find an old cylinder of Melville reading Moby Dick at the New York Society Library?)

[mattgarrish]

It feels kind of late in the game to be loosening this up, as I would expect any reading system that actually does anything with the roles already only expects one per instance.

It also seems like a potential burden to throw at authoring tools.

[dauwhe]

Would people be OK with not changing any cardinalities here and in #1126?

[GarthConboy]

Not completely unreasonable request, but I'm okay punting for now.

[dauwhe]

Closed via CG resolution. Although we see some utility here, we are concerned about the effect on authoring and reading systems, and don't feel there's enough demand to make a change at this time.

[acabal]

I just bumped into this today with the release of epubcheck 4.2.5, which throws an error when there is more than one role attached to a <dc:creator> or <dc:contributor>.

This is a problem for us at Standard Ebooks because we include rich metadata, and it is very common for contributors to do more than one thing. For example, this is the standard boilerplate for marking up the SE producer of an ebook:

<dc:contributor id="producer-1">Alex Cabal</dc:contributor>
<meta property="role" refines="#producer-1" scheme="marc:relators">bkp</meta>
<meta property="role" refines="#producer-1" scheme="marc:relators">blw</meta>
<meta property="role" refines="#producer-1" scheme="marc:relators">cov</meta>
<meta property="role" refines="#producer-1" scheme="marc:relators">mrk</meta>
<meta property="role" refines="#producer-1" scheme="marc:relators">pfr</meta>
<meta property="role" refines="#producer-1" scheme="marc:relators">tyg</meta>

This shows that I am the Book Producer (bkp), Blurb Writer (blw), Cover Designer (cov), Markup Editor (mrk), Proofreader (pfr), and Typographer (tyg), which is correct because I did do all of those things for this ebook.

Consider the other basic and common case where an author is also the illustrator of the book, or an author who also wrote up the introduction:

<dc:creator id="author">Bob Smith</dc:creator>
<meta property="role" refines="#author" scheme="marc:relators">aut</meta>
<meta property="role" refines="#author" scheme="marc:relators">ill</meta>
<meta property="role" refines="#author" scheme="marc:relators">aui</meta>

We've been doing this for years without problems so I think this restriction was introduced recently? I would suggest that role should be changed back to zero or more in the interest of being able to include rich metadata like the above.

(The unfortunate side effect here is that we can't use epubcheck 4.2.5 because our entire corpus would explode with errors. Each of our ~500 ebooks is marked up as above.)

[acabal]

Looking at the 3.3 draft spec it looks like this has not been addressed there, so I hope to reopen the conversation in the hopes of getting this in 3.3 or whichever is the next version of epub.

[rdeltour]

For reference, this spec requirement was added in EPUBCheck after it was reported in w3c/epubcheck#1121

[iherman]

The issue was discussed in a meeting on 2021-03-26

List of resolutions:

• Resolution No. 3: Relax the restriction on cardinality for OPF metadata

View the transcript

3. Extending "role" cardinality in contributor metadata

See github issue #1129, #1583.

Dave Cramer: this came up early in epub 3.2 in CG
… can you have more than one metaproperty role pointing to meta element
… schema said 0 or 1
… CG felt it would be tricky for RS to do anything else, and there wasn't a lot of demand for change at the time
… but recently people have been using role property to reflect fact that each contributor can do multiple things for publication

Matt Garrish: part of the restriction is because we had the OPF role attribute role in epub
… and we were trying to match things up
… i'm not sure its critical anyway
… not harmful to have multiple roles
… happy to let people do what they want with metadata
… for epub2 compat, maybe an informative note that you may want to limit yourself to 1 role

Dave Cramer: more RS i'm aware of won't display this to end user at all

Bill Kasdorf: allowing this might be good just for removing friction for publishers
… really common
… so maybe let's allow it if it does no harm

Hadrien Gardeur: from Readium perspective, we could support it
… we could parse it, make it easy to work with, and then its up to the RS to do with that what they want
… and then about OPF, for some RSes its the only metadata they have

Dan Fauxsmith: given that we are currently saying 0 to 1, but publishers are saying they have lots of ebooks where this is already >1, should we recommend that if there is more than 1 then it should be in priority order?
… as an author, you don't know about RS behaviour. You just want to know what is the best value to populate

Ivan Herman: +1 to dlazin

Gregorio Pellegrino: my Q is about ONIX
… in ONIX do you have to duplicate the contributor, or can the contributor have multiple roles?

Bill Kasdorf: this is really common in higher ed publishing
… highly likely that they'd need to be able to do this

Hadrien Gardeur: disagree that we should try to align with ONIX
… its not produced by the same people
… one person does OPF, and often someone else does ONIX
… repeating roles rather than repeating author is more elegant

Dave Cramer: ONIX cardinality for contributor is that each can have multiple roles
… i'm seeing strong support to relax this restriction, to allow cardinality of multiple

Ivan Herman: agree, but i think we should also make it clear that they should be in priority order

Charles LaPierre: i just created book for diagram center that had multiple contributors, and there i had to add in all these roles for each contributor. Would have loved to have been able to do this in the epub as well.

Brady Duga: for priority, i could seen some RS taking the first one, and some taking the last one

Matt Garrish: can we also agree to 1583?

Proposed resolution: Relax the restriction on cardinality for OPF metadata (Wendy Reid)

Ivan Herman: +1

Charles LaPierre: +1

Matthew Chan: +1

Brady Duga: +1

Bill Kasdorf: +1

Gregorio Pellegrino: +1

Ken Jones: +1

Wendy Reid: +1

Juliette McShane: +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Resolution #3: Relax the restriction on cardinality for OPF metadata

Wendy Reid: so we'll leave to mgarrish to draft amending language