comments on uc document

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