RE: variables prefix - ?variable vs. $variable

My preference to spell variables is as in
; q:where {?VARIABLE :howBusinessesLookAt :QueryLanguages}.

-- 
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/




"Rob Shearer" <Rob.Shearer@networkinference.com>
Sent by: public-rdf-dawg-request@w3.org
01/09/2004 00:00

 
        To:     <kendall@monkeyfist.com>
        cc:     "RDF Data Access Working Group" <public-rdf-dawg@w3.org>, (bcc: Jos 
De_Roo/AMDUS/MOR/Agfa-NV/BE/BAYER)
        Subject:        RE: variables prefix - ?variable vs. $variable



> On Tue, Aug 31, 2004 at 02:25:30PM -0700, Rob Shearer wrote:
>
> > > a variable like "?this"? Do their expectations really matter
> > > so little?
> >
> > As a general note, yes. Their expectations matter very little.
>
> Fine, but *you* get to tell them that!

I was rather under the impression that the subscribers to this mailing
list constituted a significant fraction of the entire RDQL community...

> > RDQL is
> > used in a tiny community and is clearly in the realm of the
> "proprietary
> > one-off language".
>
> Really? Proprietary in what sense? There's a public document
> describing it, multiple open source implementations, no patent
> encumbrances. It's neither proprietary nor one off *in any
> sense*. That's just misleading and false.

Proprietary meaning it's not perceived as community-owned, and one-off
in the sense that there's not a lot of expectation that a lot of
different commercially viable implementations will spring up. (As an
analogy, there are a ridiculous number of web-based interface frameworks
which companies have fully documented and released for public use.
They're still parochial, proprietary, one-off solutions and not
commodity APIs.)
It's really more about market perception than any particular technical
feature: there's a danger that the DAWG output could be viewed in this
way.

Right now, if a company commits resources to using RDQL, they perceive
them as costs for doing that one project, NOT as an investment in
developing commodity skills. That is very different from they way they
view training employees in SQL or XQuery.

Like it or not, that's the reality of how businesses look at these
languages.