Note on Formal Objections (was Re: Motivation as Property or Value)

Thanks for the useful summary Doug. Here is some more information for members of the group:

We should be clear that from a process perspective there is a difference in formally raising an objection and commenting on the list, being silent or walking away. 

Raising a 'formal objection' is a specific statement that is recorded and then requires review later in the process.

Thus we need to be very clear on this in our voting (should we do that) and minutes.

see http://www.w3.org/2015/Process-20150901/#WGArchiveMinorityViews

[[

3.3.2 Recording and Reporting Formal Objections

In the W3C process, an individual may register a Formal Objection to a decision. A Formal Objection to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g., in response to a request to advance a technical report). Note: In this document, the term "Formal Objection" is used to emphasize this process implication: Formal Objections receive Director consideration. The word "objection" used alone has ordinary English connotations.

An individual who registers a Formal Objection should cite technical arguments and propose changes that would remove the Formal Objection; these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments or rationale are unlikely to receive serious consideration by the Director.

A record of each Formal Objection must be publicly available. A Call for Review (of a document) to the Advisory Committee must identify any Formal Objections.

]]

Note also on voting, see http://www.w3.org/2015/Process-20150901/#Votes

[[

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock. In this case the Chair must record (e.g., in the minutes of the meeting or in an archived email message):

 • an explanation of the issue being voted on;
 • the decision to conduct a vote (e.g., a simple majority vote) to resolve the issue;
 • the outcome of the vote;
 • any Formal Objections.
In order to vote to resolve a substantive issue, an individual must be a group participant. Each organization represented in the group must have at most one vote, even when the organization is represented by several participants in the group (including Invited Experts). For the purposes of voting:

 • A Member or group of related Members is considered a single organization.
 • The Team is considered an organization.
Unless the charter states otherwise, Invited Experts may vote.

]]

Thus the group can agree we have consensus and move on, some might not like it 'but can live with it'. Otherwise we may need a vote and some may need to decide whether to raise a formal objection (or not).

regards, Frederick

Frederick Hirsch
Co-Chair, W3C Web Annotation WG

www.fjhirsch.com
@fjhirsch

