Re: [SKOS] Review of SKOS Use Cases and Requirements

Hi all,

Sorry for missing the call this morning - my voice is still nonexistant, 
but I want to share that I think most, if not all, of the concerns I had 
with the original draft of the use cases and requirements have been 
addressed in the latest editors draft.  The current version [1] 
represents quite an improvement over the prior version, and clearly a 
lot of work went into it.

Thanks,

Elisa

[1] 
http://www.w3.org/2006/07/SWD/wiki/UCRMaterial?action=AttachFile&do=get&target=ucr-20070417.html


Antoine Isaac wrote:

> Hi Sean and Elisa,
>
> Thank you very much for the comments! I've quickly read them, and all 
> the points you raise seem more than apropriate.
> I suppose we'll come back to you when we try to address them, 
> hopefully in the coming days.
>
> Cheers,
>
> Antoine
>
>
>> All,
>>
>> Sorry for the delay in getting this out.  I'm in a meeting at the OMG 
>> technical meeting in San Diego, and was just able to get the wireless 
>> to work.
>>
>> Overall -- I agree substantially with Sean's comments.  There appears 
>> to be  some inconsistency in the level of detail across use cases.  
>> This may be because of inconsistencies in the submitted use cases, 
>> but could possibly be allieviated by introducing a bit more structure 
>> across use cases, e.g.,
>> Summary, Required SKOS Features, Detailed Description, Link(s) to 
>> Complete Use Case Submission, and consistent subheadings if used.  
>> This is there informally, but providing the same headings for each 
>> use case, and collecting required elements in one place for each 
>> might make this easier to read.
>> I think it would be useful to provide comments on the vocabulary 
>> maintenance /methodology/ in all cases (if known) as well (of course, 
>> I'm biased, but it's there in a number of cases), but for example, 
>> I'm not sure that maintenance in Protege is what I mean by this. If 
>> we know it, information regarding the methodology would be useful for 
>> readers (i.e., organization and process related insights), even if 
>> it's a short sentence, again consistently across use cases. The same 
>> is true for information regarding the size and coverage scope for 
>> each.  These could be managed in consistent subheadings under 
>> detailed description.
>>
>> Introduction - this section could do with another detailed editing 
>> pass, but provides a decent introduction to the document itself.
>> Use case 2.4 - I agree that this one is a bit muddy, and 2.6 might 
>> not need all of the examples; some of the detail captured in 
>> subheadings could simply be bulletized.  I also agree with Sean on 
>> 2.7 -- I'm not sure that all of the detail on metadata and 
>> relationships among terms used are needed, but one or two additional 
>> summary motivation sentences would help.
>>
>> Other use cases should be under a separate heading, perhaps 
>> clustered/categorized to a degree if possible.
>>
>> Numbering over sections also needs to be fixed (at least in the 
>> emailed version I have from Antoine), and additional structure in the 
>> requirements section, clustering of requirements, etc. would be 
>> helpful for readability.
>>
>> Also, some kind of concluding paragraph regarding summary of 
>> findings, next steps, etc. would help balance the document.
>>
>> Best regards,
>>
>> Elisa
>
>
>
>
>
>

Received on Tuesday, 24 April 2007 15:06:08 UTC