-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parsing EPUB contributors #126
Comments
Refinements of Dublin Core properties have always been a complex matter. Even without refinements, |
That makes sense. I’m now personally leaning towards the option @qnga has proposed in his PR: giving more weight to the So that would mean removing the first column (element) in the mappings tables and having a global rule saying it can be Of course other opinions are warmly welcome but as an early proposal starting from Quentin’s PR… ContributorsThe contributor’s key depend on the role of the creator or contributor. It is an object that contains a The The contributor object may also contain a When parsing an EPUB, we need to establish:
EPUB 2.xThe contributor element can either be The following mapping should be used to determine the key of the contributor’s object:
Where Parse the carrying element as a localized string to compute a language map for the contributor’s name. Finally, the string used to sort the name of the contributor is the value of the EPUB 3.xThe contributor element can either be The following mapping should be used to determine to key of the contributor’s object:
Where In addition, Parse the Finally, the string used to sort the name of the contributor is the value of a refine with a PublisherThe The The publisher object may also contain a Parse the Finally, the string used to sort the name of the publisher is the value of a refine with a Although I’m not completely happy with this rewording – I think publisher is best if left as its own section, as it is in the RWPM doc, but it could probably refer to contributor given the duplicated text. |
What about a preface writer? I think he could legitimately be declared as a contributor with 'opf:role=aut', and we definitely don't want him to appear side by side with the author of the main content.
What about |
It's not clear from the table how these elements are mapped when the
Yes, I wonder how it's used in the wild... Also, wouldn't it be weird to have a |
Indeed, we will probably have to reach a consensus on an opinionated parsing for some metadata, especially as contributor is a minefield for corner cases. For preface writer, for instance, there’s
TBH, I’ve always been interested in a comparison between the metadata of EPUB files and their ONIX record, as lots of producers treat EPUB metadata as something that is displayed in the UI – and you could consequently find conflicts. As the most simple example I’m aware of, instead of:
Some will do:
so that both names are displayed in the page header of say iBooks, despite what the spec is saying: “If an EPUB Publication has more than one creator, each SHOULD be included in a separate creator element.”
That’s a good point.
That’s another one. @hadrien commented the PR a few minutes ago:
I don’t have a better answer right now but looking at the EPUB spec, I think it’s fair to add something to make “ Let me a few minutes to change the earlier proposal :-) |
Updated proposal ContributorsThe contributor’s key depend on the role of the creator or contributor. It is an object that contains a The The contributor object may also contain a When parsing an EPUB, we need to establish:
EPUB 2.xThe following mapping should be used to determine the key of the contributor’s object:
Where Parse the carrying element as a localized string to compute a language map for the contributor’s name. Finally, the string used to sort the name of the contributor is the value of the EPUB 3.xThe following mapping should be used to determine to key of the contributor’s object:
Where Parse the Finally, the string used to sort the name of the contributor is the value of a refine with a So this rolls back to the text of the PR with updated mapping tables. Does that sound reasonable? |
I agree except on same for narrator |
I agree with the content, but a different presentation might be clearer:
What about |
Ah yes thanks, that will make it more consistent. On a related note, would |
yes is a good representation IMO. |
Close readium#126 Co-Authored-By: Jiminy Panoz <JayPanoz@users.noreply.github.com>
Multiple roles have not been mentioned. In Kotlin so far a |
|
Oh, yes, you have already said that, sorry. |
Which also begs the question of making a rule of thumb that “if cardinality is And maybe also adding links to the EPUB OPF docs in the header of the doc (with RWPM link) given we use them quite extensively. |
Yes, we could. But are you sure multiples roles are never used in real life despite the specification? Using multiple |
I’d say one good way to look at some issues when we have doubts is probably EPUBCheck – that also helped open bug issues in the epubcheck repo in the past. So the bad news is that epubcheck is fine with multiple roles.
So:
Anyways, on an interesting note, the editor I used to make this quick test file, Sigil, has another take on this: Its metadata editor enforces this cardinality (only one Reminds me of the “multiple |
So Matt Garish just confirmed me it’s an epubcheck bug here. So at least this point is clarified: one Then what do people want to do about that? |
Personally, I'm ok with considering only the first role. This should lead to simpler code. |
That's similar to this issue I reported yesterday. Even though it's not spec compliant, IMHO it's better to handle cases like these, that are definitely found in the wild.
I checked on Swift, and we're parsing only one |
Seems to me this is the best we can do. So as a recap, the important pieces of information:
Who’s in favour of handling multiple Use 👍 or 👎 emojis to cast your vote. |
The group has chosen to handle only one role per contributor. In case the source format allows a contributor with several roles, the corresponding Readium Web Publication (serialized or not) will have one contributor entry per role. |
Close readium#126 Co-Authored-By: Jiminy Panoz <JayPanoz@users.noreply.github.com>
As a side-effect of readium/r2-streamer-kotlin#125, I’m now wondering whether the contributors’ section of the EPUB parsing doc should not be modified in more depth.
For reference: contributors’ section in RWPM doc.
Per EPUB spec:
And then
So my interpretation is that
creator
vs.contributor
is more vague than the mapping tables we have right now e.g.illustrator
could be acreator
but this is not covered. And as another example, a contributor could have the role ofaut
(author), so should it be promoted toauthor
or be kept as acontributor
to not lose this nuance?Any thoughts?
The text was updated successfully, but these errors were encountered: