Meeting minutes
Ivan Herman: Some groups are looking at automatic scribe mechanisms
Susan Neuhaus: How does an auto scribe get proofread?
Ivan Herman: currently it generates the minutes, then members can review it
… but it is up to the working group
<Wendy Reid> https://
Avneesh Singh: Some group makes it the responsibility of the group for the corectness of the minutes, regardless of source
Wendy Reid: I have done this another group I chair. There are challenges, like Zoom requires AI companion. There are also accuracy issues
… strong accents and non-English names are problems
Ivan Herman: One experiment has the info reflected directly in to IRC, so it all looks the same as now
Wendy Reid: None of the tools allow live editing when testing for the AB
… but that would be ideal
… who is building that?
Ivan Herman: Co chair of the DID wg
Wendy Reid: Are they looking for test subjects?
Ivan Herman: Not ready for that yet. Too much lag still
Wendy Reid: Laurent Le Meur do you want to start with your PR?
PR #2973
Laurent Le Meur: 2973 now allows A/V bodies, in two main sections
… 3.4 body now allows an id so you can specify a relative url
<Ivan Herman> w3c/
Laurent Le Meur: you can use id when it is image, sound, or video (names from the original spec)
… so you now either need the value or an id that is a relative URL, depending on media
… And I added a zip container that contains the annotations and the files
… otherwise if it is in the epub then it needs to reference the json file in the meta-inf and all the binary files
… there are some issues raised by Ivan Herman
Brady Duga: why don't we only use zip? then we only have one file format and one set of directions for getting it out?
Laurent Le Meur: I didn'y think about that
… zip in zip is not ideal
… when you unpack you usually put it somewhere
Ivan Herman: I don't see a problem with that
… but there is one comment that worries me
… when you import from the outside, but you already have annotations, the two sets have their own metadata
… how do you merge these two? For instance the generator - does it get lost?
Laurent Le Meur: yes
Ivan Herman: then why have it in the first place?
Laurent Le Meur: This is really a technical log during development
… if we know something is coming from a specific RS, maybe we can adapt to support their quirks
… it is really administrative. We don't need to keep it
Ivan Herman: Generator is one thing, but what about other metadata?
… For instance, the book. Since they are the same book, do you check to see if they are the same
… So we have to explain what normatively what happens on import
Laurent Le Meur: If an annotation item is tied to a book, but import to a different book, what do we do?
Ivan Herman: I propose we merge this PR, but then look at the processing issue separately
Laurent Le Meur: Agree
Wendy Reid: Editorial comment - we use sound, shouldn't we use audio?
Laurent Le Meur: Yes, but then we depart from the W3C annotations spec. It is sound there
Wendy Reid: Can we file a bug?!
Ivan Herman: Sure, but there is no group
… maybe we can alias audio to sound
Wendy Reid: It feels odd to call text textualBody, when there is sound, video, etc
… why not 'text'?
Laurent Le Meur: Same answer, the original spec
Ivan Herman: isn't there text already?
Laurent Le Meur: Yes, but that is for remote text
Wendy Reid: Sometime you don't find bugs until you implement them
Laurent Le Meur: I am ok with changing things for modernization
Wendy Reid: Can we do that? Unless it is too hard
Ivan Herman: Audio is easy, but text is harder since it already exists
… Do we allow someone to add an audio URL? No, it is always relative. But this difference makes sense now [ed note: may not have captured that]
Susan Neuhaus: Do you need to consult the original to use this spec?
Laurent Le Meur: No it is written so this is completely self contained
Ivan Herman: For implementor no, but we have to define terms etc. I hesitate to go down the route where we abandon the predecessor
Annotations - Adding a replying function
<Wendy Reid> w3c/
Wendy Reid: I have a proposal - don't do it in v1
<Laurent Le Meur> +1 to wendy
<Hadrien Gardeur> +1 as well
<Brady Duga> +1
<Ivan Herman> +1
<Susan Neuhaus> +1
<Shinya Takami> +1
<Toshiaki Koike> +1
Wendy Reid: there are lots of issues it raises
… so defer it, or close it?
Laurent Le Meur: I think close and reopen if we want
… we just need to make sure nothing in our implementation prevents it
… which it doesn't
Ivan Herman: So when the minutes are generated I can close the issue
Annotations - Different Terms for the Same notion
<Wendy Reid> w3c/
Wendy Reid: No disagreement
Wendy Reid: We have name and title in the spec, they are very similar
Ivan Herman: They are used the same way
Wendy Reid: We have title and name, both are human readable ids. title is for set, name is for the annotation
Susan Neuhaus: I see nuance - title is often a work, name is often person place or thing
Laurent Le Meur: I don't mind renaming it. It is transient.
… The optional name is useful to for display purposes, but I don't care if it is name or title
Hadrien Gardeur: Why do we even have title?
… we have metadata about the book. I don't know when we will display it
… I am cautious about adding stuff that I don't understand
Hadrien Gardeur: Why do we need it?
Laurent Le Meur: It is a name for the file
Hadrien Gardeur: Yeah, but you can do whatever you want for naming
Susan Neuhaus: What about multiple sets imported?
Ivan Herman: That is a separate issue
Laurent Le Meur: It is a standard so we need to support everyone
… I don't see a reason to keep it, that is fine
… people can add a title if they want
<Grigorily Manucharian> simplicity is divine
Ivan Herman: Can we remove it in this pr?
Laurent Le Meur: yes
Text Style Properties
<Wendy Reid> w3c/
<Wendy Reid> See also w3c/
Wendy Reid: There was a comment about implementing this in a plugin
… there will need to be a mapping for colors
… his issue is, who creates that mapping?
… it's a good implementation question
Laurent Le Meur: I don't really understand
… looking at the LUA now
Hadrien Gardeur: There are whole discords for this plugin where they share their UIs
… in some cases there may be large numbers of colors
… and his question is how do I handle it
… this is the least problem for that plug in, as they handle annotations in a different way
… I think we just need extensibility
… on another note I saw and Android app for eink, and it is specific for eink because the standard colors don't work on eink
… so you will need to adapt to your own reading system, we can't really do it
Laurent Le Meur: He wants to know if he can add additional metadata
… and the answer is yes, we just have to make sure in the json.ld it is correct
… and he wants to add new words for values
… e.g. inverted
Hadrien Gardeur: They are both customizations
… for instance, they use a hash for the volume
… There are differences in the extensibility, properties and values
Laurent Le Meur: Properties aren't a problem, and we can be more specific
… but new values needs new text
… I wrote something about this, if the RS doesn't understand the color it should pick something else
… which should solve the problem
Ivan Herman: Going back to the original, how do we answer, and what do we do in the spec to avoid this coming up?
… for colors we need to make it clear that these can be adapted
… and they are really to make sets of annotations
Hadrien Gardeur: I disagree, extensibility informs the model
… if we don't consider it, then it will mess up when people extend
… in this case, there will be no rgb colors in our properties, if they want that they should use a new property
… extensibility does not need to conflict with interop
<Grigorily Manucharian> +1 will just need a list of all possible values
Susan Neuhaus: So it sound like extensilibilty won't impact interop
Ivan Herman: The fact that the model can be extended goes back to the original spec
… we should add this comment to the data model section
… beyond that, say for extensions to color, we shouldn't do that. We should just follow the original extension mechanism
<Hadrien Gardeur> +1 for that, I wasn't suggesting that we provide guidance on how to extend our model with specific properties/values
Ivan Herman: For colors, we add a note that says we are not talking about CSS colors
Wendy Reid: We don't have time for the last issue
Best practices or requirements?
<Wendy Reid> w3c/
Wendy Reid: but maybe people can comment on it
… in best practices we use normative language
… some of them would be very good requirements
… do we need a new section for RS requirements in addition to best practices?
… just want to open the conversation
Ivan Herman: Staff hat on - any MUST will need a test
… just want to make sure people understand the consequences
Susan Neuhaus: for creators, interop is huge
… so yes there is more work, but it is in service of the wider community
Ivan Herman: I do not disagree