Re: Sending Docs to Rec?

Hmmm...one obvious solution is to table this discussion till after we
get the GRDDL Spec to Last Call. However, I am still interested in
hearing people's opinions on the issue. However, I am at this current
moment even more concerned about getting GRDDL Spec Review...


Chimezie Ogbuji wrote:
>
> On Thu, 22 Feb 2007, McBride, Brian wrote:
>> Harry,
>>
>> As best I can understand it, your argument is:
>>
>> 1. there are different audiences for the different docs
>
> I agree with this point, and is my primary concern with a scenario
> where only the specification is the most prominent document that both
> implementors, authors, and people with general interest read.
>
>> 2. we have show that we take each audience seriously
>
> I personally, couldn't imagine a scenario where a person with just an
> introductory understanding of RDF had to contend with the
> specification and I don't think it is reasonable to expect that the
> specification serves all of these audiences.
>
>> 3. ergo each document should be rec track.
>
>> I don't see taking a document rec track as some sort of certificate of
>> seriousness.  It may be a certificate of stability and of consensus (so
>> its worth implementing the spec).
>
> This is the *real* problem, in my mind.  We don't seem to have a
> consistent (or even coherent) criteria for what rec track means with
> regards to the documents we decide to take that route.  Dan suggested
> (in the last telecon) that the criteria is completely up to the WG, so
> I think rather than try to decide which documents we take down the REC
> track (without any consensus on what it means for *us* to do so) we
> should ask instead what REC track means for GRDDL.  To me, it is
> twofold: coherent functional requirements and a coherent set of
> literature for introductory and intermediate-level audiencess.  The
> two are mutually exclusive and therefore one document will simply not
> do both.
>
> If functional requirements (unambigous engineering details) is the
> only criteria then the documents we should be aiming for REC track
> should be the specification and the test cases.  Now, IMHO, the test
> cases are nowhere
> near coherent in their coverage of the functional requirements we have
> consensus on so far and it is *still* unclear to me how we are
> handling situattions where we have multiple outputs from a single input.
>
> It seemed to me (niavely perhaps) that conformance labels spoke
> specifically to functional 'conformance' and not 'setting the tone in
> the market' as was suggested in the last teleconference.  If indeed we
> are using SHOULD / MUST / etc.. language to set the tone in the market
> then that is a stronger suggestion that our criteria is not functional
> requirements alone.
>
>> I speculate that what a CIO cares about is a) whether GRDDL will be good
>> for his organization b) that it is an open standard with
>> implementations.
>
> A CIO will *never* be able to determine a) from the specification alone.
>
>> A spec that is a rec takes care of b.
>> The primer explains what it does
>> so takes care of a - whether or not it's a rec.
>
> Actually, I think the question of a) is answered by *both* the usecase
> document and the primer.  We could decide to take only the spec to a
> REC (on the grounds that functional requirements are our only
> immediate interest).  However, if as a result of this the primer and
> the usecase document don't get the exposure for review they need that
> would only put them at risk for being able to answer a) for a CIO.
>
> The time restrictions (which I think are unfortunately short) seem to
> make functional requirements the only feasible criteria for REC track
> and so unless our time constraints are relieved a bit, we really have
> no choice but to take only the specification down the REC track - but
> we should at least be aware that it puts us at risk for readability
> for the intermediate audience (which will comprise the majority of our
> audience)
>
>> Brian
>>
>>
>
> Chimezie Ogbuji
> Lead Systems Analyst
> Thoracic and Cardiovascular Surgery
> Cleveland Clinic Foundation
> 9500 Euclid Avenue/ W26
> Cleveland, Ohio 44195
> Office: (216)444-8593
> ogbujic@ccf.org
>


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Saturday, 24 February 2007 23:18:13 UTC