- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Tue, 25 May 2004 10:16:06 -0400
- To: "Thompson, Bryan B." <BRYAN.B.THOMPSON@saic.com>
- Cc: "'public-rdf-dawg@w3.org'" <public-rdf-dawg@w3.org>
On Tue, May 25, 2004 at 09:27:39AM -0400, Thompson, Bryan B. wrote: > > 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. I'm not going to make these changes; the paragraphs in question are far more readable w/out them, IMO. > In the last sentence of paragraph two and throughout the document, > change [builtin] to [built-in]. Fixed this. > 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). Well, as you know, requirements and design objectives doesn't merely indicate the diff between mandatory and optional; it also indicates, at least to us, the diff between those things that have gotten a lot of support versus those things that have gotten less support. While there may be a change here worth making along the lines you suggest, I think this is too big a change to make at this relatively late date. Let's revisit this again for the next draft? > 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. Hmm... Not entirely sure what to do here... > 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. I didn't add anything after the vote. The problem is that we voted on this one *with* the phrase you want to strike, and I can't be sure that whether that phrase helped someone accept this requirement. I'll work on a variant and we can see if there is consensus for it. But I'm unhappy with this in some sense because it weakens the document. This is an *approved* requirement -- having a variant of it is not very healthy, IMO. IIRC, there are only variants of PENDING items, not of ACCEPTED ones. > 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. I'd prefer not to renumber at this point. > 3.7 (Limited Datatype Support). Replace [query language language] > with [query language]. Ooh, good. > 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." Hmm, that's interesting... I'll add as a variant. > 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'. Propose some language. > 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? Yes, I edited it per editor's prerogative, and since I proposed it to begin with. I meant "user-specifiable" as a weak form, which would cover content-negotiation, for example, as an implementation tact. > 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. This points up an ambiguity in MIME/IMT, and I'm not sure I want the proposal to take a position on this... I'll think about it some more and I'd like to hear from others about it. > > 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. Please send URLs for these. I think XForms is already there; and what is "XML Stylesheets"? > x. (Glossary) I would like to see the glossary in this document until > such a time as it is refactored into another document. Hmm, even as HTML comment? I would have sworn no one had looked at this, even once! :> Thanks! Kendall
Received on Tuesday, 25 May 2004 10:19:05 UTC