Re: Requirements feedback

Hi,

I agree with most of Bijan's points, and talked with Christine on  
possible ways to achieve a shorter, more concise requirements document.

Sections 2 and 3 could be either appendices or separate. We think that  
sections 4 and 5 can be integrated in a straightforward manner as  
follows:

We use the current structural content of section 5 to describe both  
the requirements and features in one integrated structure (i.e. we  
simply remove the 'F#' bit from the titles of all subsections). Each  
subsection will give the requirement, followed by links to motivating  
use cases, and the description of the feature that was added to meet  
the requirement, and its grammar. We then have the theoretical and  
implementation aspects, followed by one or more concise examples. The  
examples can be shortened significantly, by copying the explanations  
of axioms to the right-hand column of the example block (what's now  
there can be removed as it does not really add more information).

I've put an example of a requirement description online at [1].

The tables that map requirements/features to use cases give a nice  
overview.

Although it is tedious and boring work, the proposed changes are  
purely editorial. No information is needs to be added, nor do we  
(necessarily) lose any.

- Rinke

[1] http://www.w3.org/2007/OWL/wiki/AlternativeOrganizationProposalReqDraft


On 20 okt 2008, at 21:39, Bijan Parsia wrote:

>
> 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.
>

-----------------------------------------------
Drs. Rinke Hoekstra

Email: hoekstra@uva.nl    Skype:  rinkehoekstra
Phone: +31-20-5253499     Fax:   +31-20-5253495
Web:   http://www.leibnizcenter.org/users/rinke

Leibniz Center for Law,          Faculty of Law
University of Amsterdam,            PO Box 1030
1000 BA  Amsterdam,             The Netherlands
-----------------------------------------------

Received on Friday, 24 October 2008 10:38:35 UTC