Re: Proposal for personalization semantics as vocabulary

 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
>