Re: protocol draft available

On Sun, Nov 21, 2004 at 10:51:35AM -0500, Tom Adams wrote:
> 
> FWIW, when we expose Kowari/TKS via WSDL, we only expose only one 
> method, a generic query operation. iTQL supports all the operations 
> (delete, add, drop, create, etc.) so we only need to provide one method 
> of access. 

Yeah, since we haven't pushed everything into the query language, that
doesn't really work here.

> o I like this document, it reads well and while I don't think it's in 
> the format of a spec, could easily be turned into one (DanC has 
> addressed this). It's a strong piece of work.

Thanks, Tom. I think Dan's points re: this are wrong, but I agree that
it's not formatted entirely like a spec, but rather like a proposal to
the WG as to the direction such a spec would go. Hard to write a pure
spec proposal when there is disagreement and undiscussed detail in the
space the spec covers. At least, it was hard for me.

Some of the existing doc, in either draft, would get dropped if the WG
decided to go forward with it, since it's addressed to WG members
about issues we haven't decided.

> o I'd like to see (this can be taken as an offer) a summary table 
> somewhere at the start that lists operations by conformance levels. 
> This'll make it easy to specify what's in what level.

Yes, that's a spec-requirement. But it sorta falls out (as does the
idea of conformance levels, I think) in the simplex draft. For
simplex, we either do query and getGraph (my position) or we do query
(Andy's position), and in either case, I think both are required. So
there just won't be enough "there" there to bother w/ conformance
levels, IMO.

For the draft with 7 operations, a summary table of conformance levels
makes good sense. I'm just hesitant to do *that* kind of work till I
know it will or won't be needed.

> o Minor grammatics:

Equally nitpicky responses... :>

>   o Use full name for SPARQL the first time you reference it.

Yep.

>   o 2nd paragraph needs comma after "SPARQL Query Language for RDF".

Uh, no, it really doesn't. A comma, at least in standard American
English, is used before a conjunctive that joins independent, not
dependent clauses, in which latter case it's optional and I don't
prefer it. :>

>   o You use "qua" twice in section 2 # 9, I'm not sure what this
    means.

It's a Latin word which you can read as "as". I suspect most of
section 2 would be dropped in a real spec; or at least radically
revised, since it seems that some of my assumptions aren't widely
shared by everyone -- or at least not shared by some of the most vocal
WG members. :>

>   o SPARL type, section 9 #10.

Thx.

>   o I think in section 3, B, *A, you want to use a "0" not an "o". 
> Could be my font.

I'll look at this eventually. In the simplex spec, a lot of this
"apparatus" would go away, I think.

>   o Reference to SPARQL in second paragraph is incorrect (gives 404).
>   o RDF triple definition has URI with lower case i - "URi"

Thx.

> I'll now go through section by section.
> 
> 5.0 Abstract protocol -> A. Types -> Protocol Types
> 
> OperationProcessor - OperationContext is not defined
> 
> Also, why are some operations links, and some not?

Because I ran out of time to make all the good internal links. Would
do this for a real spec, of course.

> 5.0 Abstract protocol -> A. Types -> Query Types
> 
> DistinctQueryResults
> 
> 1) Replace "winnowed" with "removed".

Why?

> 2) Be careful about the wording and emphasis of the second sentence, 
> even though it uses "may not" (is this in RDF2119 BTW?), I read it 
> quickly as "must not". I know what you're trying to say, but we need to 
> make sure we're unambiguous.

I'll have to think about this.

> LimitQueryResults - I believe we need offset here too.
> 
> StreamingQueryResults
> 
> 1) This definition of streaming isn't clear to me. In fact after 
> reading it I have no idea what you mean, this to me says results must 
> be ordered - "elements of one solution to a query available ... before 
> any elements of another solution". I *think* I know what this should 
> say though. To me streaming means that the client is not forced to hold 
> the entire result set in memory at one time, results are "streamed" to 
> the client one at a time as fast as the client can pull them.

Yes; this is meant to force discussion about our streaming design
objective, and isn't "real" spec language. Think of it as a
placeholder or a promissory note.

> 5.0 Abstract protocol -> B. Responses
> 
> Why do you have a separate code for GraphCreated? Perhaps I missed 
> something later on.

Meant to be returned in response to a successful makeGraph
operation. Could just use OK for that, but I thought something
specific was useful. Perhaps not.

> 5.0 Abstract protocol -> C. Operations
> 
> I'd prefer to call "makeGraph" "createGraph". I think this is just 
> personal taste though.

No, my undergrads didn't like "makeGraph" either. I will likely make
this change unless the simplex draft gets the most support.

> 4. makeGraph
> 
> Does this support the creation of an empty graph? In TKS/Kowari, we 
> allow the creation of models, then the subsequent insertion of data 
> into them. So at any point, a model may or may not have any data in it.

I intended that it would by including an empty RDF graph in, say,
RDF/XML serialization. Works for me.

> 6. addTriples
> 
> Can this operation support adding triples that result from a query? 

I thought about that long and hard, trying to find a relatively clean
way of expressing it in one HTTP request. I'm not sure I found such a
way. 

> Like what deleteTriples supports?

Yes, it would be nicely parallel with delete. I'll think about this
some more and welcome suggestions.

> 7. deleteTriples
> 
> "If a triple T is deleted as a result of deleteTriples, but is still 
> entailed by the RDF graph, then it will still exist in the RDF graph 
> after the deleteTriples operation was invoked."
> 
> The above sentence doesn't make sense to me. 

It might help if I'd written "may" instead of "will still exist".

> I assume the entailment is 
> due to the triple existing as an inferred triple. If so, it should 
> perhaps be reworded as:
> 
> If a triple T is deleted as a result of deleteTriples, but is still 
> entailed by the RDF graph (for example as a virtual or inferred 
> triple), then it will still exist in the RDF graph after the 
> deleteTriples operation was invoked.

Yeah, that's what I meant. Thx.

> 6. Advertisement and Discovery
> 
> I think the Service and Resource Advertisement section should be in the 
> spec, but should be flagged as being background.
> 
> In point 3, the set of RDF graphs returned may be large, we have 
> clients who store hundreds of thousands of graphs. This needs to be a 
> separate operation, and not returned via getOptions.

I assume that getOptions can do the REST hypermedia thing, at least
for the HTTP binding, of returning a document that largely consists of
pointers to other documents, letting the client navigate where it
will. I'm not sure that requires a separate protocol operation.

> That is all for now.

Thanks a lot, Tom. Depending on which (if either!) draft we go forward
with, I'll make the appropriate fixes you pointed out.

Kendall
-- 
Sometimes it's appropriate, even patriotic, to be ashamed
of your country. -- James Howard Kunstler

Received on Monday, 22 November 2004 16:08:29 UTC