Meeting minutes
Use case document draft
LaurentLM: We have a first draft of use cases
… It will stay as a note, but will be the basis of our requirements
… So it is important that everything that is a real use case be here. Maybe not everything we can imagine, but everything that people really need
<LaurentLM> Use cases: https://
<LaurentLM> duga: it could also be surviving editions.
<Hadrien> +1 and this could even be across formats
LaurentLM: I feel it is the same use case. Basically something has changed
… other than the start and end and pagination, what else has changed?
… Anything else
Hadrien: Usually just the front/back matter, most everything else stays the same
duga: but there could be some text differences
LaurentLM: Yes, this is why we need to work on selectors, so changes to text will need to survive
delackner: Will this not use CFI?
LaurentLM: In w3c annotations you can use a lot of selectors, including CFI
… But CFI can be over precise
delackner: Footnotes are kind of sad, and there is no formal support for styled footnotes. We treat them as plain text
LaurentLM: Footnotes are different beasts
<LaurentLM> duga: CFIs is precise but has ability to adjust to content, via text added before after, + ids. You can correct a broken CFI.
<LaurentLM> ... about footnotes, you can have styled footnotes but implementations don't use styles. This feels like we have a way to style, but nobody uses it because it is a lot easier.
Hadrien: On the footnote side, it seems like an implementation issue
… In thorium mobile we won't do what Apple does, we will open a new webview with the documet that contains the footnote and scroll to its location
Dale: Looking at this from the edu direction, I imagine some profs who were tech savvy, some not
… So I ask how would this work in that world?
… We take something written student to teacher and vice versa, and we want that to be in the digital world
… When I think about an epub that has archival issues, I am thinking about how people will add this to the archive
… And some email systems strip large files, so I am wondering - are we talking about a separate document for the annotation?
… Is the annotation a separate document that links to an epub? So we don't have the overhead of the epub
… Are we considering all the possibilities?
LaurentLM: Yes, we are. We are considering detached files, and we are considering annotations in the epub. So both.
ivan: If I look at edu case, it is based on the teacher student interaction by import/export
… which is fine, but I would expect people expect a real time sync of annotations
… e.g. like Google Docs
… So the teacher annotates, and it just shows up in the students book
LaurentLM: I didn't want to mix this with the teacher use case
… But this is why I added the option of syncing in the cloud
delackner: When we look at real school deployments of shared reading systems, the success seems to be the areas that are low complexity
… Is there a solution that is simple enough that we don't require isolated silos?
… We need something that is simple enough to allow interop
LaurentLM: We should create something to interact with a server
… so we can crush the silos
ivan: Looking back at w3c web annotations forum, I extracted some comments
… Once annotations are extracted beyond the epub, they exist as their own thing. How do we reference those annotations? Is there a UID? What about copyright? etc
… the current annotation standard doesn't touch on this, but we may want to at least document all these issues
LaurentLM: we can create use cases around that, but I wonder if we should at this time. As you say, it is cimplex
ivan: It is fine to have it in the use cases, and then decide not to solve it
LaurentLM: So we will add these use cases from the 10 year old workshop?
ivan: Yes, but it is ok. One interesting thing that came up was annotations on religious literature, that itself become religious literature
Dale: X api may have some of this functionality
… it is working with a server, there is a language you can use to specify what you want to store or retrieve
… but in terms of having a server, a single point where you can store info
… X api already exists. Can that be used in a special case like annotations
LaurentLM: Could you review the x api spec and see if X api can process JSON and save/fetch and store where it is searchable
Dale: let me find out
LaurentLM: we talked about styled footnotes, but we have no use case for styled annotations
… there will be some needed
… and we need to see if e.g. Ruby is needed
… I will take the minutes and try to add new use cases
… next topic is an overview of the W3C annotation spec
Short overview of the Web Annotation spec
<LaurentLM> Link to the W3C Annotation spec: https://
LaurentLM: it is not simple, so I will just give an iverview
… [reviewing annotation sample in slide]
… [reviewing all the items that can go in a header]
… target is flexible - it can be a URL or a local structure
… target can be a source and selector
… this is most interesting to us
… target is very flexible, as is body
… body can just be embedded
… plain text is easy, as is styled text in markup/down
… real complexity is the target, and especially the selector
<LaurentLM> https://
LaurentLM: [discussing list of selectors]
… One is epub cfi selector (a left and right part)
… there is redundancy, as the target is specified in the json and in the cfi
… there are a lot of selectors. we need to decide on a subset if we don't want it to be overwhelming
… In this spec, there is the notion of collection
… you can't add, delete, etc. You can just fetch a set of annotations
… we don't really have time to discuss this spec today, but for next time please review the existing w3c annotations spec and decide what you like, what you don't, and what is missing
… e.g. the annotation does not have a good way to point at an epub
… should we have calls over the summer?
… I am missing for the next two weeks, but do we want to meet in August? Or skip to September
ivan: Two things on the presentation
… selectors can be combined
<ivan> https://
ivan: So a text before/after selector can be combined with a more targeted selector to limit scope (e.g. id)
… we also had a note specifically about selectors which makes it a little more readable than the core spec
… it might be easier to understand than the spec
Dale: Of the different selector models, are any just based on the DOM?
ivan: many if not most
Dale: We can just use the DOM structure to add labels
LaurentLM: There is no DOM range selector that is pure serialization of the DOM range
ivan: CSS selector is probably the most complex one. May be the most important one