(Less substantial, but spookier: Dudu mentioned your name this morning, and just now, reading Leo Sauermann’s blog as I wrote a reply to him, I found a link here; wheels within wheels!)

[quote post="773"]Actually on the first point, I had not been very clear. For me the HTTP GET method IS ALREADY a Query. Thus, I don’t understand the need to layer new SQL-styled methods on top of it.[/quote]

Humm not sure I follow here: the idea of the SPARQL query if to get data from a RDF triple store. It is way to get results from a source of data. The HTTP GET method will get that data from the web server only. And the Accept: parameter will check for content negotiation. Am I missing something in your idea?

[quote post="773"]My current lonely work is actually to debunk a coherent URL semantics to bypass new methods constructions i.e how to for example distinguish “jobs” the 4-letter word, (the things that are) “jobs” and (the thing that are called) “Jobs”.

Thus, I would note / cool for a thing called “Cool”, /#cool for “A cool”, / #cool/ for all the things that are cool, or /%cool for the word cool).[/quote]

So if I understand right, you are developing a query language from the URI syntax? Than parse it with your web server to build some server side query to send to some data store?

Thanks!

Take care,

Fred

Thanks for your responses.

Actually on the first point, I had not been very clear. For me the HTTP GET method IS ALREADY a Query. Thus, I don’t understand the need to layer new SQL-styled methods on top of it.

My current lonely work is actually to debunk a coherent URL semantics to bypass new methods constructions i.e how to for example distinguish “jobs” the 4-letter word, (the things that are) “jobs” and (the thing that are called) “Jobs”.

Thus, I would note / cool for a thing called “Cool”, /#cool for “A cool”, / #cool/ for all the things that are cool, or /%cool for the word cool).

1. You have one URL to a Web Page that is also a Data Source URI

2. You do not have to learn SPARQL per se. You simply put URLs (usual Web Page Location references) or URIs (Pointers to Web Data Sources; which may include Web Pages) into the RDF Browser

3. Joining data from del.icio.us and flickr and googlebase, and other data sources is trivial

4. Content negotiation is the correct way of getting data from web servers the cost to the user is zero. The benefits are exponential (for instance a traditional Browser and associated industry politics no longer determines your ability to improve how you experience the Web).

[quote post="773"]Why to use two level of indirections, aka SPARQL AND HTTP query, asking for learning a new language (SPARQL) and generating “machine language styled” URL ?
Why not encoding IN THE URL the query with a simple GET ? With this you can be able to aggregate the “query/get”, the update/put and the create/post within the same token…[/quote]

Well yes. Take a look at that example. Is it what you are talking about?

One of the problem I can see with queries embedded into URL is: what do we do if the QUERY change? The URL will change too and this is bad in my point of view. See this method exactly as the same with server side programming language except that instead of using a programming language such as PHP, ASP, Ruby on Rail, etc, we use a SPARQL query to generate the data structure and then some other things to present data.

Also, embedding queries in URLs is not really what I call: cool URIs or nice URLs

[quote post="773"]Why not giving an URL both to “raw”� data, aka URL with no extension, AND to “formated”� data, aka URL appended with a “.”� operator ?
Thus, http://blabla.com/google can point to the noun “google”�, http://…/google.html could point to the html version, and tutti quanti
This could allow the client to choose the representation with the same explicit HTTP GET mecanism and not with some special opaque and equivoque “Content Negociation”� mechanisms.[/quote]

Well you are right. In fact, it could be another way to get data. Content Negotiation is preferred by the semantic web community, and personally I find that a much better way to get data in different formats. However I agree that it could be more convenient to some devleoppers, and more intuitive to others. I will send the suggestion to the OpenLink team working on that stuff.

Thanks for this comment, I hope that I will answer to your question, don’t hesitate to ask for precisions or other things.

Take care,

Fred

Quite interesting post about the decoupling of “data” and “representation”.

As you seem to know RDF and REST extensively, I have two questions :

Why to use two level of indirections, aka SPARQL AND HTTP query, asking for learning a new language (SPARQL) and generating “machine language styled” URL ?
Why not encoding IN THE URL the query with a simple GET ? With this you can be able to aggregate the “query/get”, the update/put and the create/post within the same token…

Why not giving an URL both to “raw” data, aka URL with no extension, AND to “formated” data, aka URL appended with a “.” operator ?
Thus, http://blabla.com/google can point to the noun “google”, http://…/google.html could point to the html version, and tutti quanti…
This could allow the client to choose the representation with the same explicit HTTP GET mecanism and not with some special opaque and equivoque “Content Negociation” mecanisms.

There is none: data shape is data format…. the only thing is that i remembered how I like the word “shape-shifter”, don’t ask me why please

And the content negotiation I am talking about is naturally what you are talking about: HTTP content negotiation! I am not re-inventing the whell here

Nah, the main idea to have in mind here is that everything start from a single saved sparql query: a sparql query get a URL, and that URL (that is the location of the saved sparql query on the web server) will return results of the query in many formats (shapes). And the most fantastic,is that it is already existing in Virtuoso

Thanks for your comment!

Take care,

Fred

Do you know about the Accept/Content-Type HTTP header fields? They appear to be designed for exactly the reasons you mention.

Kind regards,
Alex

P.S. The size of this comment area is proportional to the number of commnets you get. Think about it