<Thaddeus> +present

<LisaSeemanKestenbaum> regrets, roy, charles

<sgoto> hey all

<Thaddeus> same

<LisaSeemanKestenbaum> introductions

<LisaSeemanKestenbaum> zakim pick scribe

<LisaSeemanKestenbaum> scribe: Becka11y

<scribe> scribe: becka11y

<LisaSeemanKestenbaum> https://w3c.github.io/personalization-semantics/

looking at help or tools https://w3c.github.io/personalization-semantics/tools/index.html or https://w3c.github.io/personalization-semantics/help/index.html

Lisa: 3 modules - need more mature version of explainer and need more mature drafts of content and help & tools
... Becky was supposed to look at Help and Thaddeus at Content - has that happened

<LisaSeemanKestenbaum> https://w3c.github.io/personalization-semantics/help/index.html

Becky: Needs more info and understanding before I can tackle this on my own

JF: sees a number of parts but has concerns about how we are moving forward (although admits that is new ot the group). Seems we are focusing on solutions before we fully understand the semantics involved
... would like to focus on taxonomy first; concerned about volume of attributes proposed, complexity and worried main stream developers will struggle with that

Michael: agree about separating taxonomy and how we apply to content; believe that we need to focus on taxonomy for now. Sees Becky’s confusion about overlapping values, etc; Proposes that folks don’t get wrapped up in terms that are currently in the documents
... focus more on what the concept is and try to determine the set of terms to accomplish that concept or goal

Michael; believe Lisa can give us the background to help us

<Thaddeus> Michaels input is helpful for me to move forward with tools

<LisaSeemanKestenbaum> https://w3c.github.io/personalization-semantics/help/index.htm

Lisa: Help document is a very early draft

<sgoto> https://w3c.github.io/personalization-semantics/help/index.html (other link 404s)

Lisa: goal is to enable people to provide extra support and help to mostly people with cognitive disabilities but may help others
... we have in this doc. 2 proposed implementations. 1 - linking to something that provides more information - we need to tag that as to what type that alternative content/ more information is
... we might have alternative content that addresses more than one type of issue: numberfree, non-literal, or other type of extra help
... we can provide an entire page that is alternative content that is easier - no numbers, simple language, etc
... could be metatdata or different sections of the page
... Need direct link to alternative or identified within the dom - not as easy as alt text or putting alternative into attribute value
... some simple ones can be aui attributes

<LisaSeemanKestenbaum> https://w3c.github.io/personalization-semantics/help/index.html#alternative-explanation

Lisa: gives an example of alternative supplied in the DOM

Becky: how does user access that alternative info?

<sgoto> is your expectation that the user agent is able to hide the other text?

Lisa: via personalization preferences

JF: so all of this information would be in the DOM - but can also be a link to an alternative; This brings up concerns based on all of the conversations and push back over long description in HTML5

Lisa: extended vocabulary can be in a div, inline, complementary or other region; but want to reference between one another
... we need to get the vocabulary completed - either at a page level or a section

<LisaSeemanKestenbaum> https://w3c.github.io/personalization-semantics/help/index.html#numberfree-explanation

Lisa: easylang is really a summary of the other cases but for other things (such as numberfree) the substitutions are much easier perhaps as an attribute
... this is simpler to implement but makes the spec appear more complicated
... could be implemented as a popup by the user agent; User makes the selection of what type of replacement they want

Michael: using easylang exampler there are related use cases: this is the easylang version of x; the easylang version of x can be found at y
... agree need to focus on vocabulary first

<LisaSeemanKestenbaum> qa

JF: content when author provides supplementatl or alt. content - for easylang author needs to provide orig content and alternative
... also additional info can be provided within DOM

Lisa: we do have a simplified example in the content module
... in current discussion author doesn’t just give more information but provides an alternative content

<LisaSeemanKestenbaum> https://w3c.github.io/personalization-semantics/help/index.html#alternative-explanation

