Re: comments on Protocol doc 14Jan2005

On Wed, Jan 19, 2005 at 01:46:20PM -0600, Pat Hayes wrote:
> 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.

Thanks, Pat. Sorry it's taken me so long to respond to this.

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

I think I can best respond to this by saying that the text I wrote was
originally meant to support conveying queries via the protocol to
several different targets -- as well as trying to be strictly neutral
as between whether protocol operations were conveyed to RDF graphs or
to query processor services.

But I think in order to simplify things, the specification should rely
on the query language spec to determine whether or how a query
involves more than one RDF graph. In addition, perhaps the best way to
avoid constraining (by specification) implementation choices is to
simply be *silent* about what a protocol operation is conveyed to
(whether graph or service).

At any rate, I'm deleting most of the troublesome text you point to
from the Protocol Types section. I think that should help your
tautology sensors to quiet down?! :>

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

Hmm, perhaps I've gotten myself into trouble here, but I think I only
meant that an "RDF graph resource" is a resource identified by a URI
which has a representation with an RDF MIME type.

Again, I think the easiest thing to do is to drop talk of "RDF graph

> What does the notation
> instanceOf(
> mean, exactly? You use it without defining it.

Actually, I use it *before* defining it.  Ouch. Maybe a section reorg
is in order...



	Indicates a well-formed, and optionally valid, instance of an
	XML vocabulary identified by <URI>. For example,
	indicates a well-formed instance of RDF/XML. Representation
	types other than XML may be expressed in the same notation,
	even if they do not define well-formedness or validity or
	define it differently than XML.

> ----
> OperationTarget can be a anyURI which identifies a graph resource, 
> and an OperationPoint is an anyURI 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?

I think the spec is stronger with only one -- as opposed to several --
protocol types, since it allows me to delete all of this troubling
text. Hope that suits you as an answer?

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

Well, there's been some back and forth about where distinct and query
belong. Since "limit" and "distinct" are not both modifiers of SELECT,
I'm dropping this from the protocol spec.

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

One of the Query Types I define is RDFGraph. That's what I mean to say
can as equally well be the target of a protocol operation as a
service can be. Does that help at all?

Thanks for yr comments, Pat, they helped a lot.

Kendall Clark

Received on Saturday, 26 February 2005 17:08:12 UTC