- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 4 May 2004 10:35:33 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
From the May 4 telecon agenda: > 3. Use cases draft status > http://www.w3.org/2001/sw/DataAccess/UseCases > $Revision: 1.26 $ or better > > ACTION: AndyS, EricP to review kendallC draft by 4 May telcon I have read through v1.32 (I had already read v1.25 and sent Kendall minor wording changes). I have few comments on the document and think it is in very good shape. Some comments: = UC/Requirements relationahip = DanC contributed: [[[ A list of technical requirements has been extracted from the use cases, a list that describes the critical features a standard RDF query language and data access protocol should possess. ]]] to the introduction. We generated requirements (4.1-4.10) by a different route but I think they are reasonably justified given the use cases. I wouldn't expect a direct match between the UCs and requirments, just a reasonable connection. The matching will always be arguable; I think we should also be clear that the requriments do not form an exhaustive set of features. = Use case intro = [[[ http://www.w3.org/2001/sw/DataAccess/UseCases#uc 3. Use cases Each use case describes a concrete application of future technology recommendation, setting a user-oriented context in which the query language or protocol or both are used to solve a real problem. ]]] We were going to have text more like the OWL requirments doc: [[[ http://www.w3.org/TR/2004/REC-webont-req-20040210/ one should not assume that OWL will directly support every aspect of the use cases. ]]] that made it clear we are not completely solving the use cases but providing technology for them. = Requirements = One area we have had a lot of discussion on is the "tell me about" query - where the result form is not determined by the query itself. This is covered in UC 3.2 (Motorcycle parts) I think (it is arguable). Explicitly including this, or explicitly rejecting it, as a requirement would make thing clearer to the wider community. We may not have time before publication. = Typos = I wasn't looking specifically for these but I noticed: 3.2-para-2: s/receive/receive/ 3.3-para-3: s/contain/contains/ 3.5-para-2: s/^But his/His/ 3.8-para-1: Elsewhere uses em rules (em dashes) so s/ -- /—/ 4.10 title: s/\.// = Feedback = A link to where feedback should go. My preference is that we have a separate comments mailing list to gather the feedback. Having this running before we publish would be good. Andy -------- Original Message -------- > From: public-rdf-dawg-request@w3.org <> > Date: 3 May 2004 22:06 > > Folks, > > I've checked in version 1.31 of the UC&R document. It's my best effort > to address the issues raised before, during, and since our F2F > meeting. I haven't yet finished working through all of the issues on > my TODO list, but I got most of the big ones. (And for some reason > aspell, my Unixy spell checker, doesn't like the document so I've been > unable to spell check it...Sorry.) > > I'm suggesting the following publication schedule as way to start > discussing the fulfillment of our obligation to publish by the end of > May: > > 17 May -- I'll freeze the document > 18 May -- discussion of document in telcon > 25 May -- final discussion; call the question > 26 to 29 May -- if approved, I'll finalize the doc here 30 May -- > publish > > (By "freeze", I mean I'll be very unlikely to add new material or > significantly reorganize the document on *my own initiative* after this > point.) > > Frankly, I think we now have enough use cases: there are two existing > ones I need to polish, modulo new concerns or issues raised by others > > Thus, unless I hear from people explicitly, I'm not likely to add more > UCs to the document on my own steam. > > Best, > Kendall
Received on Tuesday, 4 May 2004 05:36:07 UTC