Re: Proposal for personalization semantics as vocabulary

On 16/10/2017 10:54 AM, lisa.seeman wrote:
> I added some comments inline, but my main issue was with logs.  Logs 
> become much more complex. Logs needs to be a combination of role or 
> tag name and stucture within the DOM. It can be done as a vocablary 
> but it becomes out of the skill set of most web designers.
> With regard to implemention some folks at IBM had told me they were 
> implementing it but I need to follow them up.
I still haven't seen a structure for logs as you seem to be suggesting. 
This is therefore hypothetical, and not sufficient to justify a 
structural limitation.

I've said in other messages that a vocabulary doesn't prohibit a 
structure, it just doesn't inherently support it. The ARIA module that 
is currently the FPWD also doesn't describe a structure, any more than a 
vocabulary would.

I've also said that we could provide a taxonomy beside the vocabulary, 
so they work together - one defines the terms, and one defines how the 
terms relate to each other. I'm not convinced we need a taxonomy, and 
the sole example of logs, where I haven't seen the intended taxonomy for 
that, doesn't convince me we need this especially in the 1.0 timeframe. 
It's always something we could add later, so I don't see vocabulary as 
preventing future work.
>
> So my main question is - can we do a mix?
I think that would muddy the waters and eliminate the value of doing a 
vocabulary. The idea of vocabulary and taxonomy as siblings rather than 
a mix works better IMO.

The main reason I want to focus on a vocabulary for now is to force us 
to think in terms of features, rather than the vagaries of a specific 
technology implementation which likely would cause us to lose sight of 
the features. I think that is really important as personalization is a 
big new concept and keeping it as general-purpose as possible seems best.

A close second reason I want to focus on vocabulary is we can easily map 
a vocabulary to multiple implementations. There's been lots of talk in 
AG WG about how personalization could be done by RDFa or HTML Microdata 
in addition to personalization semantics. But there would be no defined 
way to do personalization in those other metadata languages, and that 
would lead to fragmented implementation if any. By doing a vocabulary, 
we can clearly support all three metadata languages, RDFa, Microdata, 
and ARIA, and others if we choose.
>
> Also I am not sure about how the proposed attributes would work with 
> ARIA. this seems like a coordination issue.
> We do not want to delay getting uptake of attributes in ARIA because 
> we are making a vocabulary.
In the proposal, there is an appendix that defines how the vocabulary 
would map to ARIA. I expect we would expand that to define a full ARIA 
module. The key difference in the proposal is the ARIA module depends on 
the vocabulary, rather than the vocabulary depending on the ARIA module. 
I don't expect any timeline or coordination differences from what we 
were already going to do on that front.

