Re: Proposal for personalization semantics as vocabulary

Very well said Michael and I agree with everything you have said.
Lets use the KISS mantra here and keep it SIMPLE!
I agree Logs are important but can be done with name-value pair although verification could be an issue but as you said that is a nice to have and I agree with you there.

Thanks
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org<mailto:charlesl@benetech.org>
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301



On Oct 10, 2017, at 9:50 AM, 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