RE: forthcoming new feature specs for LDF

On 2 Jul 2015 at 22:56, Ruben Verborgh wrote:
> Hi Markus,
> 
> I'll start with the most important thing:
> 
>> Would this replace the TPF spec?
> 
> Certainly not.
> 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? 


>> Do you intend to make some features required to define a least common
>> denominator between clients and servers?
> 
> That's not the intention at the moment.
> The common denominators are the features themselves.

The more features there are, the more combinations thereof exist, the less
likely it becomes that a client and a server will be able to fully
understand each other. Don't you think that might be a problem in practice?
Wouldn't it hinder adoption? Or at least make it much more difficult?


> Client are free, however, to demand more.
> For instance, if a client needs to solve a complex SPARQL query,
> but the server only offers substring search,
> then the client cannot complete the task.
> 
> 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.


>> Another nice weekend read. Could you please share a direct link to the
>> papers themselves as well?
> 
> The camera-ready versions aren't complete yet,
> we will definitely share once they are.

Yeah, please do even if this specific discussion is over at that point.


>> How do you intend to spec it? Would this replace the TPF spec? Or would
>> there be two additional specs?
> 
> It would be two (small) additional feature specs, and more could follow
later.

How would you call those two specs?

Probably a bit premature to discuss this but have you considered writing a
single feature spec instead? Also, do you intend to define different
conformance classes/products?


> The approximate membership metadata spec requires the server also
implements TPF.
> The substring feature is independent of other features.
> (However, to use substrings in complex SPARQL queries, the client also
needs TPF.)
> 
> 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.


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


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 6 July 2015 21:16:09 UTC