LDP argumentation

[Sergio Fernández <se...@salzburgresearch.at>]

Hi,

trying to understand the data and interaction model [1], the last two 
teleconferences of the Working Group at W3C have done nothing but 
confirm my suspicions: right now there are too many core decisions a bit 
undefined or unclear. Since joining the WG not from the beginning could 
be a problem to understand the background of some discussions, I'd like 
to focus this as something constructive rather than destructive. 
Therefore I'd like to discuss these issues with the Marmotta team, 
specially Andy and Nandana who are also involved in the WG, before send 
my questions to the mailing list.

Some key documents to read would be:

- LDP spec [2]
- LDP Uses Cases and Requirements [3]
- Composition vs. aggregation in LDPC (ISSUE-34 [4]) and a basic 
proposal [5]
- Data and interaction model (ISSUE-37 [6]) and some proposals [7]

So here a list of my main questions:

- First of all, fmpov the goal is too high-level defined (see the 
charter [8]), and this derives that it is hard to argue some key 
decisions, which is being conflictive when trying to find agreements 
with all members. Maybe my point of view is too close to my RWW 
experience, but I guess the current protocol is just a meta-protocol 
with some considerations.

- Unfortunately the use case and requirements do not address such issue. 
I don't know where the user stories come from, but definitely the uses 
cases do not cover the overall problem, I think, LDP will address. Maybe 
we can take a look on this document with more detail and contribute 
where we can clarify some details from the implementation point of view.

- Mixing the data model with the interaction model within a single 
formalism is confusing. For instance I agree that LDPC could be a 
subclass of LDPR, but I don't see where this benefits how to use the 
protocol to interact.

- For instance, I'm still figuring how Marmotta could distinguish 
between normal Linked Data resources and LDPR. I mean, we already 
implement our Read Write Linked Data interpretation, and I see some 
details which do not easily fit with a single endpoint implementation.

- There are three different perspectives of the same problem 
(triple-oriented, resource-oriented and graph-oriented) somehow rubbing 
between them. For instance, with the Graph Store Protocol in mind [9], I 
clearly see LDPC as a kind of special graphs with some restrictions in 
some properties, rather than a normal resource. But these limits or 
details fmpov are not clear at all.

Additionally I know we have some valuable extensions to propose 
(versioning and so on), but for the moment I'd prefer to keep it and try 
to focus the work at the WG.

Thank so much.

Kind regards,

[1] https://issues.apache.org/jira/browse/MARMOTTA-21
[2] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html
[3] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-ucr.html
[4] http://www.w3.org/2012/ldp/track/issues/34
[5] http://www.w3.org/2012/ldp/wiki/Issue-34:_Back_to_Basics
[6] http://www.w3.org/2012/ldp/track/issues/37
[7] http://www.w3.org/2012/ldp/wiki/ISSUE-37#Linked_Data_Platform
[8] http://www.w3.org/2012/ldp/charter
[9] http://www.w3.org/TR/sparql11-http-rdf-update/

-- 
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at

Re: LDP argumentation

[Peter Ansell <an...@gmail.com>]

On 29 January 2013 07:42, Sebastian Schaffert <ss...@apache.org> wrote:
> Hi Sergio,
>
> thanks for the summary. I agree mostly with your observation. I am trying
> to reply to some of the concerns as far as I can:
>
> 2013/1/28 Sergio Fernández <se...@salzburgresearch.at>
>>
>>
>> So here a list of my main questions:
>>
>> - First of all, fmpov the goal is too high-level defined (see the charter
>> [8]), and this derives that it is hard to argue some key decisions, which
>> is being conflictive when trying to find agreements with all members. Maybe
>> my point of view is too close to my RWW experience, but I guess the current
>> protocol is just a meta-protocol with some considerations.
>>
>
> While I agree that it is very high-level, there are fmpov only a few
> reasonable ways of implementing the charter, assuming you want to apply the
> concepts from Linked Data and REST in a sensible way. Sensible would mean
> you respect both, the REST ideas (stateless, POST, PUT, GET, DELETE in
> their proper semantics). One of these ways we already implemented (IMHO) in
> the web services of the LMF.
>
> Note that sensible is not always possible, because REST and Linked Data are
> not completely aligned in all cases. For example, the HTTP specification
> requires that if a client sends a POST or PUT and the server replies with a
> 303 redirect, the client should always follow-up with a GET. Which makes it
> kind of hard to apply the GET-redirect pattern of Linked Data also to
> updates.

