[SKOS] Review of SKOS Use Cases and Requirements

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