Meeting minutes
A11y4Children follow-ups
Issue 240 update, "Could we build symbolic annotations with existing Web standards?"
A11y4Children follow-ups
Lionel_Wolberger: Notes the document from Web accessibility for Children Community Group
https://
Lionel_Wolberger: Finding well formed opinions based on years of experience
Lionel_Wolberger: They address areas I believe we haven't
Lionel_Wolberger: proposing new attributes, etc
Lionel_Wolberger: we'll need to consider how to work with this
matatk: Didn't see it via our archive
matatk: Believe some overlap to COGA, e.g. trauma
matatk: phps our concern is to be careful of how many attributes and not overdo
matatk: think the what rather than the how may be a useful approach?
janina: I've also not read it yet, but +1 to matatk
Lionel_Wolberger: Notes their Google Doc is packed with compelling ideas
Lionel_Wolberger: we'll have to schedule processing this
Lionel_Wolberger: asking what our next steps should be?
matatk: agree we need a bit of time to process this
matatk: Do we have existing expertise -- is there sufficient staffing to work on it?
matatk: Should note finishing symbols is a priority, but that also gives us a bit of time
matatk: suggests pinging COGA for staffing
matatk: we need to do some expectation management
mike_beganyi: agree on collab review and synthesizing priorities
janina: Fine with us consulting COGA on guidance, use cases, etc. but they may not be able to help with the technological/architectural issues.
… With respect to UDL, I think the question will be: how few tags can we introduce to meet most of the use cases?
… Are they generalizable in such a way that we can re-organize them on the fly? E.g. in some cases, a H1 may become an H2. I think EPub/DPub would be interested in this (from the conversations we've had).
… RQTF is happy to work on this [UDL] but they need specific questions from us.
Lionel_Wolberger: re-organizing?
janina: You might have a recipe book; the H1s could be e.g. Chicken, or they could be Soups.
… Is that where the CG's thinking is?
Lionel_Wolberger: Will return to this hopefully with some ideas of what next
matatk: agrees
Issue 240 update, "Could we build symbolic annotations with existing Web standards?"
Lionel_Wolberger: issue 240 with over 3K words
Russell: has this grown? Seems there's more there now
Lionel_Wolberger: Perhaps; latest is last week
Russell: I know him
Russell: Doing unicode for BCI; the registrar for the subtag registry in the unicode group
Russell: proposing rather than the BCI ids we use the unicode encoding
Russell: I agree it will be widely used once established
Russell: concern is that it would be using word spellings for ids, not sure that's what we want
Russell: believe we would want unique ids
Russell: notes that it would be 0x.. + 0x.. something else rather than our ids
russel also bci can change; they're generative
Russell: over time what once had meaning ceases to have meaning
Russell: the unique id wouldn't change, though its representation could
russel somewhat like the same word, different spellingrusselonce unicode is there it wouldn't change, only expanded
Russell: we do have ids for each unicode; but also id for concatinated unicode chars
Russell: puts me still on the fence here
Russell: bci codes are dependent on bci which should persist, but phps an unnecessary dependency
Russell: someone will need to maintain the db
Russell: the symbols aren't self explanatory, so concepts need to be maintained
Lionel_Wolberger: we need a primary key, and the unicode may not quite function that way
matatk: very helpful discussion
matatk: not up to date on thread but 3 concerns
matatk: whether unique values are the symbols or the building blocks for the symbols
matatk: understood both
matatk: I've seen symbols get deprecated, changed, etc
matatk: was that accurate?
matatk: we need to know whether we could manage a concatinated set of 0X values
Russell: correct
Russell: some of this is historical to bliss and how contractions, etc, work
The previous standard Russell mentioned: https://
Russell: notes first was pictographic but then parsed for component parts most of which (but not all) are meaningful on their own -- apparently about 1500
Russell: unicode cannot fully display every bliss construction
Russell: as unicode evolves, though, it will likely do even better at supporting bliss
Russell: the unicode activity is impacting bliss extensions; people consider it as they develop symbol construct
Lionel_Wolberger: let's see what our next action might be on this ...
Lionel_Wolberger: shares the registry screen
Lionel_Wolberger: if we understand 240 as a suggestion to change our primary key
Lionel_Wolberger: if it's pretty much a straight up replacement of ids for unicode values or concatinated unicode values that could be ok
Lionel_Wolberger: looking at an example with "mind"
Russell: great example
<Lionel_Wolberger> 24488 drug,mind-altering_drug
Russell: "mind altering drugs" would consist of two values
<Lionel_Wolberger> 15471 mind,intellect,reason
Russell: have actually done it that way, as a compound
<Lionel_Wolberger> 20518 sport
Russell: similarly "mind sports"
Lionel_Wolberger: thinking the ambiguity and ordering makes unicode a less useful key
Russell: certainly less readable
<Lionel_Wolberger> Proposed response: The topic was discussed at [put offset]
<Lionel_Wolberger> ... we do not find that the unicode spellings will substitute for the ID as we currently use it
<Lionel_Wolberger> ... which constitutes a nonambiguous, unique "Primary Key"
<Lionel_Wolberger> ... in the sense of a Primary Key in SQL and relational database theory
<Lionel_Wolberger> 21799 mind_sports
matatk: aren't we already sometimes concatinating?
Russell: sometimes when the same concept is repeated --
<Lionel_Wolberger> ... we are discussing it, we are not sure that this proposal will substitute for the 'primary key'