Re: TPF and DBMSes (was Re: Hydra and Shapes)

On 11/26/14 5:17 PM, Markus Lanthaler wrote:
> Hi Kingsley,
>
> On 26 Nov 2014 at 00:15, Kingsley Idehen wrote:
>> On 11/25/14 2:49 PM, Ruben Verborgh wrote:
>>>> In addition, what would constitute the SPARQL endpoint, in this
> scenario?
>>> There is no notion of "SPARQL endpoint" in the context of triple pattern
> fragments.
>>> This is on purpose; only simple questions (= triple patterns) can be
> asked to servers.
>>>> By that I mean: an endpoint to which SPARQL-FED queries could be
> directed?
>>> Federated SPARQL queries over triple pattern fragment interfaces
>>> should be solved using a federated triple pattern fragments client.
>> Yes, but can't you see I am trying to line things up with standards
>> parts of SPARQL?
>>
>> You position this work in the context of SPARQL, but many of the virtues
>> of SPARQL, are not there.
> When we talk about Linked Data Fragments and SPARQL we always try to make it
> very clear that LDFs aren't a replacement for SPARQL engines.

I am not responding to "LDFs as SPARQL replacement" notion. I am 
responding to "LDFs is SPARQL compliant" notion, which is currently 
confusing.

> Neither have
> SPARQL engines been a replacement for static file servers.

SPARQL engines always works with documents. These documents may be 
tightly or loosely coupled with other aspects of the engines in 
question. Conflating DBMS and Databases is an eternal industry problem 
that RDF and SPARQL actually alleviates.

Bottom line, it isn't about static file servers. Its about state of data 
accessible (to a client) from a document location provided by different 
kinds of servers supporting  different kinds of interaction protocols.


> Traditionally,
> however, there hasn't been anything in between those two "extremes". LDF
> tries to fill that gap. This slide illustrates this quite nicely I think:
>
>   
> http://www.slideshare.net/lanthaler/why-and-how-to-optimize-your-data-archit
> ecture-for-an-integrated-future/36

See my comment about conflating database management apps and database 
documents. That's a cleaner definition of the problem.

You have data (accessible from a document) in fixed or volatile state, 
each has implications.

>
> (AFAIK, Ruben includes a similar illustration in his talks about LDFs)
>
> Currently we only have Triple Pattern Fragments (TPFs) in there but the goal
> is to create a whole spectrum. I personally am most interested in LDFs that
> look very similar to current JSON-based Web APIs... even though that will
> mean that some queries might be *extremely* inefficient or impossible
> (without crawling the entire API).
>
> I hope this clarifies matters a bit

My concern is really about the notion of SPARQL compatibility. 
Basically, the narratives around TPFs, LDF, and SPARQL remain confusing, 
but I'll try to straighten some of this out, in due course, with actual 
examples.

I believe in mutual inclusion, and have no interest in mutual exclusion. 
The Web is inherently lego-like, and I simply want to do my best to 
encourage everyone to keep it that way, as best I can.


>
>
> Cheers,
> Markus
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>


-- 
Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this