Re: Requirements feedback

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.

> I'm unclear what I'm to look at, in general. I current watch:
>     http://www.w3.org/2007/OWL/wiki/RequirementsDraft
> which seems to get updated in the wiki.
That's the right place.

>
> 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.  The idea behind the structure of the document
is to start with user perspectives and map these into the language as 
designed.  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. 

>
> I (still) favor a very lightweight document. I would put a strong 
> length requirement on this document and a similar complexity one. Its' 
> currently at about 29 papes when I PDF it. If I cut out section 4, we 
> are only 4 pages shorter. Section 5 is 11 pages, but I think is nicer 
> (and it is, after all, my originally proposed organization). It seems 
> to me that something like 5 stands on its own and could easily be the 
> whole document. I don't see the need for the use case section at all 
> nor for the Users and Applications. In fact, they seem very very 
> confusing.
>
> I don't like the term "Motivating use cases" because that suggests a 
> causal history which just might not be there. If we keep that, I would 
> suggest "Applicable to:" or something like that.
>
> I think that that link isn't helpful though because it's not at all 
> clear what features really are applicable or how. We can't possibly 
> add enough text to make the connections clear and I think the 
> examples, esp. if they vary subject matter, do very well to convey the 
> sense. (That is, instead of laying out a range of uses explicitly, 
> just let the examples (ONE PER FEATURE) lay out the range of uses 
> *implicitly*.)
>
> 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.  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.  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.   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.

>
> Cheers,
> Bijan.

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