Re: protocol draft available

Hi,

I've completed my review of the older draft, it was the first one 
published by Kendall (no revision markers). I haven't read the latest 
with the updates, but will do so, along with the simpler form I've 
skimmed and all my points still appear to apply).

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. Apart form the argument that we should bring everything into 
the query language (an argument I'm reasonably in favour of), it's 
probably a matter of taste as to whether an operation is exposed as a 
callable operation in the protocol, or accessible through the QL over 
one protocol operation.

Perhaps we can do both ;) That'd be confusing. Now to my review...

Some overall comments:

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.

o I'd thought we could do this post v1, but perhaps we need to have the 
more general discussion of what do we want to see in the query language 
vs. protocol, or as Andy puts it have locally. TKS/Kowari uses the 
query language for all operations, and only exposes one method via (one 
of) its external protocol (WSDL/SOAP). I'm perpetually behind, so 
someone feel free to tell me if this has been sorted already.

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.

o This is more a note to myself; I'm unsure what impact if any this 
protocol will have on TKS distributed queries. I don't *believe* that 
it will have any impact, but need to make sure we're covered.

o Minor grammatics:
   o Use full name for SPARQL the first time you reference it.
   o 2nd paragraph needs comma after "SPARQL Query Language for RDF".
   o You use "qua" twice in section 2 # 9, I'm not sure what this means.
   o SPARL type, section 9 #10.
   o I think in section 3, B, *A, you want to use a "0" not an "o". 
Could be my font.
   o Reference to SPARQL in second paragraph is incorrect (gives 404).
   o RDF triple definition has URI with lower case i - "URi"

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?

5.0 Abstract protocol -> A. Types -> Query Types

DistinctQueryResults

1) Replace "winnowed" with "removed".
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.

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.

2) You use both client and requester in the same sentence, pick one.

5.0 Abstract protocol -> B. Responses

Why do you have a separate code for GraphCreated? Perhaps I missed 
something later on.

5.0 Abstract protocol -> C. Operations

I'd prefer to call "makeGraph" "createGraph". I think this is just 
personal taste though.

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.

6. addTriples

Can this operation support adding triples that result from a query? 
Like what deleteTriples supports?

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. 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.

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.


That is all for now.

Cheers,
Tom



On 09/11/2004, at 9:17 AM, Kendall Clark wrote:

>
> Les Chiens,
>
> I'm relieved (!) to say that I've finally got a protocol draft that
> I'm willing to publicly share, in the event anyone's still
> interested. You can find it at
>
> 	    http://monkeyfist.com/kendall/sparql-protocol/
>
> but that should be considered a temporary location, I suspect.
>
> If the primary consideration was that it fit on one sheet of paper,
> then either I was the wrong person to work on this or it's just more
> complex than that. Or both. :>
>
> I worked really hard to describe an abstract protocol that could be
> realized in the Unix command-line environment, SOAP, HTTP, BEEP, and
> other diverse environments, and that took a great deal of time. I
> biased that abstract description in favor of HTTP, when things were
> otherwise tricky, but I hope not too much.
>
> It probably doesn't need to be said, but this is a draft, it's full of
> warts, bugs, and outright errors. I will continue to work on it pretty
> much all the time, which means now that I'm sharing it, I'll add some
> date/time/RCS-markers, so that changes are easier to detect.
>
> I hope that it helps, at the very least, focus our discussion and move
> us toward CR status with all deliberate speed.
>
> Best,
> Kendall Clark
> -- 
> Sometimes it's appropriate, even patriotic, to be ashamed of your
> country. -- James Howard Kunstler
>
>
-- 
Tom Adams                  | Tucana Technologies, Inc.
Support Engineer           |   Office: +1 703 871 5312
tom@tucanatech.com         |     Cell: +1 571 594 0847
http://www.tucanatech.com  |      Fax: +1 877 290 6687
------------------------------------------------------

Received on Sunday, 21 November 2004 15:51:38 UTC