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 <[email protected]> > > > 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
