comments on Protocol doc 14Jan2005

Hi Kendall

Sorry Im only just resurfacing, here are some quick comments on your 
14 Jan draft. Mostly to do with exposition rather than real content.

A OperationTargetSet is a set of one or more distinct OperationTarget
//
An Operation.....OperationTargets

RDFGraph

RDFGraph is a canonically serialized RDF graph...

Wait a minute, that reads circularly, like saying a person is a an 
American person, or something like that. But its worse, since these 
are things in different categories. An RDF graph is a pure 
abstraction: its defined to be a set in your glossary. A canonically 
serialized RDF graph is a piece of XML, presumably: but even that can 
be understood as a type rather than a token. If I find a canonically 
serialized RDF graph stored in a document at a URI ex:this and I copy 
it exactly, character by character, and store it as ex:that, is it 
the same canonically serialized RDF graph? Or are there now two of 
them? The point being that transfer protocols only apply to the most 
concrete of these entities. In the sense of "canonically serialized 
RDF graph" in which ex:this and ex:that are the same one, it 
meaningless to talk of executing protocol operations against them; 
and of course still less meaningful if we are referring to graphs 
themselves. So Im really not sure what it could mean to say that an 
OperationTarget could be (be? As in, be the very same thing as??) an 
RDF graph, as contrasted with a URI identifying a RDF graph resource.

By the way, what exactly is an "RDF graph resource", again? That 
sounds like it might be a useful idea, deserving of glossary entry.

What does the notation
instanceOf(http://www.w3.org/1999/02/22-rdf-syntax-ns#)
mean, exactly? You use it without defining it.

----

OperationTarget can be a anyURI which identifies a graph resource, 
and an OperationPoint is an anyURI identifying...an OperationTarget. 
Is that right? So the OP is a URI identifying another URI, the OT, 
which identifies the graph resource. That sounds like a 2- or 3-way 
indirection from OP to graph (OP-URI --> OT-URI--> graph-resource --> 
graph); is that really intended?

indpendent//independent


  if true, distinct results must be returned to the client; if false, 
distinct results may not be returned to the client

Surely : if false, no constraint is implied, or some such.  I think 
'may not' means 'is forbidden'.

Why do we need protocol-level constructions for distinctQuery and 
limitQuery? Surely these are language-level issues. The protocols are 
the same with or without these flags: an answer with distinct results 
is indistinguishable from one with duplications at the protocol level.

Implicit arguments

All of the abstract protocol operations defined here, with the 
exception of makeGraph, are equally well conveyed to an RDF graph as 
to an operation processing service.

Well, no: see above comment. It really does not make sense to talk of 
conveying a protocol operation to an RDF graph (= a set). That is 
like talking about stroking an integer or painting an idea red. You 
didnt put 'RDF graph' into your special font in this extract, so Im 
using the normal meaning; maybe this is just a formatting slip. But 
you see the problem of having this ambiguity everywhere. I'd suggest 
it would be better to stick to the strict RDF meaning of 'RDF graph', 
and use a locution like your 'RDF graph resource' to refer to the 
RDF-graphish thingies that protocols can get sent to.


I like the idea of SPARQL...FIXME. That seems like an excellent 
suggestion for a revized HTML protocol, in fact.

Pat

-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes