Comments on "DAWG use cases and requirements" v1.89

Excellent work!  I would vote to release this version (per-or post any
editorial changes based on final comments) as our first working draft.
Comments follow.

1. Introduction. Strike [, there has not yet been any work done to
   create standards for querying or accessing RDF data] since it is
   highly redundent with the next two sentences.

   In the last sentence of paragraph one, strike [interacting with].
   We have just mentioned "data access" and we're not currently doing
   graph update, so I don't see that this language adds anything.

   In the last sentence of paragraph two and throughout the document,
   change [builtin] to [built-in].

   In the last paragraph of the Introduction, I do not like the
   language that is being used ("requirements" vs "design objectives")
   to indicate the distinction between manditory and non-manditory
   requirements (those not on the critical path).  How about writing a
   series of "The DAWG Recommendation MUST" assertions (the critical
   path succeed or perish requirements) and a series of "The DAWG
   Recommendation SHOULD" or "The DAWG Recommendation MAY" assertions
   (non-manditory guidence for the working group).

2.0 (Use Cases).  The language [future technology recommendation] is
   awkward.  DAWG is chartered to produce a W3C Recommendation on the
   basis of which implementors will realize future technologies.
   However, the rec is NOT a technology.

   The last sentence of the paragraph strike [But] and insert [The use
   cases are designed to motivate and ground the discussion and
   identification of requirements, but ....].

2.3 (Finding Unknown Media Objects (Publishing)).  The text says
   "matching various properties ... price point".  It seems to me that
   the user would need to satisify a price point criteria, such as
   price < 15 euro), not match a price point value.  Also, I think
   that a string match on title and author properties is unlikely to
   get someone what they need -- especially when querying across
   multiple knowledge bases.  I would like to see an edit that
   discusses how the user might find the URIs that identify the
   title(s) and author(s) of interest so that Smiley will have a
   better chance of finding the data he needs.

3.3 (Extensible Value Testing) There seems to be consensus in the
   group that the language of the requirement be concise without
   including for example or motivating use cases.  3.3 is an outlier
   in that it includes both.  I would recommend a refactoring that
   strikes [--whether through function calls, namespaces, or in some
   other way--] and which migrates the second paragraph into a use
   case.  Frankly, I don't remember the second paragraph from the vote
   on this requirement.

3.4 (Subgraph results) If we approve this requirement (I would vote
   'yes'), then re-order the requirements so that "variable binding
   results" and "subgraph results" are next to one another in the
   requirements section.

3.7 (Limited Datatype Support).  Replace [query language language]
   with [query language].

3.10a (Iterative Query (variant)).  In order to avoid stateful
   connections, another variant would have the server create a
   resource that contains the results.  The client could then apply
   DAWG or other mechanism to access portions of the result set.  This
   can also stand on its own as a requirement, "The server must be
   able to produce a persistent representation of the query result."

4 (Design Objectives) Please see my earlier comments on the
   Introduction concerning the distinction between "requirements" and
   "design objectives".

4.2 (Provenance) This item does not address the ability to query
   provenance data, nor to query (provenance + graph).  I would like
   to see such an item added so that we can vote on it as a possible
   requirement and/or 'design objective'.

4.4 (User specifiable serialization).  I like this goal.  However, I
   seem to remember that there was language to the effect that "a
   client could negotiate the representation" that would be used in
   the response by the server (ala content negotiation).  Did this get
   scrapped in favor of the "user specifiable serialization"?  I don't
   recall any explicit vote on this?  If so, I think that they are
   different issues.  For example, you could negotiate for
   application/atom+xml and specify a serialization syntax for Atom.
   In any case, I would like to see the content negotiation language
   back in.

   For example, "The client can negotiate with the server to identify
   the Internet MIME Type that will be used to serialize the results
   identified by the query."

5. (Related Technologies and Standards)

    Add XML Stylesheets.

    Add XForms.

    Add RSS

    Add Atom interchange syntax and publishing model (it is up in the
    air right now whether Atom will get standardized at the IETF or
    W3C).

    Add XML Topic Maps.


x. (Glossary) I would like to see the glossary in this document until
   such a time as it is refactored into another document.

Received on Tuesday, 25 May 2004 09:28:31 UTC