Re: protocol draft available

Tom Adams wrote:
> 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.

One real value of having an update language (whether that is querylanguage or a 
separate language is immaterial), rather than update operations, is the 
possibility of writing the changes in a document, then referring to the document 
via RSS.  Operations, even ones that refer to documents, don't fit with RSS very 
well as they are client-push, not database-pull.

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

Indeed - maybe a way forward is to take just the HTTP+query part and publish as 
a working draft as soon as possible (before XMas?) and work on the overall 
architecture separately as it may be beyond this WG's timescale.

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

It would be better in the query langauge rather than on a per protocol design.


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

Received on Monday, 22 November 2004 14:49:15 UTC