Re: allow implicitly unbound variables in SPARQL results?

(Trimming unnecessary CC:'s.)

On Dec 14, 2005, at 11:12 AM, Lee Feigenbaum wrote:

> I must say that I, at least, am not particularly swayed by our  
> requirement
> for a
> bandwidth-efficient protocol.

But the WG adopted it and is, in *some* sense, bound by that decision  
until or unless it overturns it explicitly. I don't think we can  
ignore it.

> Yes, the collapsed version is more
> efficient, but only
> for a particular class of queries (those featuring unbound variables).

Granted. However, that class of queries may be more important that  
would otherwise seem to be the case. For UMD's semantic portal  
framework -- there was a workshop about semantic portals, which I  
believe Steve Harris attended, and the technical discussion seems to  
have boiled down to "use SPARQL when it's ready" -- we build almost  
all of the portal from SPARQL queries. And given the prevalence of  
FOAF data, not only in our portal but in my.opera.com's and in other  
ones, you end up having to do queries where it's reasonably to  
believe that you're going to have *tons* of unbound variables. That's  
how Ron Alford got to the point where he wanted to make an objection  
to the LC design. He and other people at our lab were writing code to  
use SPARQL in our portal, and they kept getting big blowups because  
of our query language semantics, some FOAF modeling decisions, and  
the relative inefficiency of our results format.

So, yes, it's a small change to optimize a particularly verbose  
feature of our results format, but I think it's a mistake to dismiss  
that as corner or edge...

Among our accepted use cases is at least one (and several, IIRC) apps  
that basically describe or presume a semantic portal. It *could* be  
one of the bigger areas of use of SPARQL. We ignore it at our peril,  
IMO.

> I
> would much
> rather publish a less-efficient yet fully functional XML design  
> along with

Option c is not fully functional in some way?

> compromise. (The flippant side of me wants to point out that the  
> results
> format would
> be more efficient if it only used one-letter element names, as well.)

But not relevantly more efficient, Lee. Jeen's numbers, IIRC, show  
that option c is 2x more efficient than LC design. How much  
efficiency gain would one-letter element names buy? I'd be  
*astonished* if it were more than 10%. No way it's 2x. (Though if you  
prove me wrong, I will buy you a beer!)

> Finally, from a procedural point of view, I'd like to point out  
> that 4.7
> is a design
> objective and NOT a requirement.

Yes, indeed.

Cheers,
Kendall

Received on Wednesday, 14 December 2005 16:48:56 UTC