w3c / adapt Goto Github PK

Add Web Annotation as an implementation.

https://www.w3.org/TR/annotation-model/

All 3 modules and the Explainer have in the Status of the document section references to AIRA instead of APA.

IE:
Status of This Document

This document was published by the Accessible Rich Internet Applications Working Group as an Editor's Draft.

The current draft includes two links to a proposed attribute: @context. However, while there are 2 links in the draft spec, there is no @context attribute defined anywhere in the document.

I recently submitted a pull request #50 to describe how to use the personalization semantics vocabulary in HTML Microdata and RDFa. I have since been told by a RDFa expert that RDFa does not add semantics to the element it is used on; instead, it describes how to use content from that element to add semantics to the page as a whole. This would mean that RDFa would not be a useful metadata language for most of the use cases we have for personalization semantics. I still need to learn more about this but wanted to log an issue.

If RDFa only annotates the page as a whole, then we should explore if there are features of personalization semantics for which that is useful. My guess would be that personalization at a page level would be a different kind of module from the others, and we might say RDFa could be used only for that module. This is likely to benefit use cases that impact search engines (e.g., pointers to alternate versions of content and the nature of the alternative) rather than direct user experience in user agents.

the personlization specification
https://w3c.github.io/personalization-semantics/content/index.html#use_case_interoperable_symbols
and
https://w3c.github.io/personalization-semantics/content/index.html#symbol-explanation
Should be check for accuracy

Is word net the best option? should we recomend something else?

Check with EA and m.lundalv and Chochai

also potential better wording:

We would like to create interoperable symbol sets for those with complex communication needs using Alternative and Augmentative Communication (AAC) systems. AAC systems designed for people who are non-verbal often use symbols with or without text. End-users tend to only learn one symbol set and cannot easily communicate with other symbol users in a written format or may struggle to understand different symbols used in different applications. Some symbols are subject to copyright and cannot be shared across applications. However, there are open symbol sets that can be shared and mapped against concepts, generating representative text. This text can be translated into different languages and even used to present a different set of symbols. If users' symbols are mapped to the same concepts then user agents can load the user understandable symbols and enable access to the web and other applications.
User experience: AAC users, those working with AAC users and others will be able to load symbols that they understand into different applications that have been made by a different provide

Compiling here a list of alternatives one should consider / compare and contrast.

@michael-n-cooper did a really good job comparing some serialization formats here:

https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content

I'm starting to compile different architectures here:

#76
#73

