Meeting minutes
Organizations
LaurentLM: What orgs are interested in this project
… EDRLab talked to Himmer (sp?) who are interested but will not join
… Colibrio made a presentation on CFI use and presented the fact that Colibrio has released an open source JS library for CFI
… So those are two who are interested, does anyone knows anyone else?
… (sounds like no)
Documentation
LaurentLM: proposal for docs is to use github as a subdir under somewhere [I missed where]
… we still need to decide Note vs rec
… apparently the current admin at W3C isn't happy with Note -> Rec process
… so we need to decide ASAP
ivan: Rec means we need 2 implementations
… and in this case we will probably need to prove interop between RSes
… If I look at that and the few number of orgs interested, then I am not sure we can do rec track
… just trying to be realistic
LaurentLM: We have Colibrio and EDRLab
… which should be good
ivan: No, sorry. There are 2 independent implementations, but the minimum of 2 should require interchange as well
… so we need more than 2, maybe 3 or 4
LaurentLM: Are you sure that using the Readium kit at different companies won't count as multiple impls?
ivan: No, it is like Google and Brave implementing the same thing. They are considered the same impl
… I would like it to be a rec, but I am trying to defend against objections
George: Rick Johnson and VitalSource are interested in interchange
… They are also interested in citations. They are no longer members, but I can check if they are implementing
… they are not in WG
ivan: That is ok
… CR does not require they be W3C members
ach George
duga: So Note to rec is an issue, what about the other direction?
ivan: No, not a problem, it would just stay as a working draft
LaurentLM: I would be in favor of going to rec track
… Note is ok at first, but it is a problem for wider adoption
LaurentLM: Back to documentation
ivan: Should be in the 3.4 line in github
LaurentLM: Yes, with folder name annotations
… Next item is process and use cases
Use cases
LaurentLM: we should start with them, ok?
ivan: Yes, definitely
LaurentLM: I have a Google doc that I started
… we can move to github later
<LaurentLM> link to the temporary google doc: https://
LaurentLM: It would be good to add to this document in the next few days, then we can move the best ones to github
ivan: So 1 paragraph is 1 use case?
LaurentLM: Yes
Simple annotation
<LaurentLM> first use case : A user decides to annotate a textual section of an EPUB. He selects the section, triggers the annotation affordance, optionally enters a note, selects a highlight mode and color. He then saves the annotation. The selected section appears on the page with the chosen highlight.
<LaurentLM> comments?
ivan: We already have annotations, the important thing is the interchange
… do we even need this one? Since it already exists
… looking for other use cases for the web, but I am not finding them
… what we really care about is how are these different from web annotations
LaurentLM: W3C annotations has so much in it. Maybe we should close the door on unnecessary things
ivan: The use case doc structure is ours, we could start with exactly that
… e.g. "web annotations allows, but we don't need" at the start of the use cases
George: A simple use case, I read in Thorium, annotate, then open the same book on the phone in a different app
… That isn't even between people
LaurentLM: That is on the list near the top
Annotating images, videos
<LaurentLM> second one: A user decides to annotate an image of an EPUB. He selects the image and triggers the annotation affordance. The annotation feature is then identical to the one associated with a textual selection.
LaurentLM: There are some obvious ones before it, but the only one I want to call out is images, etc
… we should probably discuss this
George: There are a couple of AI tools to get the description of the image
… I could annotate the image with that, but I may need a sighted user to confirm the annotation
George: Just select it and annotate
LaurentLM: In Thorium, that ability doesn't exist
… This will inform our choice of selectors
George: What about figures?
LaurentLM: If we require images, we will get figures
ivan: Apart from the tech issues, what are the arguments for not annotating images?
… It seems fine in a use case document
duga: Do we need all the possibilities?
LaurentLM: There are definitely technical issues with some of these things
… maybe we can add a use case for images, but not video, etc?
ivan: Just because it is in the use case document, doesn't mean we don't have to support it
… If it is a valid use case, we should add it, then explain why we are not supporting the use case
… technical issues aside, it is a valid use case
LaurentLM: So we can have use cases that are not in the requirements list?
ivan: Yes
LaurentLM: Ok, we can dream in the use cases
Adding tags
<LaurentLM> third one: A user creates an annotation. He can categorise this annotation with a string (let’s call it a tag), so that annotations can easily be grouped together. Examples: “analysis”, “to be discussed”.
LaurentLM: there is another small use case
… categorization
… Being able to add a label
… So the annotator can add some semantics
duga: Is this use case valid for us? Since we are specing interchange
LaurentLM: If we have the possibility to tag, then we will need this in interchange
ivan: The real use case is adding categories to the interchange
LaurentLM: I will move this to the last section for interchange
… and clarify
Bookmarks
<LaurentLM> next use case: A user decides to bookmark a location in an EPUB. The current cursor is used as an anchor. He selects the section. He triggers the annotation affordance, optionally enters a note, selects a highlight mode and color. He then saves the annotation. A bookmark icon appears on the page, near the line where the cursor was positioned when the bookmark was created.
LaurentLM: People also want to share bookmarks, it is not clear if the current spec covers bookmarks
Hadrien: You have bookmarks and highlights, and either can be annotated
… a highlight is essentially a range, but a bookmark isn't
… an annotation is complementary to those two (highlight and annotation)
ivan: I agree with Hadrien
… We are talking annotations and selectors, a selector could be a range or a bookmark
… we need to add them both to use cases, and yes they should be separated
… in the bookmarks use case, a big difference between an epub and web page, a book is typically much longe
… it is unusual for someone to read the whole epub in one go
… so we need to clarify in the use cases that there is an emphasis difference here
George: I see 3 or 4 items in this annotation. I see a tag, a color, the content, and one bookmark (the location)
… so when I move devices I have a last known reading position
LaurentLM: I didn't put this in the use cases, since this is not a user action, but rather is automatic
George: I don't know if that is a flag that goes across users
… in schools teachers want to know amount read, etc, but we aren't going there, we are just looking at the annotation transfer
Hadrien: I would treat last known reading position as different from a bookmark, and typically that can't be annotated
… And the progression is transient, so it may not be very interesting for this work
… It seems better for syncing across devices, so I would exclude it from our use cases
LaurentLM: But when I export wouldn't it be interesting to export it?
Hadrien: maybe, but not for sharing
brady: if I'm jumping between devices, I might want my reading position to follow, not in other use cases. Make it optional in the RS is a UX complexity. My alternative is to explicitly add a bookmark if I want to export it. It is almost an implementation detail. We should not muddy the waters with this current position
LaurentLM: We are at time, if everyone could review the use cases and add as needed, and we can finalize the next time we meet
George: Will we move this into the repo?
LaurentLM: Yes. Should we allow some editing first, or move it now?
George: I prefer github
ivan: Let's take it offline