Re: Linked Data Platform - Next

Hi Melvin, I'll give two examples:

First (related to authZ), if you have a strictly conforming LDP server,
section 4.2.8 HTTP OPTIONS requires advertising certain headers related to
capabilities of a resource. This is fine for public resources, but if you
have authZ enabled *and* you are concerned about privacy *and* if you are
using JavaScript based web clients, you will need to support CORS -- but
CORS preflight requests don't send auth headers so you either disclose
information about the resource at that URL (in order to conform to LDP) or
you just respond with a static (fixed) response that is the same for all
URLs (in order to support CORS).

Second (related to the FS analogy mentioned earlier): Solid puts a lot of
emphasis on the semantics of slashes in URLs (e.g. containers always end
with slashes), which means the LDP interaction model can be derived from
the other parts of a request, rather than from client-supplied Link
headers. This (arguably) simplifies the client-server interaction, since
clients no longer need to supply explicit link headers when creating
resources; the idea here is that HTTP clients already supply a request URL
and Content-Type and web developers are (arguably) more familiar with those
compared to link headers. This also means that, when building Solid on top
of LDP, the server can accept an explicit interaction model, but if one
isn't present, a server-level filter can derive one from other information
in the request. And since Solid only uses basic containment, there are
really only three relevant interaction models: LDP-RS, LDP-NR and LDP-BC.

I'm sure there are other areas, but those two came immediately to mind.

-- Aaron







On Sat, 18 Jul 2020 at 12:40, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

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