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

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