Difference to YQL?

409 views
Skip to first unread message

Markus Lanthaler

unread,
Nov 23, 2011, 6:33:20 AM11/23/11
to ql...@googlegroups.com
Hi,

After reading through the docs I'm wondering how ql.io is different from
Yahoo's YQL? Or is it just the same but open sourced?


Regards,
Markus


--
Markus Lanthaler
@markuslanthaler

Subbu Allamaraju

unread,
Nov 23, 2011, 7:55:47 AM11/23/11
to ql...@googlegroups.com, <qlio@googlegroups.com>
Have you tried building the example in http://66.211.164.71/docs/quickstart? That should help doffeerentiate. Please ignore simple selects frame the examples page (which btw are still work in progress).

Subbu

Markus Lanthaler

unread,
Nov 25, 2011, 3:37:07 AM11/25/11
to ql...@googlegroups.com
Hi Subbu,

You are right, you can't achieve that directly in YQL as it doesn't support
inner joins; it just supports sub-queries. But that's really the only
distinction I've seen so far. All the rest looks pretty similar - or am I
missing something?

Is there a reason why you didn't use a graph data model and in consequence a
SPARQL like query interface? That's one of the approaches I'm working on
(see http://bit.ly/seredasj and https://bitly.com/sparql2rest for details).


In YQL the closest query I could come up with was the following:

select * from yql.query.multi where queries="select ProductID.Value,
ProductID.Type, Title, ReviewCount from eBay.ProductDetails where
(ProductID.Value, ProductID.Type) in (select ProductID.Value, ProductID.Type
from eBay.FindProducts where QueryKeywords = 'macbook pro'); select
ProductID, ReviewDetails.AverageRating from eBay.ProductReviews where
(ProductID.Value, ProductID.Type) in (select ProductID.Value, ProductID.Type
from eBay.FindProducts where QueryKeywords = 'macbook pro');"


... which will produce the following output:

{
"query": {
"count": 2,
"created": "2011-11-25T05:33:06Z",
"lang": "en-US",
"meta": {
"meta": [
null,
null
]
},
"results": {
"results": [
{
"Product": [
{
"ProductID": {
"Value": "99741550",
"Type": "Reference"
},
"ReviewCount": "37",
"Title": "Apple MacBook Pro 13.3\" Laptop - MC700LL/A (February,
2011)"
},
{
"ProductID": {
"Value": "84755204",
"Type": "Reference"
},
"ReviewCount": "112",
"Title": "Apple MacBook Pro 13.3\" Laptop - MC374LL/A (April, 2010)"
},
{
"ProductID": {
"Value": "78092464",
"Type": "Reference"
},
"ReviewCount": "102",
"Title": "Apple MacBook Pro 13.3\" Laptop - MB990LL/A (June, 2009)"
},
{
"ProductID": {
"Value": "108789851",
"Type": "Reference"
},
"ReviewCount": "2",
"Title": "Apple MacBook Pro 15.4\" Laptop (February, 2011) -
Customized"
},
{
"ProductID": {
"Value": "78131796",
"Type": "Reference"
},
"ReviewCount": "30",
"Title": "Apple MacBook Pro 15.4\" Laptop - MB470LL/A (October,
2008)"
}
]
},
{
"json": [
{
"ProductID": {
"Value": "99741550",
"Type": "Reference"
},
"ReviewDetails": {
"AverageRating": "5.0"
}
},
{
"ProductID": {
"Value": "84755204",
"Type": "Reference"
},
"ReviewDetails": {
"AverageRating": "4.5"
}
},
{
"ProductID": {
"Value": "78092464",
"Type": "Reference"
},
"ReviewDetails": {
"AverageRating": "4.5"
}
},
{
"ProductID": {
"Value": "108789851",
"Type": "Reference"
},
"ReviewDetails": {
"AverageRating": "5.0"
}
},
{
"ProductID": {
"Value": "78131796",
"Type": "Reference"
},
"ReviewDetails": {
"AverageRating": "4.5"
}
}
]
}
]
}
}
}

--
Markus Lanthaler
@markuslanthaler

Subbu Allamaraju

unread,
Nov 26, 2011, 2:32:06 AM11/26/11
to ql...@googlegroups.com
Hi Markus,

I think your example below shows the *key* difference that ql.io is based on a procedural style scripting language for to do automatic orchestration - meaning that dependencies between statements determine the execution order. It does not matter whether the script has 3 selects from source HTTP APIs, or 100 selects with some using HTTP APIs and some using JSON objects - as a developer, you just write statements in their natural order. Batching, forks, joins etc. happen implicitly.

Other features of the language include:

* Mapping to arbitrary HTTP resources - create table abstract all the details necessary to make an HTTP request with/without body
* JSON objects (string, array, object, true, false, etc) in RHS and return statements
* Assignment of results of statements or objects to variables
* Projections of assignments
* Variable references in statements and objects (such as "{foo.bar}")
* Return statements
* Routes to execute stored scripts

The runtime is built on node with AIO. You can deploy ql.io wherever it makes most sense - closer to API servers, or on front-end servers, or closer to client on the edge.

Thanks for the links to your papers. I will check it out.

Subbu

Markus Lanthaler

unread,
Nov 27, 2011, 4:44:10 AM11/27/11
to ql...@googlegroups.com
Hi Subbu,

Yes, and that makes it very easy for developers to use.

As far as I understood it the response has to be in JSON, right? There is,
at least at the moment, no support for other response formats, right?

Would be really interested to hear you opinion about my papers.

Subbu Allamaraju

unread,
Nov 27, 2011, 10:09:12 AM11/27/11
to ql...@googlegroups.com
APIs can return either XML or JSON, but the processing is done entirely in JSON. Also the response from ql.io is JSON.

Subbu

Subbu Allamaraju

unread,
Nov 28, 2011, 11:44:55 PM11/28/11
to ql...@googlegroups.com
FYI, here is one more added today to explain some more capabilities.

http://66.211.164.71/docs/variable-ref

Subbu

Reply all
Reply to author
Forward
0 new messages