-
Notifications
You must be signed in to change notification settings - Fork 27
Symbols the big picture
After today's (2017-07-15) meeting I thought I'd write down my understanding of the big picture as there are quite a few parts involved with support symbols.
Authors should be able to add AAC symbol references to content so they are displayed to support the meaning and provide an alternative for people who use symbols as their communication 'language'. Then, if a user's personalization preferences declare they want symbols they will be displayed. Sometimes the content designed to be only symbols - for example in communications charts.
The mechanism for selecting the content that the symbols support should be flexible to allow authors to apply symbols to large areas or single words. It will thus apply to standard HTML block-level or in-line elements.
The mechanics of providing the ref[s] to the specific symbol[s] will also use standard HTML mechanisms. In addiiton, The mounting and encoding of references needs to be compatible with other personalization semantics mechanism - see Options for Symbol.
Ideally the HTML spec will eventually be extended to provide new markup for symbol references but until then existing user-land extension mechanism will be used eg a data-* attribute.
Selection of specific references to be added to content can be a manual process by the author, by third party subject experts (e.g. Speech Therapists) or even automated, perhaps using A.I.
A single master ontology would appear to be preferable to letting each symbol set have it's own. Then other symbol sets will provide mappings to the master ontology. This would be easier to manage and should encourage some standardization. There are a lot of issues wrapped up in this, including technical and political. For example what format will the ontology be in, where does it live, who is responsible for managing it? One possibility is to use the Bliss Symbols set.
A basic schema will be as simple as an
- ID for referencing the symbol in content , eg
1234 - A set of concepts, language elements eg
crocodile, alligator
See July 8th notes on Options for symbol
Symbol sets are highly personal and may be localized so can be expected to be requested via personalization preferences. However authors are likely to want to specify a specific symbol set in their content.
A markup mechanism is required to define a specific symbol set to be used. It can be at document scope as only a single set is expected to be required. As new symbols sets may appear over time this needs to be extensable.
A 'mapping' is required to the master symbol ontology from the symbol set's specific symbols "ids". If an existing symbol set is used as the master ontology (eg Bliss) an optimisation can be made when that symbol set is chosen.
Each symbol set will need to maintain this mapping. Given the potential size of the mapping it size it will most likely be linked to from the content rather than embedded in it.
The symbols set identification and mapping link could be combined.
Currently this mapping is being proposed as using Schema.org metadata annotation, as it is already supported and can be authored as Microdata, RDFa or even as JSON. The other proposal is to use <link rel...>
Ideally, this would be done by browsers which also process use preferences for personalization. Until then this could be done at page code level using a code library, as a browser extension or even a javascript bookmarklet.
[JF: Indeed, and personally I envision these types of helper-tools 'bundling' the symbol set they ultimately use: that what we are envisioning is not URI references to each symbol that would be used in our actual mark-up, but rather that our metadata declaration simply informs the user-agent that:
a) the document has mark-up that supports symbol transformation, and
b) the Key# to symbol "look-up" table can be found at a specified URI. If the URI points to "Bliss", then the helper tool renders the image either from a locally-bundled version of the symbols OR via a URI reference, but that is determined by the look-up table and the helper-app: all the author need provide is a reference number, and all of the other magic happens elsewhere (i.e. the helper application / browser extension / other tool in the user-agent stack.)]