RE: forthcoming new feature specs for LDF

On 7 Jul 2015 at 00:16, Ruben Verborgh wrote:
>>> 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.

OK, I see. Makes sense.


>> 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.

This part worries me a bit but let's see how it turns out. I still need to
read the papers :-/


>> 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.

Because I'm afraid that clients will cut corners and not implement all
pieces.


> It can even just understand part of the pieces and use those.

In some cases, yes. I'm not sure yet whether this can be generalized.


[...]

>>> 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?

If you know that servers never support FILTER REGEX(?literal, "abc")
efficiently, you wouldn't build an application that executes the query
above. If you do happen to develop against a server which does and then
later move to a server which doesn't, your app basically breaks as it would
need to retrieve every single triple and then execute the regex locally. For
developers not knowing the whole stack in detail that might be very
surprising and hard to debug.


> 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,

Solving it with just TPF would be impractical for large datasets.


> 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

I assume that is just part of the title, right? No need to discuss this now
though if you haven't decided it yet.


>> 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.)

I'd say they are independent but not unrelated. Depending on how long those
specs turn out to be it might make sense to keep those features in a single
document. Let's defer this discussion till we have something concrete to
look at.


>> 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.)

Cool. Thanks a lot for your patience and for pushing this forward!


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 8 July 2015 19:47:37 UTC