Re: Linked Data Platform - Next

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.

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