I don't think this is a problem with REST. In my opinion, the sem web
people caused the issue by creating a new alternative semantics for
303 instead of creating a new 3xx code for their purpose. HTTP 303 was
originally specified as a way to give an unrelated redirection link
back to a user agent after a successful POST so they had a place to go
next, without attaching any semantic link between the 303 resource and
the redirect resource. Having a completely different semantic for 303
in response to GET doesn't make sense to me. However, they still
retroactively created the extra meaning in recent HTTP RFCs, so you
have to support it if you are following the standards.

Don't get too many people started on that one though. It is an
argument that just goes on and on and never has an end [1].

Cheers,

Peter

[1] https://en.wikipedia.org/wiki/The_Song_That_Never_Ends

Re: LDP argumentation

[Sebastian Schaffert <ss...@apache.org>]

Hi Sergio,

thanks for the summary. I agree mostly with your observation. I am trying
to reply to some of the concerns as far as I can:

2013/1/28 Sergio Fernández <se...@salzburgresearch.at>
>
>
> So here a list of my main questions:
>
> - First of all, fmpov the goal is too high-level defined (see the charter
> [8]), and this derives that it is hard to argue some key decisions, which
> is being conflictive when trying to find agreements with all members. Maybe
> my point of view is too close to my RWW experience, but I guess the current
> protocol is just a meta-protocol with some considerations.
>

While I agree that it is very high-level, there are fmpov only a few
reasonable ways of implementing the charter, assuming you want to apply the
concepts from Linked Data and REST in a sensible way. Sensible would mean
you respect both, the REST ideas (stateless, POST, PUT, GET, DELETE in
their proper semantics). One of these ways we already implemented (IMHO) in
the web services of the LMF.

Note that sensible is not always possible, because REST and Linked Data are
not completely aligned in all cases. For example, the HTTP specification
requires that if a client sends a POST or PUT and the server replies with a
303 redirect, the client should always follow-up with a GET. Which makes it
kind of hard to apply the GET-redirect pattern of Linked Data also to
updates.

Another problem (and this is apparently where the LDP group is also still
discussing) is that REST is resource centred while RDF is triple centred.
Conceptually not a big deal, but makes a serious difference in interaction.

And the third problem is for me named graphs. Since they are underspecified
so far in RDF (datasets upcoming only in RDF1.1), people apparently come up
with many similar but slightly different ideas. Personally, I don't
understand the difference between a container and a named graph.

For me, these are the three basic questions to bring into the working group
if they have not yet discussed them. :)



>
> - Unfortunately the use case and requirements do not address such issue. I
> don't know where the user stories come from, but definitely the uses cases
> do not cover the overall problem, I think, LDP will address. Maybe we can
> take a look on this document with more detail and contribute where we can
> clarify some details from the implementation point of view.
>

Yes. I have the opinion that everyone who writes a spec on software also
must be a programmer. :-)



>
> - Mixing the data model with the interaction model within a single
> formalism is confusing. For instance I agree that LDPC could be a subclass
> of LDPR, but I don't see where this benefits how to use the protocol to
> interact.
>

Maybe this is related to the second problem I mention above. Maybe if
making the problem itself clearer, it will also become easier to separate
these concerns.


>
> - For instance, I'm still figuring how Marmotta could distinguish between
> normal Linked Data resources and LDPR. I mean, we already implement our
> Read Write Linked Data interpretation, and I see some details which do not
> easily fit with a single endpoint implementation.
>

Can you point me to the single endpoint solution? I don't understand the
issue at the moment. :-)


>
> - There are three different perspectives of the same problem
> (triple-oriented, resource-oriented and graph-oriented) somehow rubbing
> between them. For instance, with the Graph Store Protocol in mind [9], I
> clearly see LDPC as a kind of special graphs with some restrictions in some
> properties, rather than a normal resource. But these limits or details
> fmpov are not clear at all.
>
> Additionally I know we have some valuable extensions to propose
> (versioning and so on), but for the moment I'd prefer to keep it and try to
> focus the work at the WG.
>

I agree. Also, if we have features we consider important that are not in
the LDP draft, or if we have different opinions about how to properly do
some things, I think we should do them as we think (and maybe have a
"compatibility" option in the configuration). There are many examples of
specifications being refined after-the-implementation, e.g. JPA stemming
mostly from Hibernate. :)

Greetings,

Sebastian