Comments on UseCases v1.46

v1.46 looks in good shape, especially the text for UCs which is fairly
stable.


== Section 1. Introduction

Para 2/end: Not sure what the "domain specific semantics" refers to.

Para 3:
Suggest:

"""
There are also a variety of approaches for accessing remote RDF data.  Even
when the basic protocol ...
"""

== Section 2. Use Case

[[[ 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 requirements 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.


== 2.3: Finding Unknown Media Objects

"Smiley uses his web browser to establish a query" reads awkwardly to me; I
don't know what establishing a query is.

Suggest something like: 

"Smiley's web client has a UI for setting up queries to be executed
regularly."

== 2.5: Avoiding Traffic Jams

"Using his cell phone, Neil asks his car" hints at a voice interface (which,
in a car, it should be if he's driving!).  Could make it framed more in
setting up things before he drives off as voice interaction is not in our
scope so the focus is more on out bit?

== 2.8: Sharing Vacation Photos

has a [XXX:finish].  Just noting it to make sure it does not get forgotten.

== 2.9: Fining Input and Output Documents for Test Cases.

Seems to have lost the bit about filtering only for test cases with status
of "approved".

Last sentence is a remnant from having benefits with use cases.

Para 2: s/process of the/process the/

== Section 3: Candidate requirements

For publishing, should we have a one line note in each requirement to say
what's adopted and what's not.  Or a list of adopted ones.

"Mandatory" - This is an intermediate published draft so maybe "expected to
be" to give the WG a chance to find out that some things do not work well
together.

== 3.6: Optional Match

Instead of "optional triples", I would prefer to talk about an optional part
of the graph pattern so as to be more neutral to optional triples and/or
may-bind variables.

My attempt was:
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0282.html
Which doesn't talk about triples until the second sentence.

Also "named part of the query" implies labeling of query parts.  Suggest
"identified" or "nominated" or "marked".

== 3.9 Bandwidth-efficient Protocol
== 3.10 Result Limits

These will be important features of our recommendation. Given the framing of
section 4, "design objectives", they seem to fit better there because they
are not quantifiable.  That would still acknowledge that they are important
design objectives alongside a readable syntax.

== 4.5 Multigraph Query

I have difficulty with this one because of the ambiguity.  I don't oppose
query on multiple graphs (independently) then merging the results.  I can't
support merging the graphs and getting the results of a query over the
merged result.  Either it is query routing or it is building potentially
large intermediate graphs from unrelated sources - while it might make sense
when the two source are close, it does not across the web in general.

For the latter, creating an explicit merge of the two datasets and querying
that does not require any support from our work.  Its just aggregation which
is a potential point in the business value chain.

Received on Tuesday, 11 May 2004 07:15:24 UTC