- From: Thompson, Bryan B. <BRYAN.B.THOMPSON@saic.com>
- Date: Tue, 25 May 2004 09:27:39 -0400
- To: "'public-rdf-dawg@w3.org'" <public-rdf-dawg@w3.org>
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