- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Fri, 6 Nov 2015 11:48:40 +0100
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-linked-data-fragments@w3.org
>> Usually, one can implement tests like:
>> look for _this_, then check that and that.
>> But since the controls can have various shapes,
>> the _this_ can be hard to recognize
>> without performing the checks first.
>
> I see. Makes sense. Sometimes people suggest to require explicit typing of
> resources to simplify that. What's your take on that?
My opinion: it simplifies because it doesn't scale.
It works for TPF. It works for an extension of TPF.
It might even work for two extensions of TPF. But that's it.
I don't believe in APIs a atomic building blocks,
where you can simply type "this is a TPF response".
I see APIs as being composed of features,
some of which a client might know, others which it ignores.
So more like: "you can query by triple pattern",
"you can also perform full-text search on objects",
and "I support jumping to arbitrary pages".
We should not strive to have identifiers for all those cases,
but rather explain in-band to a client what those cases are.
When in doubt, I always look at the human Web.
A control's functionality is not explained with a label ("this is a search box"),
but rather by its affordance (this looks like something that lets me search).
As it turns out, making servers that enable clients to be intelligent
might be harder than making servers that are intelligent,
certainly to test. But that shouldn't stop us :-)
Cheers,
Ruben
Received on Friday, 6 November 2015 10:49:10 UTC