Re: Publication proposal discussion summary

I found Bijan's summary helpful.

I think reasons 1-4 are good reasons for publishing semantics as FPWD
and reason 5 could go either way (cf G) ...

I wished to comment on B and H


[[
	B) People expressed the desire for more group review before
publishing anything. The consequential benefits haven't been clearly
enumerated to my ken.
]]

Jim argued this most effectively - this is the normal W3C WG process, 
and there is nothing so strange about this WG that we should behave 
differently.

As an example to do with the semantics doc. HP has a view that the n-ary 
datatypes design (which I guess is in that doc) is broken. We have 
stated this on a number of occassions. Currently that does not seem to 
be in an issue list, and until we have well-functioning WG issue list it 
probably won't be. As HP rep, I am happy with a doc that includes n-ary 
datatype design to be FPWD, but only if it is clear that the publication 
does not suggest that this is consensus design, ideally with a pointer 
to an issue list item, expressing HP's concern, and say including a 
pointer to our technical report concerning the design.
During a WG review I could agree text to that effect with the editor.
This presupposes that the WG is slightly more advanced in its internal 
processes than it is now.

off the top of my head, satisfactory text could be:

In the SOTD,

"This document does yet reflect a consensus of the OWL WG - a (currently 
non-exhaustive) list of issues concerning the design is found at 
**URL**, of which the following are particular pertinent:

    - N-ary datatypes -
    - ??? -
    - ??? -

Later versions of this document will change as WG consensus is reached.
"

I think the problem for me with the RDF Mapping, and perhaps for Elisa 
with the MOF, is that the issues (at least from the nay-sayers point of 
view) are so all embracing that the last sentence, which while stictly 
not invalidated with a total rewrite, would at least be confusing: the 
sort of document which we can imagine as a consensus doc would be too 
far away from the current doc, to be a respectable later version, as 
opposed to a different document.

Benefits of B:
   a) this is the normal process - deviating from normal process 
requires justification. Benefit: risk minimization.
   b) allows WG to influence doc before publication, so that public have 
a better feel for the WG position, rather than the member submission 
permission, which is already public
   c) adds to WG sense of ownership of document, which currently belongs 
to the members who made the submission

[[
H) I got another email stating that WDs should either reflect the
state of consensus or be clearly labeled as lacking that.
]]

I hadn't realised there was a proposal not to do this.
Certainly the expectation is that a WD published by a WG, while a 
work-in-progress, does reflect WG consensus unless labelled as not doing 
so; and even if labelled as not a consensus, a WD does reflect the most 
likely direction of progress.

Benefits of H:
  a) if a WD does not document any lack of consensus, then the readers 
are likely to assume a consensus
  b) any WG participants whose voice is not reflected at all in WD will 
feel marginalized and disempowered, undermining good WG process
  c) if a WD appears to include a complete design and no disagreement, 
then any reviewers of FPWD might (unrealistically) expect a LC in three 
months or less.

Jeremy

Received on Wednesday, 24 October 2007 14:58:12 UTC