- From: <howardk@fatdog.com>
- Date: Thu, 13 May 2004 11:35:16 -0700
- To: Kendall Clark <kendall@monkeyfist.com>, 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>
Kendall, Nice work on the UC document. That's looking very nice. I'm attaching a list of typos and comments. Howard ---------------------------- Section 1. Introduction, third paragraph, starting "Further, there may be as many different methods ...": The second sentence uses dashes to set off the phrase "HTTP, SOAP, or XML-RPC". The first dash is garbled. --------------------------------- Section 1. Introduction, last paragraph. Last sentence reads, "The use cases, in turn, inform decisions about requirements, ... , as well as less urgent objectives." I'd suggest hyperlinking the words "requirements" and "objectives" to their respective sections in the document. This would emphasize that you're not just speaking about what these things are in abstract, general terms, but are defining the actual sections in this specific document and how they relate to each other. -------------------------------- 2.1 Finding an Email Address, first paragraph "FOAF vocabulary Specification" -> "FOAF Vocabulary Specification" -------------------------------- 2.1 Finding an Email Address, second paragraph: "George's email client ... set the query's result as the value of the 'To:' field" For whatever reason, I have a bit of a hard time parsing the last clause in this sentence. I think it might be the "set the result *as* ..." that's causing the difficulty. In any event, I find this slightly easier to read: "... return the value of the 'To:' field as the query result." (And if you don't have this particular difficulty on reading the original text, feel free to ignore my comment.) -------------------------------- 2.1 Finding an Email Address, "Motivates" cross-reference section at the bottom (and in all other use cases as well) I'd suggest hyperlinking on the titles being referenced (ie, "RDF Graph Pattern Matching") rather than their section numbers ("3.1"). This would look better visually (imho) and make the names of the Requirements stand out better, as well as making them easier to click on (important for those of us who in our dotage are not only slowly losing control of our bladders but our fine mouse-control skills as well). (Kendall: I'm happy to do this if you'd like a hand. I'm out of the office today but could turn this around to you in a couple of hours this evening or early tomorrow morning.) ---------------------------------- 2.2 Finding Information about Motorcycle Parts I printed out the original triples version of the code snippet. If you're going back to a triples version (and even if you're not), a few of the longer lines in hardcopy are truncated by the righthand margin. Any chance of finding shorter URIs for the triumph:type and triumph:part-for properties in particular? ---------------------------------- 2.3 Finding Unknown Media Objects, second paragraph: "Smiley uses his web browser to setup a query ...": "setup" -> "set up" ----------------------- 2.4 Monitoring News Events, first paragraph, "She wants her personal digital recorder (PDR) to record every television show automatically using the Electronic Program Guides." 1) I'm presuming you don't mean "every television show" literally, but rather "every television show containing the story". I would say the latter explicitly. 2) I'd place EPG in parentheses after "Electronic Program Guides", similarly to what you've done with "personal digital recorder (PDR)". (And why capitalize the words in the former expression but not the latter?) --------------------------------- 2.5 Avoiding Traffic Jams "Niel" is far less common than "Neil" (by a factor of 60 on Google). Just double-checking that's the one you intended to use ... -------------------------------- 2.7 Exploring the Neighborhood, paragraph one, last sentence: "Jose wants to find out the latitude, longitude, name, and type of everything within 1 mile of the convention centre so that he can plan his meals and sightseeing time accordingly." 1) "1" -> "one" 2) Just a thought, but if you want it's easy to expand the use case to encompass a second date/time example of Datatype Support: "Jose wants to find out the latitude, longitude, name, and type of everything within one mile of the convention centre, as well as all events happening during his stay, so that he can plan his meals and sightseeing time accordingly." ------------------------------- 3.3 Extensible Value Testing, first paragraph, "The query language must make it possible?whether by way of function calls, namespaces, or in some other way?to calculate and test values extensibly." A real niggle, but I'd change the second "or in some other way" to either "or in some other fashion" or "or some other mechanism" to avoid repeating the word "way". --------------------- 4. Design Objectives The first sentence, "Design objectives differ from requirements in that the query language and data access protocol specification may be considered complete if none, some, or all of these design objectives are achieved," seems awkward and doesn't convey much useful information. Aren't you just saying that they're optional, which is what the second sentence already says? I'd simplify as something like, "Design objectives are considered somewhat less critical and/or important than requirements, and unlike the latter, are considered optional."
Received on Thursday, 13 May 2004 14:53:13 UTC