Re: Requirements feedback

On 20 Oct 2008, at 20:18, Evan Wallace wrote:

>
> Christine is the main driving force behind the Requirements  
> document currently,
> but I believe that she is currently completely absorbed with other  
> activities at
> TPAC.  For now, let me provide a few of my thoughts on your comments.

Thanks.

[snip]
>> I've not done a detailed review, nor am I clear what state of flux  
>> the document is in (sections 4 and 5 seem to be alternative  
>> organizations). But I thought I'd just remind folks of my general  
>> position wrt this document so we don't get surprised later.
> 4 and 5 have different organizations because they are meant to  
> match different viewpoints.

Ok, they aren't different approaches y'all are evaluating, but meant  
to both show up in the end product. I'm pretty sure I oppose that.

> The idea behind the structure of the document
> is to start with user perspectives and map these into the language  
> as designed.

That seems helpful during document development, but not so great in  
an end product.

>   Section 2 is meant to describe some typical classes of
> users.  The Use Cases section describes how these user classes make  
> use of the language.  Section 4 highlights requirements that fall  
> out of
> these use cases.  Finally, the Features and Rationale section  
> describes how these requirements were addressed and is intended to  
> provide
> an explanation for limitations in the features that may be  
> surprising and frustrating to users.

The last goal seems valuable; the other parts not so much.

If one tries for too much in one document, I think you'll lose everyone.
[snip]
>> I think section 5, by itself, would make a very nice and readable  
>> document and would serve as a good model for future groups. I  
>> think the other material is interesting but too much for this  
>> document. I'd suggest migrating it over to OWLED. It'd really be  
>> better as a database of some sort with heavy cross references and  
>> ongoing maintenance.
>
> Personally, I also think that the document is quite large.  We have  
> been trying to slim each section down to address this, but such an  
> approach
> is hard-going.

Yeah, I don't think trimming *each* bit will make it flow better.  
Hence my preference for going primarily with 5.

> A different organization could provide some benefits: maybe  
> allowing some reduction in material, better impact, and moving
> the core (the requirements) more upfront.  I think we could lose  
> section 2, but 4 is key.

Ok, lemme look at 4 again.

Er...it doesn't seem to be a list of requirements but a list of  
features. And it seems terser than 5 but less informative. What's the  
rationale for 4 *and* 5.

> Some have argued that material such as in the use cases
> is a valuable resource for folks who are working with OWL to use to  
> to help justify their organization's investment in OWL 2.

I need some evidence for that. I've never experienced that, esp. as  
these are use cases and not case studies. Use cases like this just  
are artifical.

>   Maybe it doesn't
> need to be in this document.  If it stays in this document, I think  
> moving it after the core material makes sense.

I think the SWEO approach is likely to be better:
	http://www.w3.org/2001/sw/sweo/public/UseCases/

Also, I think use cases and case studies, to be useful for  
justification, need to be up to date. Thus it could be  
counterproductive to include them in a static document. Far better to  
get public-owl-dev or OWLED behind them. Hence I think even more  
strongly that they should be dropped.

Thanks for the insight.
Cheers,
Bijan.

Received on Monday, 20 October 2008 19:36:20 UTC