- From: Paul Gearon <gearon@ieee.org>
- Date: Wed, 7 Oct 2009 20:43:05 -0400
- To: Lee Feigenbaum <lee@thefigtrees.net>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
On Wed, Oct 7, 2009 at 8:20 PM, Lee Feigenbaum <lee@thefigtrees.net> wrote: <snip/> > Could you explain the confusion some more? I was a proponent of naming > everything "2" in the first place, but I don't really see the complexity in > Steve's example above. It seems reasonable to give a list of different > versions that a particular application needs. Even if all the components of > this round of standardization had the same number, it seems it would still > be likely to have applications that need different versions. I don't think > that the "standardization round" should really have too much impact on how > people think about the individual components, but I'd like to understand > where the potential confusion is. >From a technical perspective (particularly as an implementor), I'm fine with things as they are. However, the public appear to find it unnecessarily complex. The general public are aware of a version of SPARQL that they call "version 1". There is very little awareness of the protocol being a part of the spec, so SPARQL just refers to all of it. Most people (who are interested in these things) are also aware that SPARQL is being updated at the moment, with most people adopting the moniker "SPARQL 2". Generally, people don't seem to have an issue with the next version being 1.1 instead of 2, so that's fine. But when we say that SPARQL will now be in several parts, with the query language and the protocol being 1.1 and the update language being 1.0, that's when the confusion comes. Having different version numbers for different parts of the spec is forcing a lot of people to be aware of the fact that there ARE different parts of the spec. That's all well and good for us, but the majority of people are just trying to figure out how to talk to a database, and are learning whatever they need to make it work. The proposed versioning does NOT work for them, and they make up the majority of potential users. Contributing to the complexity of the situation, the Update 1.0 spec depends on the Query 1.1 spec, again mixing version numbers - and simply to use a single part of the spec (Update). I get it, you get it, and anyone intimately familiar with SPARQL gets it, but the spec is being made available for the general public, and they don't get it. If I had to explain it to someone (and I often do) then personally I'd like to say, "SPARQL 1 had two parts. The first part lets me do queries, and the second part describes how to connect to a SPARQL server and talk to it. SPARQL 2 also has those parts, expanding significantly on the capabilities of each. It also has a third part that lets me update data in a database." Any versioning scheme that fits into that description (or something like it) would be supported by me. :-) Regards, Paul Gearon
Received on Thursday, 8 October 2009 00:43:37 UTC