Lisa: propose next step: make a new draft starting off with the vocabulary of the different types - implementing via the DOM and via alternatives

<MichaelC> MC: I´m hearing we have at least 2 types of properties - ones that say ¨this is a X¨ and others that say ¨this is the X version of Y, or the Y version of X can be found at Z¨. They are ¨type¨ and ¨references¨ types of vocabulary terms. For the references ones, we know implementation will be a bit more complicated, but I hope can find a consistent way to do it. So let´s just put properties in the proper bucket and then refine

<MichaelC> them, and circle back on the ¨how should references type terms be implemented¨ question.

Lisa: include how to implement via large sections of text; also include via shortcuts to implement via inline replacements the author can provide

<Thaddeus> yes

JF: yes working on vocabulary makes sense; we may want to coordinate with web platform group and possibly get more attributes defined but wants vocabulary solid first is key

Lisa: keep the current implementation proposals but characterize some as shortcuts but note that these may be removed - they are here for dicussion only
... Include a note that some of these examples may be removed - that way we don’t lose any current information

<LisaSeemanKestenbaum> start with vocablery

Michael: not sure we need a note on each section since this is an editors draft

<LisaSeemanKestenbaum> then implementing

<LisaSeemanKestenbaum> then a section on proposed shortcuts

Michael: agrees on working Vocabulary and don’t want to distract from that

Lisa: put all of these shortcut examples into their own section

Michael: what is meant by shortcuts?

Lisa: these are the inline implementations - the ones that look like alt text

Michael: sounds like we are looking at attributes - lets call them that

Sam: Is there any doc that goes further with use cases and how User agents might use this metadata?

<LisaSeemanKestenbaum> https://github.com/w3c/personalization-semantics/wiki/Getting-started-with-personalization-semantics

<sgoto> that would be great, thanks

Sam: Michael mentioned microdata and RDFa - is there a document about how alternatives have been considered/analyzed

Lisa: would be interested to know if link above is helpful?
... willing to provide an orientation call for people if wanted

<JF> +1 to Michael

Michael: more use cases and implementation is somethine we should be doing in the explainer; then we don’t have to orient each person separately

<sgoto> anyone has the github issue handy with pros/cons of alternatives considereds?

<JF> +1 to Lisa

<LisaSeemanKestenbaum> ACTION: make a new wiki page for considerations

Lisa: agree is important to document considerations, common definitions, etc

<MichaelC> Does personalization semantics work as an ARIA module?

JF: some of use cases and research done as part of COGA task force should be resurfaced

<JF> act me

<LisaSeemanKestenbaum> ACTION: mickael make a new wiki page for considerations

<sgoto> that sounds awesome Michael

Michael: will take the action to create an page to document alternative proposals / implementations

<MichaelC> First Public Working Draft of Personalization Semantics

Michael: and document the decisions we made (and discussed related to)
... don’t want to dive too deep into history since it exists in minutes but focus on going forward

Lisa: Need to find someone to make this version of the doc separated into two sections

<Thaddeus> isnt that within the context of tools and help documents?

Becky: restructure document first or work on vocabulary first?

Lisa: section on use cases; section on vocabulary; section on implementations

<JF> +1 to a) Use Cases, b) Vocabulary, c) implementations

Becky: I can look at the vocabulary but need resources from COGA

<MichaelC> Placeholder page for metadata comparison

Thaddeous: can we do the same reorganizatin for the tools

<JF> trackbot, end meeting

<JF> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: clapierre, Thaddeus, Becka11y, JF, Roy_, MichaelC, sgoto, Sharon, present, LisaSeemanKestenbaum
Present: clapierre Thaddeus Becka11y JF Roy_ MichaelC sgoto Sharon present LisaSeemanKestenbaum
Found Scribe: Becka11y
Inferring ScribeNick: Becka11y
Found Scribe: becka11y
Inferring ScribeNick: Becka11y

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: make mickael

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)