Meeting minutes
ivan: Some groups are looking at automatic scribe mechanisms
sueneu: How does an auto scribe get proofread?
ivan: currently it generates the minutes, then members can review it
… but it is up to the working group
<wendyreid> https://
AvneeshSingh: Some group makes it the responsibility of the group for the corectness of the minutes, regardless of source
wendyreid: 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: One experiment has the info reflected directly in to IRC, so it all looks the same as now
wendyreid: None of the tools allow live editing when testing for the AB
… but that would be ideal
… who is building that?
ivan: Co chair of the DID wg
wendyreid: Are they looking for test subjects?
ivan: Not ready for that yet. Too much lag still
wendyreid: LaurentLM do you want to start with your PR?
PR #2973
LaurentLM: 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> w3c/
LaurentLM: 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
duga: why don't we only use zip? then we only have one file format and one set of directions for getting it out?
LaurentLM: I didn'y think about that
… zip in zip is not ideal
… when you unpack you usually put it somewhere
ivan: 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?
LaurentLM: yes
ivan: then why have it in the first place?
LaurentLM: 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: 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
LaurentLM: If an annotation item is tied to a book, but import to a different book, what do we do?
ivan: I propose we merge this PR, but then look at the processing issue separately
LaurentLM: Agree
wendyreid: Editorial comment - we use sound, shouldn't we use audio?
LaurentLM: Yes, but then we depart from the W3C annotations spec. It is sound there
wendyreid: Can we file a bug?!
ivan: Sure, but there is no group
… maybe we can alias audio to sound
wendyreid: It feels odd to call text textualBody, when there is sound, video, etc
… why not 'text'?
LaurentLM: Same answer, the original spec
ivan: isn't there text already?
LaurentLM: Yes, but that is for remote text
wendyreid: Sometime you don't find bugs until you implement them
LaurentLM: I am ok with changing things for modernization
wendyreid: Can we do that? Unless it is too hard
ivan: 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]
sueneu: Do you need to consult the original to use this spec?
LaurentLM: No it is written so this is completely self contained
ivan: 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
<wendyreid> w3c/
wendyreid: I have a proposal - don't do it in v1
<LaurentLM> +1 to wendy
<Hadrien> +1 as well
<duga> +1
<ivan> +1
<sueneu> +1
<shiestyle> +1
<toshiakikoike> +1
wendyreid: there are lots of issues it raises
… so defer it, or close it?
LaurentLM: 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: So when the minutes are generated I can close the issue
Annotations - Different Terms for the Same notion
<wendyreid> w3c/
wendyreid: No disagreement
wendyreid: We have name and title in the spec, they are very similar
ivan: They are used the same way
wendyreid: We have title and name, both are human readable ids. title is for set, name is for the annotation
sueneu: I see nuance - title is often a work, name is often person place or thing
LaurentLM: 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: 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: Why do we need it?
LaurentLM: It is a name for the file
Hadrien: Yeah, but you can do whatever you want for naming
sueneu: What about multiple sets imported?
ivan: That is a separate issue
LaurentLM: 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
<gman> simplicity is divine
ivan: Can we remove it in this pr?
LaurentLM: yes
Text Style Properties
<wendyreid> w3c/
<wendyreid> See also w3c/
wendyreid: 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
LaurentLM: I don't really understand
… looking at the LUA now
Hadrien: 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
LaurentLM: 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: They are both customizations
… for instance, they use a hash for the volume
… There are differences in the extensibility, properties and values
LaurentLM: 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: 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: 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
<gman> +1 will just need a list of all possible values
sueneu: So it sound like extensilibilty won't impact interop
ivan: 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> +1 for that, I wasn't suggesting that we provide guidance on how to extend our model with specific properties/values
ivan: For colors, we add a note that says we are not talking about CSS colors
wendyreid: We don't have time for the last issue
Best practices or requirements?
<wendyreid> w3c/
wendyreid: 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: Staff hat on - any MUST will need a test
… just want to make sure people understand the consequences
sueneu: for creators, interop is huge
… so yes there is more work, but it is in service of the wider community
ivan: I do not disagree