As well as taxonomy alternatives here (if you go with @michael-n-cooper 's current architecture model):

#74

Feel free to add your alternatives here as you think them through.

In the Content Module 1 -> 3.4.4 There is an inconsistency related to the medium definition. The definition in 3.4.4 for medium states "Elements that are used by over 60% of a user group (such as parents or teachers) when they interact with the content."
But the definition in section 2.1 indicates 60% "high" and 20% is "medium" as follows:
High — used at least 60% of the time or more.
Medium — used by 20% of users, 20% of the time.
It's not clear why they definitions are different or which section is correct.

The current code example shows the following:

However, the current list of allowable token values is simplets, medium, or low (there is no "critical").

Additionally, there is currently no such attribute known as "aria-function" - this should be removed from the example. (source: https://www.w3.org/TR/wai-aria-1.1/)

In the Personalization Semantics Explainer 1.0 document, "Adaptable Tools" link should resolve to the appropriate document.

In the Personalization Semantics Explainer 1.0 document, "Adaptable Help and support" link should resolve to the appropriate document.

In the link text "Adaptable Help and support", "support" should be uppercase - "Support".

Make update to RDFA section and associated example.

IndieUI: User Context was known to introduce privacy risks, which the specification called out. Personalization semantics takes a different approach but should be reviewed for any privacy implications, and address them in the spec.

The current example shows the following:
<aui-distraction="moving ad">

aui-distraction is supposed to be an attribute, and not an element.

I believe the correct example would be:
<img src="animated.gif" alt="animated banner advertising for Foobars" aui-distraction="moving ad">

The discussion in #73 surfaces a question that I've been thinking about lately...

Are we overloading the term semantics? We've spent many years getting authors used to the idea that semantics relate to the purpose (role) of an element, or its other characteristics (name, state, etc.).

Now we propose to extend the definition of semantics to encompass an elements visual representation (under certain circumstances). I wonder whether this will cause confusion, and consequently make things harder for authors to understand and adopt?

• However what is familiar for one user may be new for another requiring them to learn new symbols.
  --> needs a couple of commas:
  However, what is familiar for one user may be new for another, requiring them to learn new symbols.
  (note that this sentence occurs twice in the document)
• programanticaly --> programmatically
• At at the user end --> At the user end
• keyboard short cut --> keyboard shortcut
• In addition it could be identified as important
  --> needs a comma:
  In addition, it could be identified as important
  (note that this sentence occurs twice in the document)
• non vocal --> non-vocal
  (there are 2 instances of non vocal in the document)
• These symbols are in fact peoples language.
  --> needs an apostrophe after peoples:
  These symbols are in fact peoples' language.
  (this sentence appears twice in the document)
• Unfortunately many of these symbols are both subject to copy write and are not interoperable.
  --> needs a comma, and change copy write to copyright:
  Unfortunately, many of these symbols are both subject to copyright and are not interoperable.
• mens clothing --> men's clothing
• more frequently use womens clothing option
  --> more frequently used women's clothing option
• (see bellow). --> (see below).
• Example user experience:, --> Example user experience: (i.e. remove the extra comma)
• compose(default importance = "critical") --> add a space after compose
• Proposed attribute:coga-destination --> add a space after the colon
  (also, add space after colon for attribute:coga-context and attribute:coga-numberfree)
• diffrent --> different
• contactus --> contact us
• gender#femail --> gender#female
• not only thoughs who can implement RDF logic
  --> not only those who can implement RDF logic
• Further , --> remove the extra space before the comma
• for Non verbal people
  --> nonverbal is all one word, and it does not need to be capitalized in the middle of the sentence
• alternatively wordnet nodes could be referenced.
  --> Alternatively, wordnet nodes could be referenced.
• High important --> Highly important
• for people learn via keypoints or examples
  --> for people to learn via key points or examples
• value : --> remove the extra space before the colon
• information.or --> information or
• tool tip --> tooltip
• inforamtion --> information
• additonal --> additional
• values:tooltips --> values: tooltips (i.e. add space after colon)
• alternitive --> alternative
• it's direct parent --> its direct parent (don't need apostrophe unless short for "it is")
• mid sentence --> mid-sentence
• claiming there preferred --> claiming they preferred
• privacy ,it --> privacy, it (i.e. move comma before space)
• experience different amount of --> experience different amounts of
• turn off distractions such as skype, and facebook, across different devices,
  --> turn off distractions, such as Skype and Facebook, across different devices,
• one miunet --> one minute
• If multiple names are used they can be separated by a coma.
  --> If multiple names are used**,** they can be separated by a comma.
• locaction --> location
• makes this message relevent --> makes this message relevant
• "home" nd "work" --> "home" and "work"
• If multiple locations are relivent they can be separated by a coma.
  --> If multiple locations are relevant they can be separated by a comma.
• "my calender" --> "my calendar"
• lable --> label

In 2.3.2.2 Solutions for security and privacy, keygen is listed as a solution.

However, the latest version of HTML indicates:
[[
keygen has been removed
]]
http://www.w3.org/TR/html52/changes.html#changes-fpwd

The current example shows the following:

1. the "name" and the "aui-field" should match in purpose - is it First name or Telephone?
2. there is no token value of "phone", it should be "tel"

Define semantics used to enforce code of conduct or acceptable use policies between users or within the context of interactive content.

To meet the needs of i18n and machine inter-operability, our taxonomy definition will need to be normative.

Additionally, whatever definition we agree to must be testable and scalable if we hope to make these measurable requirements at some point (as opposed to author best practices). For example, what is a "short sentence"? Less than 5 words? Less than 10 words? Content authors striving to meet these goals will need to have a definition of what success looks like, and for compliance requirements the results need to be testable and repeatable.

Initial draft to improve Introduction and use cases in explainer module. Will create new branch for proposed revisions.

The example at https://w3c.github.io/personalization-semantics/content/index.html#simplification-example includes aria-function. This needs removing or changing to whatever the current attribute is

<input aui-simplification="critical" aria-function="submit" value="Submit" type="submit"/>

An internationalization principle is that text should not be in attributes. Properties should be structured in a way not to use that design.

Requires edits to both documents prior to merge.

I wrote this over email, editing and moving it into a github issue to allow easy tracking.

Regarding the comparison of serialization strategies for the metadata, I think it is worth exploring (i'm genuinely curious, not sure how it compares) and adding to the list a lower level API per the Extensible Web Manifesto and leave the ergonomics to userland code. Here are a couple of ideas worth comparing and contrasting:

(1) JSON-LD
(2) A JS API (viz the AOM)

In both (1) and (2) the approach here is that you (a) detach the semantics from the DOM/presentation and (b) leave ergonomics (or the color of the bikeshed) to be explored/innovated from userland code with polyfills. So, for example, you'd expect user agents to understand these low-level APIs (1) or (2) or another alternative and you'd allow/foster/encourage JS libraries to fill the gap of ergonomics. In time, if you find a specific userland framework has won and everybody converged to it, you bake that into the user agent.

I think that one of the reasons why you may be struggling to find a silver bullet in your current analysis is because I believe that there is a fundamental difference between the DOM and the data structure you want to build. Specifically, when it gets to position: absolute everything falls apart, and, in my experience, a lot of production-level code (e.g. things that you'd find on gmail.com, yelp.com, hertz.com, opentable.com, rather than on demos/prototypes) is written in a manner where the DOM doesn't represent anymore the semantic data structure.

In Google Search, I have found that the semantic web has taken off when JSON-LD was introduced: de-coupling the semantic information from the DOM substantially increased its expressivity, earlier tied to microdata/rdfa (at the cost of duplication of data and misrepresentation - which I think are worth paying in exchange to expressivity).

Here is an example of what that could look like (just take this as an example to illustrate the concept rather than a specific proposal):

<html>

  <script src="https://jquery.com/a11y.js">

  <button intent="undo"/>
 
</html>

Which would be equivalent, from a user agent perspective, if the user had written something along the lines of:

<html>

  <button id="1"/>

  <script>
    // TODO: actual JS api largely TBD.
    document.a11y.actions.push({
      label: "undo",
      id: "1"
    })
  </script>
</html>

The latter is obviously unergonomic, so we wouldn't encourage people to use it directly, but the cool part about it is that it enables/delegates the bike-shedding to userland, giving somebody else the ability to come up with a different serialization, like

<html>

  <script src="https://anotherpolyfill.com/a11y.js">

  <button itemscope itemtype="http://schema.org/UndoAction"/>
 
</html>

Unclear to me if this is any better than what you currently have, but it seems like a fundamentally different approach worth comparing / contrasting :)

Personalization semantics defines a set of attributes, but arguably these attributes mainly serve to define a vocabulary. Other technologies such as RDFa and HTML Microdata could also add similar semantics to content, but that won't be useful unless the vocabulary is standardized. We might want to consider focusing the spec on the vocabulary, and leaving the specific attributes to implementation. Or separate the "vocabulary" aspects of the spec from the "ARIA features" aspects, so the vocabulary part can be reused by others.

The following editorial updates are needed in the Content Module 1:

2.1 -> User Experience -> Last sentence:
the quotation mark is missing after “More options” and remove the word “or”.
The sentence should read:
In the sample user experience available at https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html, the user can select a  "More options” button or "Less options" button to simplify the web content by hiding or displaying elements that are of low importance.

2.2 -> Requirement -> remove the “ed” from the word 'displayed" in the following sentence:
Therefore, the user agent or script should understand the context of links, buttons, and other page elements so that symbols and text display in a way each user understands.

2.2 -> Example user experience - remove the extra colon.

3.1.4 Values
for copy, cut, and profile values are missing a period at the end of the sentence.
for drag value - change the first sentence to read - Enables drag and drop capabilities.

3.3.4 -> Values
for ccCsc value the "y" should be removed from the word "codey".
for dateEnd value the description is missing a period at the end.

Define semantics for the implementation of trigger warning for explicit and violent content.

Forking from this thread where this originally came up.

So a user agent could make this changes before the page is rendered to accommodate his personal preferences

What makes us believe that this is the responsibility of the User Agent as opposed to the content author? That is, what makes us believe that the content author should declaratively state what are the semantics of the affordance and let the user agent figure out what to do?

Is there anything that this declarative affordance (i.e. the aui-action property) unlocks that couldn't be done before by the developer with custom CSS/HTML/JS (e.g. something that crosses security boundaries or has access to lower level APIs)?

What is it that we are buying moving this / baking this to the user agent layer? Consistency? Ergonomics? Implementation cost? Composition? Lower level access (e.g. ARIA gives declarative access to screen reader's API)?

What other alternatives have we explored to satisfy this use case? Why shouldn't we expose a programmatic/imperative javascript API like:

// returns true if the user has a preference for text over pictures
if (document.preferences.textToPictures) {
  // do stuff, hide stuff, show stuff
  // actual color of the bikeshed TBD
}

and let the developer figure out what to do with that setting (isomorphic question to "why should this be the responsibility of the user agent")?

Or maybe a media query for CSS that enables you to write a selector to change your UI based on the user preference? E.g.

// Shows numbers in text
@easylang .numbers-to-text {
  display: block;
}

// By default, hides them
.numbers-to-text {
  display: none;
}

// Shows large numbers by default.
@easylang .large-numbers {
  display: none;
}

With the following HTML structure:

<p>There are <span class="large-numers">13i828230840923840234</span><span class="numbers-to-text">a lot of</span> of users</p>

Importantly, in this alternative design, the responsibility of what to do with the UI/UX is onto the developers rather than the User Agent, and the User Agent is only responsible for managing preferences and for brokering that in a safe way with the developer.

Sorry if this is a silly question, but I couldn't find an immediate answer reading your docs.

The section on aui-symbol mentions the following example:

<img aui-symbol="http://wordnet-rdf.princeton.edu/wn31/girl-n" href="mygirlsy.bmp" >

I imagine that a conforming user agent would render the appropriate symbol instead of the referenced image. But how can color contrast be guaranteed in this case?

We should also take into account that many pages today use icon fonts or inline SVG for symbols:

<i aui-symbol="http://wordnet-rdf.princeton.edu/wn31/girl-n" class="fa fa-female"></i>

The benefit of this is that it is possible to style these with CSS, again allowing authors to control color contrast. How would aui-symbol work in these cases?

It is unclear in either of the "Description" or "Supported Values" sections that the intent here is that the attribute can support a space-separated list of values, although the example appears to demonstrate that fact.

Recommend a clearer explanation of this in the spec.

As currently written today, I cannot figure out what is being asked for here from content contributors.

 > symbol identifies the concept for symbols.

Huh? A symbol is a symbol? What does that mean?

 > symbol accepts the values of a URI or shortened URI.

But, what does that URI resolve to? The symbol? An explanation of the symbol? Something else?
Why is the content author linking to an external resource, and what is that resource supposed to be?

 > Note that namespaces are the only additional parsing that maybe required to identify the concept.

Namespaces??? How? Where? This makes no sense at all...

 > To help this be interoperable without an RDF parser we recommend referencing the most commonly used ontologies and the highest level concept.

Ontologies? This term is used exactly once in this specification, with no other explanation or reference. What does an ontology have to do with symbols?

RDF parser? What RDF parser? Where, how?

Currently, this section of the spec makes no sense, and is extremely unclear what is being asked of from the author. There is no clear goal, nor explanation of what the final outcome should look like, or achieve.

Currently this states:

Supported values: 24 hour date time format. ​DD.MM.YEAR.HOUR.MM - DD.MM.YEAR.HOUR.MM where the second date is an optional exclusive expiry date.

​May I suggest that this pattern is actually something of an anti-pattern (or at least, is "non-standard")​. Can I propose that instead we require the date format to follow the ISO 8601​ (Date and Time Standard) which takes the format:

2018-09-17T16:48:58​Z​
(YYYY-MM-DDTHH:MM:SS + Z which denotes UTC)​

Additionally, the ISO notation allows the author to specify the time based on either UTC or with a UTC off-set (which is not addressed in the current draft)​

lots of use cases are not in coga groups

Are these really destinations (e.g. and not actions)?

• comment - "submit a comment on the current item" (Submitting a comment seems like an action.)
• left - "Changes the location of the selected item(s) to the left." (Moving items seems like an action.)
• right - "Changes the location of the selected item(s) to the right." (Same observations as with left.)
• post - "post current item. Item will be visible to other parties." (Posting an item seems like an action. Also what is the difference between post and comment?)
• related - "Adds a related item(s) to a pre-selected list of items." (Again, seems like an action to me. Also what does "related" mean exactly? In the UIs I've seen, there are options to add the currently selected item(s) to a list. I've never seen an option to add "related" but not explicitly selected/obvious items to a list.)

Are these really actions (e.g. and not destinations)?

• toc - "opens a table of content" (If "opens" means "takes you to a table of contents page" then I don't see how that is any different in nature than about, which is a destination presumably taking one to a page with "about us" information.)
• profile - "opens the user's profile page" (Similar observation to toc. Being brought to another page of static content seems like a destination.)

These items seem similar in nature but some are actions and some are destinations and some are both. If their current categorization is correct, I believe some clarification is called for:

• Related to help:
  • Action: help - "opens a help function."
  • Destination: help - "a help function, support or instructions"
• Related to options:
  • Action: settings - "open settings and options"
  • Destination: language - "language options"
• Related to moving items:
  • Action: left - "moves a selected item to the left to another column or list"
  • Destination: left - "Changes the location of the selected item(s) to the left."
  • Action: right - "moves a selected item to the right to another column or list"
  • Destination: right - "Changes the location of the selected item(s) to the right."

These items seem like they need some additional clarification:

• signin - "sign in to current web site or application" (If it brings you to a sign-in page, then I can see that the change in page is a destination. But what if it keeps you on the same page but shows a pop-up with username and password fields? Is that still a destination? Is it then an action?)
• signout - "sign out current web site or application" (Similar observation: If it brings you to a new page, that seems destinationy. But if it merely logs you out, keeping you on the same page, that seems more like an action.)

Finally, something that might be worth considering: Is there really value in having actions versus destinations? Reasons I think they might be worth combining into a single property:

1. There seems to be many possibilities for authors to get these things confused.
2. Users who need familiar symbols for terms (e.g. for "help") are probably going to need the same symbol regardless of whether or not "help" is an "action" or a "destination".
3. If I understand things correctly, destination defaults to the ARIA "link" role and "action" defaults to the ARIA "button" role. Why is the type of control relevant to the end user who needs personalization? (Personally, I don't think it is.)

I need my phone verified

All of the items in the field table seem like information which the user would provide via an input control. The exception is section-***** which is defined as "used to group forms together". The user isn't expected to provide that, correct?

In addition, my understanding of the purpose of the field attribute is that it can:

• Facilitate replacement of existing labels with more easily understood/recognizable words and/or symbols so that the user knows what information is expected
• Work with a personalization-specific form population tool

Assuming my understanding is correct, section-***** won't easily be machine parseable because the "*****" (as I understand it) is a wildcard.

With all of the above in mind, is section-***** really a field?

Is there a (good, solid, crisp, concrete) doc I could be reading about the expected applications of the Adaptable Content Module? I'm looking for a crispier definition of the problem that you are addressing (i.e. what specifically are you trying to address from a user experience perspective) before you introduce any specific solution (e.g. field names, attribute names, etc).

This can include:
Symbols and graphics that they are familiar with
Tooltips
Language the use can understand
Keyboard short cuts

There are a paragraph or two in the spec with a lot of vague applications (e.g. "This can include" -- but will it really?) in this section, but I'm having a hard time taking these applications seriously (e.g. if you were really trying to solve each of these individual problems, would we really chose to use the solution specified here?).

I'm specifically interested in understanding what kinds of problems you are trying to solve with properties like action, destination and field as well as the possible values it takes (e.g. compose, delete, confirm, etc).

For example, take a single instantiation of these values and help me understand how this works. E.g. if action="compose", how would you expect here the User Agent would help?

Do we already have a solid doc (i.e. an in-depth/full understanding of the user pain and how we think user agents can help) going over the problem that we are trying to solve from a user experience perspective? If so, pointers? If not, should one be created?

Things I'd want to find in a solid explainer:

• a crisp definition of the problem statement
  • canonical examples
• related technologies
• prior art
  • does a similar problem appear in a different platform (e.g. windows? mac? android? ios?)
• alternatives being considered
• design of incentives: are incentives well-aligned between involved parties?

PS FWIW, I'm having a better time understanding how the Adaptable Help and Support module can effectively help a user.

The attribute step in Step Indicator section is to number the steps in sequential order. The step attribute in HTML specifies the legal number intervals for an element. Example: if step="3", legal numbers could be -3, 0, 3, 6, etc. Tip: The step attribute can be used together with the max and min attributes to create a range of legal values.

When I submitted #50 I intended to include a description of how to use the personalization semantics vocabulary could be expressed as ARIA attributes. But as I thought about what the section would have to say I realized it would not work as currently conceived. Several other people have also asked about the structure with respect to ARIA, so I wanted to put a description of the issues in one place.

There are several challenges to implementing personalization semantics as an ARIA module:

1. The function of ARIA is to define semantics that map to Accessibility APIs. However, nearly all the features in personalization semantics do not map to AAPIs. I do not think we expect tools will access the semantics through accessibility APIs, so there would be no need or value in adding that layer to the mix. Unless we can make a compelling argument that accessibility API mappings are possible and needed, I don't think the ARIA WG will support this as an ARIA module.
2. Most of the personalization semantics properties require values. This means they would need to be implemented as attributes in ARIA / HTML. Currently we expect that would be done with the "aui" prefix like aui-action="compose". However, HTML does not permit attributes with this prefix. The use of attributes with the "aria" prefix took years to negotiate. In order to create aui attributes, we would need to convince the Web Platform Working Group to accept attributes with the "aui" prefix, which could be a long negotiation and ultimately not succeed. Alternatively we could try to convince the ARIA Working Group to allow us to use the "aria" prefix, but for the reason above I'm not sure that would succeed.
3. It might be possible to recast the personalization semantics properties into a form that does not require values. Then it would be possible to use them as values of an existing attribute like role, using the "aui" prefix in some form like role="aui-compose". But it would take some exploration to determine whether the role attribute is suitable for this. We could propose a new attribute for personalization, which has the advantage of only requiring one new attribute instead of an indefinite set, but that still has a long path. And this approach would only work if we can find a way to make all personalization features work without requiring values.

We will need to determine the resolution to those issues to be able to describe how to use personalization semantics as an ARIA module. If we are not able to address those issues, we will have to conclude that personalization semantics does not map to ARIA. Currently that leaves HTML Microdata as the most likely way to apply the vocabulary to content.

Content Module 1.0 -> 3.5.1 -> Supported values
This is the only section that has "Supported Values" and it’s not clear what the difference is between the supported values listed in 3.5.1 which are inconsistent with the values listed in 3.5.4.
Should supported values in 3.5.1 be the same as the values listed in 3.5.4 or be removed?

Since Personalization Semantics now defines an abstract vocabulary, there is no need to distinguish tokens from those of other metadata languages via a prefix. I think it is confusing to have the prefix baked into the vocabulary terms, and reduces future flexibility. So for example, I think the "aui-action" term should be just "action", etc.

In vocabulary implementations we would suggest the prefix in ways suitable to the implementation language:

• The ARIA section could say "prepend 'aui-' to the vocabulary term to get the role token, so 'action' becomes 'aui-action'."
• The RDFa section would use a namespace instead, so could say "map the namespace prefix 'aui' to the namespace '@@' and use that with terms, so the 'action' property would become 'aui:action'."
• The HTML Microdata section wouldn't use the prefix, but would say to use the "itemtype" attribute and use the same value as we define for the RDFa namespace.

The adaptable content module lists an enumeration of action-like tags (e.g. undo, remove, etc).

Is there a doc/section going over where we looked at before compiling that list?

FWIW, here are a few things that I'd expect to see in a background research section somewhere in your explainer:

• academically: framenet, verbnet, wordnet
• standards track: activity streams and schema.org actions
• industry applications: opengraph actions, gmail actions, search actions

These are all more action-oriented and don't cover your other modules (e.g. easylang, numfree, etc). There were also designed for a different application (activity streams for social applications and schema.org for search/conversational assistants, e.g. alexa/siri/home) but seemed like somewhat related technologies.

We must acknowledge our TF Members.
Checking for Thaddeus for example I didn't see him listed in our Acknowledgements, there may be others.

N.B. Edited because this issue was subsequently split into two as described in comments.

The actions table of values has duplicate (and in some cases triplicate) values. For instance brightness appears in the following rows (where the header row is row 1):

• row 43: "brightness: change or show the settings for the brightness."
• row 70: "brightness: adjust the screen or application brightness. Often used with increase or decrease but is sometimes used alone as a menu name or item."
• row 76: "adjust the screen or application brightness. Often used with increase or decrease but is sometimes used alone as a menu name or item. EDITOR'S NOTE: At risk pending implemetions (sic)."

Other duplicates in actions:

• channel (appears three times)
• connect (appears two times)
• loop (appears two times)
• mediaPosition (appears two times)
• temperature (appears three times)
• volume (appears three times)

Duplicate in destination:

• related (appears two times)

Extra row in field:

• Beneath the bdayDay row, there is a row with the same description ("day of birthday") but no name value.

​Would not "importance" be a higher level​ requirement than just for messages? For example, in a scenario where a page is being "simplified", wouldn't the author want to denote sections of the content that is "critical" (and so do not "simplify it" away)?

Could we not just reduce this to a value of "importance" and let it cover more use-cases?

(Spin-off issue from issue #65, as requested by @clapierre)

The actions table of values does not appear to be grouped in any logical order. Two candidate orders spring to my mind:

• Alphabetical
• Functionality (email, purchases, media controls)

Other orders might make more sense. But given the size of the list (64 items when duplicates have been removed), I think some arrangement will make the list easier to process.

https://rawgit.com/w3c/personalization-semantics/requirements/requirements/index.html#step-indicator

Personalization semantics was originally conceived in the COGA TF. There should be a section in the acknowledgements crediting those participants.

On W3C Personalization Tools 1.0, section 2.2 Reminders and Messages, you go:

For example, users can disable push notifications and messages on applications such as Skype and Facebook across different devices, however, they may forget to re-enable these notifications and messages. The following defined values allow an alternative solution for users to manage reminders and messages by forming a cross-application and cross-device matrix that manages all reminders and messages. These values are based on a matrix for reminders and messages at the operating system, browser or cloud level. A user's contacts can be organized by importance or by groups. For example, the CEO of the company a user works for and a user's child care giver could both be set to critical. A user's contacts may also be grouped. Family members may be in one group, important colleagues may be in a second group, and friends in a third group.

How do you think this would work? Specifically:

A user's contacts can be organized by importance or by groups. For example, the CEO of the company a user works for and a user's child care giver could both be set to critical. A user's contacts may also be grouped. Family members may be in one group, important colleagues may be in a second group, and friends in a third group.

And

Example User Experience: Question for the group. How would data be shared, if at all, between applications containing, for example, contacts and the proposed mechanism

How does "The CEO of your company at facebook" gets reconciled with "The CEO of your company at your contacts list" and "The CEO of your company at linkedin"? That is, how do you know that they are the same entity/person? That is, facebook and linkedin and your contact list don't all share the same ID namespace, so how do you associate them into the same entity/person/id? For example, how does the user agent know that

https://www.facebook.com/sgoto
https://www.linkedin.com/in/samuelgoto
http://twitter.com/samuelgoto
http://github.com/samuelgoto

These are all the same person?