Repository navigation
Consider extending the cardinality of role to "zero or more"? #1129
Description
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?)
Activity
mattgarrish commentedon Sep 6, 2018
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 commentedon Sep 7, 2018
Would people be OK with not changing any cardinalities here and in #1126?
GarthConboy commentedon Sep 7, 2018
Not completely unreasonable request, but I'm okay punting for now.
dauwhe commentedon Sep 13, 2018
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 commentedon Mar 22, 2021
I just bumped into this today with the release of epubcheck 4.2.5, which throws an error when there is more than one
roleattached 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:
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:
We've been doing this for years without problems so I think this restriction was introduced recently? I would suggest that
roleshould be changed back tozero or morein 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 commentedon Mar 22, 2021
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 commentedon Mar 22, 2021
For reference, this spec requirement was added in EPUBCheck after it was reported in w3c/epubcheck#1121
iherman commentedon Mar 26, 2021
The issue was discussed in a meeting on 2021-03-26
List of resolutions:
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
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?
Wendy Reid: so we'll leave to mgarrish to draft amending language