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

Thanks, Frederick. It's always good to remind (or inform) people about 
W3C's Process for resolving issues and running WGs.

So far as I can tell, there haven't been (and are not likely to be) any 
Formal Objections to this proposal.

That's not to say we can't revisit any issue if there is new evidence, 
but it's useful to make a decision and move on.

As a side note on Formal Objections from W3C as an organization, we try 
to exercise extreme oversight into our Formal Objections; a Staff 
Contact cannot raise a Formal Objection without the approval of at least 
their Domain Lead, and often the Director (or someone whom the Director, 
TimBL, designates); this only happens in extreme cases (though I've seen 
Staff Contacts bluster about making Formal Objections from time to time :D).

For example, not that I'd be anywhere close to a Formal Objection on 
anything that's been discussed in this WG, but even if I were, I'd 
probably have to convince Ivan as my Fellow Staff Contact, and our 
Domain Leader, and very likely TimBL or his designate.

This is part of our check-and-balance system, and it's a good rule! As 
the ones most tasked with enforcing W3C Process (in conjunction with the 
Chairs), including consensus and interpretations of the WG charter, 
we're held to a higher burden of proof on using the Process to stop 


On 9/1/15 7:59 PM, Frederick Hirsch wrote:
> 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
> [[
> 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
> [[
> 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
> @fjhirsch
>> On Aug 30, 2015, at 5:45 AM, Doug Schepers <>
>> 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]
>> 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
>>> < <>>
>>> 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] [2]
>>> -- Rob Sanderson Information Standards Advocate Digital Library
>>> Systems and Services Stanford, CA 94305

Received on Wednesday, 2 September 2015 01:39:26 UTC