Michael
>
>
>
>
> ---- On Tue, 10 Oct 2017 20:59:24 +0300 *Michael Cooper 
> <cooper@w3.org>* wrote ----
>
>     The point of my message was to ask for evidence on the questions
>     you raise. If you have evidence, please provide it. Absent that, I
>     don't think we should hold open a decision that slows us up or
>     creates more complexity than we need. More specifically:
>
>
>     On 10/10/2017 1:36 PM, lisa.seeman wrote:
>
>         Hi
>
>         It is more then limiting to future work. Questions include:
>
>           * does it limit current work including things that are in
>             the specification and may even have people working on
>             implementations?
>
>     I don't know, does it? In my message I said I think the answer is
>     no. If you think the opposite, please describe specifically how. I
>     tried to address all your concerns that I know about.
>
>     Lisa:  logs becomes more complex. Logs needs to be a combination
>     of role or tag name and stucture within the DOM. It can be done as
>     a voablery but it becomes out of the skill set of most web
>     designers. SOmeone at IBM had told me they were implementing it
>     but I need to follow them up.
>
>           * does it make some things more complicated?
>
>     I don't know, does it? I think no, and explained why. If you think
>     it does, please say how.
>     LS: as above
>
>           * can we do a mix, where some items are a vocabulary and
>             some items are not? (We would only use this option if it
>             becomes useful.)
>
>     I think that would increase the complexity - and reduce the number
>     of likely implementations and slow the timeline - even more than I
>     was worried about before. Can you say what a mix would look like
>     and what problems it would solve that we don't currently have
>     solutions for?
>
>     LS: Logs could be a mix. Idealy it should be an aria role and new
>     attributes.
>
>
>          Alough some things might seem more simple, other
>         items  become more complex, such as logs and some of the
>         alternate version attributes. This is even more removed from
>         the path of simplifying log and step by proposing to  make
>         "log" and "step" roles values.
>
>     I need more details about these use cases. The only one I had
>     heard from you is log, and I addressed what I knew about it in my
>     message. If you have explicit use cases, we need to see them to
>     discuss them.
>
>
>         Some people may also find the aria implementation more complex
>         as a vocabulary.
>
>     Who, and in what way? Please draw those people into the discussion
>     so they can explain the issue. I didn't cover this in my message,
>     but in the call yesterday explained that I think the
>     implementation is no harder as a vocabulary because we would
>     provide mappings to ARIA, RDFa, and Microdata, and I said that
>     because of that we could have interoperability of a greater number
>     of approaches than just the one if it's structured as an ARIA module.
>
>
>         i am not saying no but maybe we should gather data on the
>         questions above before we decide.
>
>     That was the reason I sent my message. I was expecting you to
>     respond to the points I raised, and I tried to structure it in a
>     way to make it easy to respond to them one by one.
>
>     I'm concerned that simply saying we need more data, but not
>     providing the data or even verifying that it exists, will slow
>     down the work too much. I'm not saying we need to make a decision
>     today, I want to make sure any concerns are evaluated, but we need
>     to move forward at some point reasonably soon. If you have
>     concerns about that, we need specifics.
>
>     Michael
>
>
>         All the best
>
>         Lisa Seeman
>
>         LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
>         <https://twitter.com/SeemanLisa>
>
>
>
>
>         ---- On Tue, 10 Oct 2017 19:50:07 +0300 *Michael
>         Cooper<cooper@w3.org> <mailto:cooper@w3.org>* wrote ----
>
>             >From yesterday's discussion
>             <https://www.w3.org/2017/10/09-personalization-minutes.html#item06>
>             of this proposal, I gathered that the restructuring
>             overall was received favorably, but concern was raised
>             that expressing personalization semantics as a name-value
>             pair vocabulary would be limiting to future work. Here are
>             some thoughts to see if they help draw out discussion.
>
>             First, the personalization semantics as currently proposed
>             *is* a set of name-value pairs, there are no features
>             proposed that do not use that model. So it seemed to me
>             proposing it as a generic name-value pair vocabulary was
>             an obvious transformation.
>
>             I haven't seen a proposal for future work that would not
>             work as name-value pairs, so keeping the door open for an
>             unknown complex future at the cost of simplicity and
>             achievability today doesn't seem useful.
>
>             Lisa raised the example of logs, which use several
>             properties together - which is not on its own a problem
>             for the name-value pair vocabulary model. Lisa said that
>             logs might put these properties on different nested
>             elements and require more taxonomic structure. However, in
>             the log usage examples
>             <https://www.w3.org/TR/personalization-semantics-1.0/#log-usage-examples>
>             I only see one example where the properties are used on
>             nested elements, and in that third example the nested
>             <div>  doesn't do anything that shows there must be a
>             nested div, where it wouldn't work by putting both
>             properties on the parent div. So at the moment I don't see
>             convincing evidence that taxonomic nesting is required for
>             use of the personalization semantics.
>
>             A name-value pair taxonomy doesn't *prevent* authors from
>             using sets of related properties on nested elements, it
>             simply doesn't provide intrinsic *validation* that any
>             structure rules have been followed at authoring time. The
>             current version of the semantics also doesn't provide any
>             such validation. I think such validation is "nice-to-have"
>             and not essential.
>
>             Allowing sets of related properties to be used together on
>             different elements inherently makes implementation more
>             complex. It means for properties where this might happen,
>             implementations have to check the entire subtree just in
>             case other properties were provided, often only to find
>             nothing after all. Implementers will complain about extra
>             processing cycles, and I think simple implementations will
>             simply declare that kind of work out of scope. I
>             understood that a major implementation target, at least
>             initially, would be things like greasemonkey scripts or
>             simple browser add-ons, and I think requiring property
>             nesting support will rule most of those implementations out.
>
>             If taxonomic nesting is a critical part of
>             personalization, or is expected to be in the future, we
>             should consider what technology is the appropriate target
>             to address that. It gets closer to defining element types
>             with their attribute and content models, which should be
>             done in host languages. I don't think maintainers of
>             languages like HTML or SVG will welcome yet another set of
>             add-on semantics, and I don't think we have determined
>             that ARIA wants to take that on either. So if we have use
>             cases for that, we might be better served coordinating
>             with other groups rather than making a more complicated
>             and aspirational spec ourselves.
>
>             If in spite of all the above the group does conclude - and
>             gets support from its sponsoring ARIA WG in the conclusion
>             - that taxonomic nesting is a requirement, then we should
>             structure personalization semantics as a taxonomy rather
>             than a vocabulary. However, I see no evidence that that is
>             on the table for 1.0, even if it remains on the table for
>             future versions. Therefore I think we should still do 1.0
>             as a taxonomy, and do it differently in the next version
>             if needed - perhaps with renaming as a separate technology
>             to avoid confusion if that is critical. Alternately, we
>             could define the vocabulary, and a taxonomy of the
>             vocabulary terms, in separate places so we can have both a
>             simple vocabulary and a more involved taxonomy for more
>             involved implementations.
>
>             A primary reason I've seen for us to work on
>             personalization semantics, though, is to get the concept
>             of personalization "out there" in a lightweight manner so
>             we could get rapid in-the-wild implementation to
>             demonstrate usefulness. Defining a standardized vocabulary
>             will help with interoperability of work that might
>             otherwise happen in a fragemented manner, but it will
>             still be seen as a "bolt-on" technology. I was expecting
>             that we would later focus on building the concepts more
>             directly into the web platform once we have demonstrated
>             achievability and usefulness. Overcomplicating the current
>             version in favor of a future version we might not create
>             doesn't help with this goal.
>
>             I tried to break my thoughts up into paragraphs so people
>             can respond to individual points. I'd like to see if there
>             is additional data informing why a vocabulary is
>             insufficient at this time, and if so clarify our
>             requirements and scope. Otherwise I think we should follow
>             a simplest-is-best approach, particularly for version 1.0.
>
>             Michael
>
>
>             On 09/10/2017 12:44 PM, Michael Cooper wrote:
>
>                 I have put together a hasty proposal for how the
>                 personalization semantics would look like as a vocabulary:
>
>                 https://rawgit.com/w3c/personalization-semantics/vocabulary-proposal/semantics.html
>
>                 You may need to refresh once or twice to get the
>                 script to format the table of contents etc.
>
>                 Basically what I've done is:
>
>                   * Move all the properties to a section called "List
>                     of properties
>                     <https://rawgit.com/w3c/personalization-semantics/vocabulary-proposal/semantics.html#list-of-properties>";
>                   * Remove the "coga-" prefix from property names;
>                   * Renamed the section "Semantic Properties" to
>                     "Personalization Use Cases", so it focuses on the
>                     issues we want to address, and then at the end of
>                     each sub-section points to the individual
>                     properties that relate to those use cases - down
>                     the road we might even see fit to move this
>                     section into a separate use cases document;
>                   * Added an appendix "Vocabulary Implementations
>                     <https://rawgit.com/w3c/personalization-semantics/vocabulary-proposal/semantics.html#vocabulary-implementations>"
>                     that describes how items in this vocabulary could
>                     be used in RDFa, ARIA, and HTML Microdata (very
>                     hasty / sketchy for now) - we could add more
>                     formats as they occur to us.
>
>                 Most of the work on the spec would still happen in the
>                 List of properties section, and nothing is really
>                 substantively different. The value of this is that it
>                 more clearly indicates how the properties can apply to
>                 different technologies, separates the properties from
>                 their use case rationale, and gets rid of those pesky
>                 coga- prefixes in their names.
>
>                 Michael
>
>
>
>
>
>
>