Re: Review of the structure of the requirements draft

Hi Christine,

The document I reviewed was linked from the UFDTF task force page as 
frozen for review, so I assumed that was the version I should be looking 
at.  You might want to correct the link, and I'll be happy to take 
another look.  I should be able to get additional feedback to you by 
next week.

Elisa

Christine Golbreich wrote:

>Hi Elisa
>
>Thank you very much for your review.
>
>>From your comments, I'm afraid that you unfortunately reviewed an
>obsolete document that was 3 months old :-(
>Hopefully several of your comments, mainly regarding the structure of
>sections 2 - 3 - 4, have already been addressed in the current version
>available (since August) at [1], which structure was agreed at the
>last TC (1st oct) by the WG. Also, the present document does not
>exhibit anymore the previous redundancies that you noticed. So I hope
>that the present structure agrees you.
>  
>
>Regarding your comment about a repeated pattern : it is exactly what
>is underlying the current document organization as well. However,
>considering your comment, I have now moved the explanation that was
>given at the beginning of the UC section to the top of the document in
>the Overview section, in case it was not yet clear enough. Please have
>a look.
>
>I also tried to better explain in the Overview why there are Theory
>and Implementation perspectives in the Features and *Rationale*
>section, as initially suggested by different members of the UFDTF. In
>short, requirements were motivated not only by application but also by
>theoretical issues (that have been overcome) or implementations
>limitations met with OWL 1 by tools developpers. This may perhaps
>appear more clearly, once the TBD parts are completed (according to
>the ACTION decided at last TC).
>
>I agree your comment about the "narrative" of sections 2-3-4 and we
>plan to improve it very shortly.
>
>Regards
>
>Christine
>
>[ 1 ] http://www.w3.org/2007/OWL/wiki/RequirementsDraft
>
>
>
>2008/10/8 Elisa F. Kendall <ekendall@sandsoft.com>:
>  
>
>>Hi all,
>>
>>I committed to reviewing the structure of the requirements draft [1], and so
>>here are my thoughts based on several readings.
>>
>>I've essentially ignored the introductory section for the purposes of this
>>review and will "cut to the chase".
>>The use cases in section 2 are organized by (1) domain, and within domain,
>>by (2) a description of the applications they are designed to support, their
>>users and stake holders, and the use cases themselves. I've read through a
>>number of the sections, and found it to be a little slow going here and
>>there - this needs a thorough editing and spell checking pass for starters.
>>The spirit of breaking these down by application and stake holders is good,
>>though. Some of the descriptions need work, and the narrative could flow
>>better in some cases.  Presumably that will happen as folks have more time
>>to review / edit.
>>Under users and stake holders -- the content needs better agreement from the
>>domain to the description of users - for example, section 2.1.2.2 seems out
>>of place.
>>
>>The use cases themselves could stand some additional structure, either
>>underlining or additional bold heading, or something - each should describe
>>(1) the problem someone is attempting to solve, (2) the questions they hope
>>to answer, and (3) the requirement highlighted/raised.  Some of the use
>>cases do highlight the features they motivate, but the way this is done is
>>inconsistent.  Having a consistent structure that addresses each of these
>>points would be helpful.
>>
>>Most of the content under "Life Sciences" should be merged with the Health
>>Care examples, and similarly for the "Clinical Research and Clinical Trials"
>>domain -- perhaps one section with a Life Sciences and Health care heading
>>would make more sense.
>>
>>In section 3, we have use cases organized by requirements - I'm not sure
>>that it makes sense to repeat the use cases once we've already seen them.  I
>>would eliminate this section; it is particularly redundant in the sense that
>>what I want to see next is a summary from the requirements/new features
>>perspective -- which is given in section 4.
>>
>>Having said this, section 4 is fairly terse in some sections in terms of
>>describing each issue and the new feature that addresses it.  It would be
>>good to have a real example from one of the relevant use cases for each
>>requirement, showing what you can't do in OWL 1, then follow in the features
>>and rationale section with the solution using OWL 2.  Some of this is
>>already there in the features section, but the motivation is typically
>>missing from section 4.  I'd like to see more uniform treatment between
>>sections 4 and 5, and a repeated pattern -- requirement / problem example in
>>section 4, feature / problem solution in section 5, and again some visual
>>organizing cues to assist the reader in working through it.  I'm also not
>>sure that the theoretical perspective is needed in the features section --
>>depending on who we think the audience is for this document.  We go from
>>talking about electronic patient records at the start to the ever popular
>>SROIQ in the features section -- some uniformity in terms of depth is needed
>>here, along with the cues that tell the reader what the feature does for
>>them.  I'm also ambivalent about the implementation perspective - this
>>document should be more about requirements and the features that address
>>them, not so much about what tools support the resultant feature.
>>
>>I really like table 6.1, summarizing the use case, requirement, feature
>>needed, and so forth - this is very helpful.  Not sure we need tables 6.2
>>and 6.3, though I'm open to persuasion on this.
>>
>>I hope this is useful.
>>
>>Best regards,
>>
>>Elisa
>>
>>
>>    
>>
>
>
>
>  
>