Re: protocol draft available


my review comments on V 1.2 of the protocol draft follow:

Overall feeling: good introduction and goals.
I like the structure where abstract protocol concepts
and operations are followed by a mapping to HTTP 1.1.
The set of operations appears to cover the use cases
we have in mind. We would also have interest to work
on SOAP V1.1 or V1.2 binding as we could then get better
synergies from security developments relating to Web Services.


Question on section 3, definition of 'Query Results':
I don't understand "Query and other operation results are
to be distinguished from the response codes that the
server may be required to return". I think this is due
to my non-native English. Is this the same as
"Query and other operation results can be
distinguished using response codes that the server may return"?

Question on section 5, definition of LimitQueryResults.
Isn't the interpretation of the positiveInteger value
dependent on the type of query result to be returned
from the server to the client? For example, given number 5
the bindings XML representation may return 5 rows/tuples
but RDF/XML representation may return 5 triples? I don't
know if this dependency needs to be brought up here but
I think it needs to be brought up somewhere.

Question on section 5 C, operation 4 makeGraph:
The last sentence starting 'Finally, makeGraph ..."
uses a query that returns bindings for variable a.
Should the example be using a CONSTRUCT mechanism instead
of SELECT in order to make it clear for the reader that
the result of the query results is triples i.e. an RDF graph?

Suggestion on section 7 i.e. HTTP binding:
I think adding the abstract syntax example in the beginning of each
HTTP binding example would make it easier for the reader
to map previous sections to these examples.

Question on Spaqrl-Stream attribute in HTTP:
I could not find example where this attribute has its
value set to 'true'. I hope this example gets added.
I would then welcome discussion whether HTTP should be
using chunked encoding.

Question on section 7, operation 4. makeGraph, 5. dropGraph and
6. addTriples:
We at Profium have implemented support for partial
adding and partial deletion of triples. If a client
sends a graph G1 for e.g. adding to the server
and server only stores a subset G2 of graph G1,
it announces in the reply the contents of G2.
The client can then calculate which triples did not
get added or deleted.
I would thus like to suggest these operations include
the resulting (created or deleted) graph in the response.
- makeGraph now suggests it provides a link to the resulting graph
via Location: attribute.
- dropGraph now suggests there is some RDF in the response in
the form of <rdf:RDF>...</rdf:RDF>. Maybe this is already
what I am asking for.
- addTriples now suggests also via
<?xml version="1.0" encoding="utf-8"?> that some RDF
is coming back. May this is also already what I am asking for.

Some typos on the way:
- ittself
- SPARL server
- indpendent
- section 5C, 6. addTriples: is missing hash (#) from the end
http://example/3.rdf> missing < from the beginning

Janne Saarela <janne.saarela at>
Profium, Lars Sonckin kaari 12, 02600 Espoo, Finland

Received on Sunday, 14 November 2004 14:03:01 UTC