Re: Linked Data Platform - Next

On Sat, 18 Jul 2020 at 18:08, Aaron Coburn <acoburn@apache.org> wrote:

> I also work on Solid and have spent the last several years working with
> LDP.
>
> As such, I would echo a lot of what Melvin wrote (with only minor
> variations here and there). At a high level, the LDP specification has a
> lot going for it, but there are also some significant pain points,
> especially once you start adding authorization. I think it's fair to say
> that LDP, by itself, is reasonably easy to implement and interact with --
> if that's all you need, then you should be all set. It's when you begin
> layering other, orthogonal specifications onto LDP that you encounter some
> of these challenges.
>
> It may also be worth noting that, though Solid has historically been built
> on LDP, as the Solid specification moves toward 1.0, there is more of a
> loosely-coupled relationship to LDP. The current draft
> <https://solid.github.io/specification/> builds on (or is inspired by) a
> lot of the concepts of LDP, especially containment relationships; yet, LDP
> conformance is not -- strictly speaking -- required. In other words, one
> can build a Solid-conforming system on top of an LDP server, but one can
> also build a Solid-conforming system on top of a non-LDP server, so long as
> it understands RDF and REST semantics.
>

That is interesting.  Could you give a rough summary of hte potential
points of divergence?

>
>
> Cheers,
> Aaron
>
>
>
>
> On Sat, 18 Jul 2020 at 05:11, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On Thu, 16 Jul 2020 at 18:35, Eric Jahn <eric@alexandriaconsulting.com>
>> wrote:
>>
>>> Hello, we have integrated Apache Marmotta LDP into our human services
>>> data-centric platform.  What is the group's current consensus for the best
>>> future method for serving Linked Data restfully?  Is LDP a fully sufficient
>>> specification, and nothing more needs to be discussed :)  Or is there
>>> another method that competes with it, that better fulfills LDP's
>>> objectives? I know of Startin'Blox and Solid.  Thanks for the team's
>>> thoughts.
>>>
>>
>> Solid developer here
>>
>> More concretely, having worked with LDP on an hourly basis for the last
>> few years, I have encountered some pain points.  The hardest part is
>> supporting turtle.  This is ironic, as a long time turtle evangelist, I
>> think it enables you to write and think clearly in graph structures.  The
>> tooling around turtle is a tough ask, even for a believer.  It's a quite
>> large overhead and sometimes buggy.  The complexity of something gets much
>> bigger when dealing with multiple formats.  I have managed to make more
>> progress working with JSON(LD) and particularly so-called structured data
>> islands (which are not currently supported by LDP).  Turtle seemed a good
>> choice at the time, but JSON-LD seems to be well deployed on c. 100 million
>> domains and billions of pages now, mainly due to the benefit of server to
>> server SEO
>>
>> Timbl has often said that the goal of LDP is to "webize" the (UNIX) file
>> system.  To that extent, LDP has good options for performing CRUD
>> operations on resources, and also for listing a directory
>>
>> The obvious things missing are users and permissions, which is quite a
>> big task in itself.  There has been some incremental advancement there with
>> WebID and WebACL
>>
>> Continuing with the file system analogy.  In terms of functionality a
>> nice touch I think would to model the functionality of rsync, to replicate
>> or merge on LDP to another.  Most cloud systems do this, and LDP doesnt
>>
>> Lots of scope to improve LDP if you think about how file systems have
>> evolved and the functions and commands they allow.  Open question is
>> whether to put it all in one spec, or allow pluggable modules for different
>> features.
>>
>>
>>>
>>> Eric Jahn
>>> CTO/Data Architect
>>> St. Petersburg, Florida
>>> hslynk.com
>>>
>>