Dear Sergio, Your feedback is very valuable. Thank you! I've modified the proposal according to your suggestions. Here's the short description inline. Any other suggestions are very welcome.
On Tue, Mar 11, 2014 at 4:22 PM, Sergio Fernández <wik...@apache.org> wrote: > Hi Qihong Lin, > > > On 11/03/14 04:38, Qihong Lin wrote: > >> Thank you! I saw your update of MARMOTTA-444 on the new deadline of 31 >> July. >> I just submitted my proposal [1] to the GSoC website, with a project plan >> conforming to the deadline. Any comments are welcome! >> > > Great! > > Taking a quite look to your proposal, there are some points you could > improve: > > * References 5 and 6 could be mentioned together as SPARQL 1.1. It is not > expected to work with SPARQL 1.0, that's something you could stand out. > The references of 5 and 6 have been merged to SPARQL 1.1. Also, I change the project title to highlight SPARQL 1.1. Hope it helps. > > * Performance Improvement: that's not true at all, because all pending > operations are performed at commit time. And I don't expect performance > would be better in this alternative implementation, we're aware of it. > * Instead you could add something about portability, since SPARQL is the > official recommendation for accessing RDF stores (Sesame is just the > de-facto standard for Java). > Yes, I'm just aware of that. This performance improvement part has been removed from the proposal, replaced by the portability significance. Thanks for pointing it out. > > * LdpService definition is still evolving. So I'd not refer the delivery > of concrete methods in the work plan, but functionalities (container > creation, resource addition, resource deletion, etc) instead. > > * Although I understand that reading operations could be easier for > starting, in the end data creation needs to be in place before reading. So > FMPOV you would have two options: a) group by target (resource, container, > etc.) instead of operation type (exist, read, write, etc.) b) keep it as it > is, and start with a service skeleton where all methods call the default > implementation until you provide your actual implementation of each. I'd > prefer the first, but the second is completely valid and probably the most > convenient one for you. > > * But for the mid-term evaluation I'd like to have some writing > capabilities already in place, not only reading ones. > I agree with you. The project plan is now grouped by the targets (i.e. resource, container, etc) and their functionalities. According to the new plan, you can assess both the reading and writing capabilities of resource in the mid-term evaluation. > > * For storing binary resources, or more precisely "LDP Non-RDF Source", > you could use the same service the default implementation uses, SPARQL is > not capable of that. > > * I like that you assert that each concrete milestone would come with > tests. > > So far, the proposal looks good for me. Thanks for your effort. > > > Cheers, > > -- > Sergio Fernández > Senior Researcher > Knowledge and Media Technologies > Salzburg Research Forschungsgesellschaft mbH > Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria > T: +43 662 2288 318 | M: +43 660 2747 925 > sergio.fernan...@salzburgresearch.at > http://www.salzburgresearch.at > Cheers, Qihong Lin
