Dear Qihong Lin,
continue working hard towards achieving the goals of the project. The
sooner the better for testing and commenting your work, even implement
missing features.
Thank so much.
Cheers,
On 02/07/14 13:15, Qihong Lin wrote:
Dear Sergio,
I've just translated all of the methods into SPARQL implementations,
and committed the code. I'll watch the upstream, in case new methods
or modifications are coming. It's actually ahead of the original plan.
Thanks for sharing your opinions of my current work. In the next
weeks, I'll resolve the problems you pointed out (i.e. tests,
documentations, code abstractions and evaluations). Basically, I think
everything is going on well until now. I'll turn to you for help, if
there's any further question. Thanks a lot!
Cheers,
Qihong Lin
On Tue, Jun 24, 2014 at 8:32 PM, Sergio Fernández <wik...@apache.org> wrote:
Hi Qihong Lin,
it's the mid-point of the GSoC programme, so it's a good time to assess the
state of the project. It looks close to the plan and I'd like you to
(briefly) write-up how the project is going. Check you are getting what you
want out of the project as well. It is not just code production. Is the rest
of the plan looking right still?
Looking on at the repository forked at github:
https://github.com/confidencesun/marmotta/tree/MARMOTTA-444
besides the few comments I did on your commits, there are a few things I'd
like to discuss:
* Working plan: concrete details about how your work is actually following
(or not) the proposed working plan.
* Implementation feedback: which in the end may revert to the overall
quality of the project. For instance, looking to the current status of your
implementation http://s.apache.org/7mn I could expect that you should be
able to propose the usage of an abstract base implementation with some
commons things.
* Method documentation: document how you translate the Sesame native call to
SPARQL queries will help to maintain the alternative implementation
* User documentation: how to launch Marmotta using your implementation,
example requests, etc.
* More testing: I know you are moving on a very unknown area, but the more
tests you write the best for discovering issues (specially lateral effect of
related code). The official LDP Test Suite would be a helpful resource.
* Evaluation: for example, regarding performance: on the typical scenarios,
do you have some figure in the deviation in comparison with the main
implementation?
And I think that's all...
Remember that you can use the github wiki to write down whatever stuff you
need. Documentation is always good.
But so far my overall impression for this checkpoint is that you are in the
right path.
Thanks.
Cheers,
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernan...@redlink.co
w: http://redlink.co
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernan...@redlink.co
w: http://redlink.co