> On Aug 30, 2015, at 5:45 AM, Doug Schepers <schepers@w3.org> wrote:
> 
> Hi, folks–
> 
> Someone mentioned to me offlist that it seemed like I was trying to disrupt consensus in this latest thread, so I wanted to be perfectly clear in my intent.
> 
> Personally, I can live with the change to the data model that Rob is proposing; while it differs in some areas to what I'd actually proposed as a compromise, I feel that it is simple and usable enough that it's good enough.
> 
> I think we should integrate these changes into the data model spec, and publish an updated draft right away. I suspect that we are pretty close to a general data model that could be adopted widely (or at the very least, one we could credibly shop around to major vendors).
> 
> I truly appreciate all the effort from everyone in bringing us to this point.
> 
> 
> All of that said, as Tim has noted, there was an outstanding concern that an annotation implementer (OpenGov Foundation) brought forward, and from a short off-list discussion with them after last week's telcon, I found out that the compromise solution I proposed, and the final version that Rob solidified, was not acceptable to them, and that as a consequence, they were unlikely to adopt the data model.
> 
> This is a big deal to me! First, it means that we don't have consensus in the working group (and I don't mean the pie-in-the-sky "unanimity" consensus, but the more pragmatic "I-can-live-with-it" consensus that W3C practices); second, if OpenGov Foundation can at all be looked upon as representative of an implementer who is not using the RDF/Linked-Data stack (and I'm not claiming that they are representative, only that they may be), then their aversion to this aspect of the data model might be a canary in a coalmine.
> 
> However, in a separate off-list conversation, Benjamin suggested to me that he had a point of view that might convince OpenGov Foundation that this formulation data model is actually acceptable; when he explained it to me, I came away fairly convinced.
> 
> My goal here is to air these different points of view on an archived public forum, rather than in ephemeral off-list discussions that are only passed around as rumor. If we can provide a calm and reasoned rationale, on this list, for why this data model is not only good enough, but indeed why it might be better than Bill's model, then people who later ask us to defend our technical decisions (and if we're lucky, we will be questioned on them, because it will then mean that someone outside our small group is paying attention), we can provide not only an answer that satisfies the RDF/Linked-Data folks, but also the people who avoid RDF/Linked-Data.
> 
> 
> Rob made a Call for Consensus. This is not simply a pro-forma request for +1s, but is the time to drive toward consensus (which we currently don't have) through conversation, until 1 September, when the CfC ends.
> 
> I honestly believe that we can get consensus here. If we don't… well, that will be unfortunate, but fortunately, we have a path forward though the W3C Process [1]:
> 
> [[
> 3.3.1 Managing Dissent
> 
> In some cases, even after careful consideration of all points of view, a group might find itself unable to reach consensus. The Chair MAY record a decision where there is dissent (i.e., there is at least one Formal Objection) so that the group may make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot stop a group's work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group SHOULD move on.
> 
> Groups SHOULD favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people. As part of making a decision where there is dissent, the Chair is expected to be aware of which participants work for the same (or related) Member organizations and weigh their input accordingly.
> ]]
> 
> 
> My understanding is that Chris (and through him, Bill) are the only ones who've said they can't live with this solution (and they've done so graciously, saying they won't block the group moving forward). Again, I'm not blocking it, and I'm even in favor (albeit with some reservations) of the new proposed model.
> 
> So, my suggestion is that let the conversation play out until the end of the CfC, and unless we get other serious objections, we should integrate the new proposal into the Data Model spec, and publish an updated draft.
> 
> 
> [1] http://www.w3.org/2014/Process-20140801/#Consensus
> 
> Regards–
> –Doug
> 
> On 8/28/15 10:03 PM, Robert Sanderson wrote:
>> Hi Bill,
>> 
>> Thanks for your input into the discussion!
>> 
>> On Fri, Aug 28, 2015 at 5:33 PM, Bill Hunt <bill@opengovfoundation.org
>> <mailto:bill@opengovfoundation.org>> wrote:
>> 
>>    I understand that the consensus is that my suggestion wouldn't work
>>    because you'd have to define every role as it would appear - which
>>    is hard since we can't predict everything anyone would ever want to
>>    do.  My argument was that 99% of roles could be defined in a very
>>    narrow set of a half dozen or so; anyone who's doing something else
>>    or wants to create a new role wouldn't be handled by a "standard"
>>    consumer so they'd be off the map anyway.
>> 
>> 
>> I think that, happily, we can easily put this to rest.
>> 
>> There are already a dozen motivations defined in the model [1], and your
>> use case did not fit into those 12, as there isn't a motivation that's
>> explicitly the text to replace target text with.  So in order to fulfill
>> your use case, you would be outside of the standard too.  The 12 were
>> already trimmed down from longer lists of motivations by looking across
>> many use cases and previous research in the OAC and OA-CG days.
>> 
>> In the IIIF use case, we had to define a new motivation (painting), and
>> that's likely insufficient and we'll need at least 3 further motivations
>> as narrower concepts of it to clarify expected client behavior
>> (transcribing, translating, editing [in the sense of creating a textual
>> edition of a work]) [2].
>> 
>> So, I hope that you can see that 99% of roles really won't fit into half
>> a dozen, and hence property-as-role really doesn't work for
>> interoperability without the significant overhead of RDF inferencing to
>> determine how they relate to hasBody or hasTarget.
>> 
>> Thanks,
>> 
>> Rob
>> 
>> [1] http://www.w3.org/TR/annotation-model/#motivations
>> [2] http://iiif.io/api/presentation/2.0/#image-resources
>> 
>> 
>> 
>> 
>> 
>> --
>> Rob Sanderson
>> Information Standards Advocate
>> Digital Library Systems and Services
>> Stanford, CA 94305
>

Received on Tuesday, 1 September 2015 23:59:51 UTC