Re: Concerning LET or AS

I thought I should share a couple of the comments I have had on this 
topic from TopQuadrant colleagues:

[[
Speaking as a person who teaches this stuff, more than our own 
reputation is at stake.  Perhaps this is something to add to our objection.

Technology adoption is the goal of a standard.  SPARQL fights an uphill 
battle for a couple of reasons: (1) It's Not SQL.  (2) Pattern-based 
retrieval is weird (witness the fabulous popularity of PROLOG as a 
software engineering language).  In short, many people are looking for 
reasons not to adopt it, and to stay with familiarity.
In short, the semantic web is faced with a huge hurdle in SPARQL.  And 
while I applaud the "small standard" policy (which in general is a boon 
to teaching and adoption), it is only good when it serves ease of adoption.

SPARQL 1.0 has some huge problems, that give SQL fans great ammunition 
when it comes to saying "it's not ready" - negation and aggregates are 
the biggies here, and both of them have been fixed.

Adding in another complex idiom (like nested subqueries) for something 
simple (LET) will be repeating the mistake of negation.  Another reason 
to say, "Wait for SPARQL 3".
I would go so far as to use the "small standard" argument the other 
way.  Subqueries are difficult - in fact, in my course, I say, 'The 
reason SPARQL doesn't have subquery is because it is not needed.  The 
sorts of things that you use them for in SQL are done easily in a 
pattern language, without resorted to a complex construct like a 
subquery".  I challenge the room to prove me wrong.  One person was able 
to do so.  No SQL programmer can do it - subqueries are error prone and 
confusing.

So - faced with a confusing, difficult, unsuccessful idea from SQL 
(subqueries) vs a well-accepted idea from BASIC, which one fits the 
"small standard" mantra better?  I can speak confidently as an educator 
in this stuff.   LET wins hands-down.
]]

and

[[
Also look at our mailing list to see what our customers are doing. [X]'s 
message from yesterday contains:

SELECT ?stringPredicate ?stringObject ?stringAttributesNodeName ?
stringAttributeNodeName
WHERE {
   CQ:GatheredData ?predicate ?object .
   LET (?stringPredicate := smf:cast(smf:name(?predicate),
xsd:string)) .
   LET (?stringObject := smf:cast(smf:name(?object), xsd:string)) .
   LET (?uuid := smf:generateUUID()) .
   ?attributes a CQ:attributes .
   LET (?attributesNodeName := smf:qname(?attributes)) .
   LET (?stringAttributesNodeName := smf:cast(smf:name(?
attributesNodeName), xsd:string)) .
   LET (?stringAttributeNodeName := smf:buildString("{?
stringAttributesNodeName}-{?uuid}")) .
}

Will make a nice chain of sub-SELECTs...

]]

Received on Tuesday, 3 November 2009 17:14:01 UTC