solid-spec
solid-spec copied to clipboard
solid
search via query does not have a follow your nose process
The new section suggestion to use a query does not have a follow-your-nose process of discovery. How is a client meant to know which url to use to send a query to? What should the language of that query be? Should it be POST or GET? What are the interactions?
The advantage of SEARCH or GET + Query as described by issue #4 - and as proposed in the initial SoLiD spec was that it was easy to use the patterns already expressed by LDP to show what features are available.
The so-called "initial spec" had a poorly written example for Reading data using SPARQL. It was never intended to be a GET + Query as you describe it in #4. The query string was part of the URL.
Well now it suffers from the problems listed above, that it is not clear how a client would know that it can send such a query, nor what type of query to send. You are requiring out of band knowledge of a client interacting with a server, and that is not practical in a LinkedData world where a client is following relations from one server to another and could end up anywhere on any server.
As I mentioned in #34, while there is currently no "follow your nose" mechanism to advertise per resource query support, I hope that will fix this issue in LDP Next by defining a way to advertise server support.
The LDP group is meeting in Prague to discuss SEARCH at the IETF HTTP WG meeting. There seems to be at least IBM, Oracle, and others behind that idea, and it is easy to envisage how to advertise capabilities there.
In any case this feature is not useable without such a way for a server to indicate its support. So please leave this issue open until that is resolved, as it needs to be tracked.
There are no current plans to add a SEARCH method to SoLiD. Hopefully, the LDP CG will discuss this in the near future.