Re: UC&R 1.47 (Was: Re: Comments on UseCases v1.46)

Kendall Clark wrote:

>Anyway, version 1.47 should be available now.
>  
>
Thanks Kendal for the new version. The document looks like it is really 
coming together.

Here are some comments on 1.47. Please be patient if some of my comments 
are not accurate due to my being a newbie and misunderstanding something.

Comments on Use Cases:

-We should be consistent and explicit to mention RDF store when talking 
about knowledge bases in use cases. Some use cases do (2.1, 2.4, 2.5, 
2.7, 2.8, 2.9) and some dont (2.2, 2.3).

-In Use case 2.2 (Motorcycle parts) there is no clear link between 
manufacturer's parts database an the Endeavour parts  database.  Suggest 
replacing  "manufacturer's parts database" with "Endeavor's parts database"

-2.6 Discovering What People Say about News Stories (Publishing)
Not clear why the use case talks about multiple query languages. Is 
multiple query languages
a goal of DAWG. Is the idea that DAWG describes one abstract syntax with 
one or more concrete bindings
and the multiple query languages map to multiple bindings of DAWG?

-2.7 Exploring the neighborhood
This use case verbiage could be simplified.
Suggest alternate wording:

"
Jose wants to find out the latitude, longitude, name, and type of 
everything within 1 mile of the hotel in Washington D.C. where he is 
staying so that he can plan his meals and sightseeing time accordingly. 
The U.S. Census Bureau provides interesting geographic data in its new 
RDF database.

Jose sends a query to the Census Bureau's new RDF database and requests 
that the results be passed to an XSLT transformation service so that he 
can print the resulting XHTML.
"


Comments on Requirements:

3.2 Variable Binding Result

This one I find is difficult to parse and understand. Archive search is 
not helping. Can someone provide an example and clearer description of 
the requirement? Thanks.

3.3 Extensible Value Testing

Suggest changing "to extensibly calculate with and test values" to "to 
calculate and test values in an extensible manner".

3.4 Subgraph Results

Prefer wording of 3.4 compared to 3.4a. I seem to grok it better.

3.6 Option Match
Suggested re-wording based on my limited understanding....

"
It must be possible to express a query with optional parts such that the 
query does not fail to match when one or more optional parts of the 
query fails to match. Any such triples matched by this optional part, or 
variable bindings caused by this optional part, can be returned in the 
results, if requested.
"
3.10 Result Limits
I think this requirement should be replaced with a requirement for a 
database cursor like requirement. This is essential for scalability 
according to my experience with ebXML Registry etc.

Suggested wording is....

3.10 Iterative Query Support
The query language or protocol must be able to handle large result sets 
of any size by iterating over the result set and  fetching it in chunks. 

Thats all for now.

-- 
Regards,
Farrukh

Received on Tuesday, 11 May 2004 09:05:51 UTC