Add field for SPARQL queries to HTML-dialog

[akuckartz]

The current HTML-dialog includes fields for subject, predicate and object. It also should include a field to submit SPARQL queries as in this HTML-dialog: http://client.linkeddatafragments.org/

[rubensworks]

The server is not really meant to be interacted with by end-users, for this the client exist.

The next release of the server will however be more modular, so it would be easy to create a "SPARQL view" extension, that simply enhances the server view with client-side SPARQL queries.

[RubenVerborgh]

• For me, it is of utmost importance that people understand it conceptually—even more than usability, since this is foremost a technical interface. Having a SPARQL interface within a fragment would make them really confused about what TPF really is and where what happens. So I'm in favor of keeping them separated.

• That said, I think we should make the server “skinnable”. Right now, it looks into the views folder, but through configuration, people should be able to point to their own views. And these views might very well include a client. So while I don't want the client in the default view, they might be in other views.

• Part of this is also to avoid a circular dependency, i.e., the server depending on the client, which uses the server.

[mielvds]

I agree with not having this, at most we can add a link to http://client.linkeddatafragments.org

[akuckartz]

@rubensworks @RubenVerborgh @mielvds I tend to disagree with parts of your answers.

• Users and developers do interact with the HTML interface. The more usable and powerful it is the better.
• I think that usability and understandability of the technology are orthogonal here. Usability helps to demonstrate the power of the technology. Crippling that power does not help. I would make the most powerful view the default.
• Adding some text like "There is no SPARQL engine running on the server, here you see something using the power of TPF in action!" might help.
• The dependency is not circular, the two dependencies are of a different kind.

But being able to easily configure a non-default SPARQL view will certainly help me, so I appreciate that very much. (It can be made the default later :-)

[mielvds]

I get your arguments, they indeed make sense from a user perspective. In fact, we already do this on fragments.dbpedia.org.

My concern is still that TPF is a multi-client / multi-server setup. If we tie a client to a server in any de-facto way, we confuse people. Especially because most SPARQL endpoints provide a similar looking query interface. Probably we have to add an explanation "the client not being tied to the server, but can be used to query any server, just like this server can be queried by a different client", which will be overlooked. It's not only about usability, we also want people to get it.

[RubenVerborgh]

@akuckartz

Users and developers do interact with the HTML interface.

No, only devs do :-) This is a technical interface. Users do not know SPARQL and will interact with an application, which happens to use the LDF client internally.

Usability helps to demonstrate the power of the technology.

We're talking about usability toward devs here, and for devs, I think it will ultimately be clearer to see the separation between data interface and query client. I wouldn't be opposed to add a link to the query client on the default view though.

But being able to easily configure a non-default SPARQL view will certainly help me,

Great, tracking progress in #62.

[rubensworks]

Considering this resolved, please comment should this not be the case.