- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Tue, 7 Jul 2015 00:16:09 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-linked-data-fragments@w3.org, Miel Vander Sande <Miel.VanderSande@UGent.be>, Joachim Van Herwegen <Joachim.VanHerwegen@ugent.be>, Laurens De Vocht <Laurens.DeVocht@UGent.be>
Hi Markus,
>> Think of it as the machine equivalent of UI controls / widgets.
>> One spec defines autocompletion, the other defines a search bar,
>> yet another defines a people tagging control.
>
> To be honest, I find that a slightly misleading analogy as that causes
> people to focus on the design and the UX. A better one (IMO, anyway) would
> be to compare that to SQL - or SPARQL for that matter. What we define here
> are query operators.
Actually, UI controls are really the better comparison here.
UI controls combine lower level hypermedia controls
to provide a recognizable interface, in that case for users.
Here are some of those implicit/explicit UI controls:
– clicking the top logo brings a user to the home page
– clicking a share button allows to send content through a social media account
– typing text in an autocomplete control gives suggestions of expected input
Apart from a visual control, they provide an interface
through which users can interact with the web application.
The idea is to do the same with these specs:
combine lower level Hydra constructs
to higher level controls that are reusable.
They are not necessarily query operators;
for instance, the metadata spec we intend to write
would be very hard to express as a query operator.
>> The TPF spec also defines a feature, and quite an important one.
>> This spec will remain as-is, and it will remain an important building
>> block for APIs.
>
> OK. So the plan wouldn't be to rewrite it so that it is defined as a
> specific set or combination of features?
No, TPF is a feature itself.
"Feature" can be interpreted as sub-API,
i.e., part of the total API a server decides to offer.
> The more features there are, the more combinations thereof exist
That's right; and in our opinion, it is much more meaningful to define such features
then to define all “interesting” combinations up front,
because we don't know which features a server would like to combine.
(Just like we don't know which UI controls a Web app would like to combine.)
> the less
> likely it becomes that a client and a server will be able to fully
> understand each other.
Why would that be? If the client understands the pieces, it understands the whole.
It can even just understand part of the pieces and use those.
Again, similar to UI controls: you use the ones you know but disregard the others
(or figure out how the others work if you're really intelligent as a client).
> Don't you think that might be a problem in practice?
> Wouldn't it hinder adoption? Or at least make it much more difficult?
I would thus say quite the contrary.
If we add features to an existing TPF API,
TPF clients will still be able to use it,
because the interface is totally self-descriptive.
Let's say that a server wants to provide TPF + substring search.
In the feature-based way, it offers those two features to a client
and indicates them as such through hypermedia controls (API 1).
If we don't do features,
we have to define a new API that has TPF + substring (API 2).
The first API can be consumed by TPF clients,
the second one cannot, because it's a different API.
The first API can also be consumed by substring clients,
but not the second one.
Only clients that can consume both TPF and substring
would be able to use the first and second APIs alike.
>> However, the client might solve simple queries with this interface, such
> as:
>> SELECT ?literal {
>> ?s ?p ?literal.
>> FILTER REGEX(?literal, "abc")
>> }
>> as this can be evaluated using only substring search.
>
> Yep. That would mean, however, that the application on top of such a client
> library would need to be adapted. That's something we would like to avoid at
> all cost in general.
I don't really follow, why would the application on top of the client be adapted?
The application communicates to the client library, “solve me this query”:
SELECT ?literal {
?s ?p ?literal.
FILTER REGEX(?literal, "abc")
}
The client library then either solves this query with TPF,
with the substring API, or with TPF + substring API,
depending what is available on the server side.
> How would you call those two specs?
– Substring Search
– Approximate Membership Metadata
> Probably a bit premature to discuss this but have you considered writing a
> single feature spec instead?
The two features are entirely unrelated,
even though they work perfectly fine in conjunction.
(The comparison of autocomplete control + share widget is appropriate here.)
> Also, do you intend to define different
> conformance classes/products?
Just compatibility with the individual features at the moment.
(Considering writing test suites for conformance as well, also for TPF.)
>> But they can all be used together, and depending on what is present
>> the client/user can or cannot do certain things (more efficiently).
>
> Right. Those features allow us to move along the spectrum from static dumps
> to fully featured SPARQL endpoints.
Absolutely! And servers can decide themselves just how far they go.
Best,
Ruben
Received on Monday, 6 July 2015 22:16:42 UTC