You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Oshani Seneviratne <os...@apache.org> on 2007/03/24 03:44:00 UTC
Google Summer of Code project
Hi Devs,
I am interested in doing the SoC project on 'Creating plugins for
embedding/producing RDF/XML and microformats in Forrest content
objects'. My proposal is available at [1] and I would love to hear any
of your comments on that.
[1] http://wiki.apache.org/general/OshaniSeneviratne/GSoC2007/proposal
Thanks and Regards,
Oshani
Re: Google Summer of Code project
Posted by Ross Gardler <rg...@apache.org>.
Oshani Seneviratne wrote:
> On 3/27/07, Ross Gardler <rg...@apache.org> wrote:
>> [The following comments will appear to some people, from some cultures,
>> including my own, to be rude, nobody likes talking about money. I hope
>> you understand that I do not mean to offend you, or anyone else]
>>
>> You can get all that without the GSoC money.
>
> Yes true!
> For a student like me, money is also a very big incentive to do GSoC.
> However, it's not the *only* thing I expect to gain by participating.
:-)
Thanks for understanding and indulging my question.
>> Have you been active within Woden since GSoC 2006?
>
> I was very active in Woden during GSoC and even after - until the
> Milestone 6 release in October last year, which incorporated most of
> my contributions. Since then I was not able to commit a lot of my time
> to contribute to Woden due to university work (which would be over by
> June this year!).
Fair enough, as a volunteer you do what you can.
Thanks for your feedback and clarification of the points I've raised.
Ross
Re: Google Summer of Code project
Posted by Oshani Seneviratne <os...@apache.org>.
On 3/27/07, Ross Gardler <rg...@apache.org> wrote:
> [The following comments will appear to some people, from some cultures,
> including my own, to be rude, nobody likes talking about money. I hope
> you understand that I do not mean to offend you, or anyone else]
>
> You can get all that without the GSoC money.
Yes true!
For a student like me, money is also a very big incentive to do GSoC.
However, it's not the *only* thing I expect to gain by participating.
> Have you been active within Woden since GSoC 2006?
I was very active in Woden during GSoC and even after - until the
Milestone 6 release in October last year, which incorporated most of
my contributions. Since then I was not able to commit a lot of my time
to contribute to Woden due to university work (which would be over by
June this year!).
>
> Did you consider looking through ASF projects *prior* to GSoC 2007 for
> things that will fire up your interest in the semantic web and
> contributing as an existing ASF committer?
>
The ASF projects that I have some experience in (Woden and Axis2) are
not really focussed on the Semantic Web. So, I directly didn't see an
opportunity there, although I would have loved to contribute.
Anyway, I suppose the answer to your question is 'no'.
However I should mention that I did look for projects outside ASF
prior to GSoC 2007, such as the Tabulator and PAW(Policy Aware Web) at
DIG which are based on semantic web concepts.
Oshani
Re: Google Summer of Code project
Posted by Ross Gardler <rg...@apache.org>.
Oshani Seneviratne wrote:
> Ross,
>
> Thanks a lot for all your comments!
>
> I have revised my proposal [1] a bit based on your suggestions and it
> is yet again open for review. Please note that I did not change some
> of the things, which I have certain doubts about on implementing.
> However, based on your advice I am willing to change the proposal once
> again.
>
> As for the questions you raised, please see my comments inline.
>
>
> On 3/25/07, Ross Gardler <rg...@apache.org> wrote:
>> The reason I ask is that there is already a DOAP plugin in the
>> whiteboard which is reasonably functional (and a little buggy). It works
>> with both the skins and the dispatcher and may serve to act as a
>> template for how your plugins will look. Then again, you may decide it's
>> not quite right.
>
> Actually I was unaware of the DOAP plugin! So during the last couple
> of days, I tried to play with it a bit and learn how it works.
> Unfortunately, I was not able to get it working with a custom DOAP
> file. So, any points or links for documentation regarding this would
> be appreciated.
It's whiteboard, therefore no community or documentation at this stage.
Bring your specific questions to this list and I'll answer them and/or
start documentation efforts.
>> I like the idea of focussing on a FOAF plugin and using that to gather
>> community feedback. I note that you have assigned a considerable amount
>> of time to this, but provide very little information about what we can
>> expect this plugin to do. For example, is it simply going to transform a
>> FOAF file to XDoc or will it also include a number of indexes generated
>> from the available FOAF files?
>>
>
> I imagined the FOAF plugin to generate the HTML view of the FOAF data.
> However as you suggested we could also generate indexes. What I
> understood by these 'indexes', is for example, to use FOAF 'knows'
> relationship and give a structural view for the data in the xdocs. Is
> that what you meant? If not, please do correct me.
That is precisely what I meant. In the context of the DOAP plugin we
have indexes based on category or language, for example.
>> I'm particularly interested in producing JSON output to enable the FOAF
>> data to be viewed with Exhibit (from Simile at MIT). I've started to do
>> this in the DOAP plugin, but it is incomplete as other things have got
>> in the way. Would you be interested in adding this kind of functionality
>> (or finishing it in the DOAP plugin)?
>>
>
> Yes, I also like idea. IMO, producing JSON output off a FOAF will not
> be a problem. However, I am not that clear about the relationship
> between viewing it in Exhibit and using JSON output with Forrest.
> Could it be that you would want the Exhibit like look-and-feel with
> Forrest? Or did you mean something else?
Exhibit is, essentially, a small Javascript application that enables the
JSON content to be filtered and presented using AJAX. I've not spent any
time exploring exactly how this would work out, but we'll find a way ;-)
I suspect it will be pretty simple using the dispatcher, but fairly
complex using skins. Therefore, this would probably be a dispatcher only
feature.
> With a bit of clarification on this, I am very much interested in
> doing this for the FOAF as well as for the DOAP plugins.
No problem, I'm happy to work with you both as mentor and as a community
member. However, given our current drive to a 0.8 release I am unlikely
to focus on this until after the code freeze for the release (which is
all over before GSoC starts).
>> For my personal use case I need the plugins to be implemented using the
>> Dispatcher, but for Forrest 0.8 release we need the code to be
>> compatible with skins. Fortunately it's easy to do this (see the DOAP
>> plugin for an example). It is not a requirement of the project to create
>> Dispatcher code, in fact, I would be tempted to say that it may be
>> better to leave that for the community, thus reducing your learning
>> curve. However, if you are already confident with dispatcher or want to
>> learn it that would also be fine. Can you please make a note in your
>> application indicating what you preference will be (this is for
>> evaluation purposes later in the project).
>
> Well, since I am a newcomer to Forrest, I would like to try out with
> the skins first.
> I would also like to learn about Dispatcher and fulfill your use case.
> But at this point I am not so sure of the scope involved. So, I would
> take the safe option and not promise to create the dispatcher code.
That would impact the JSON stuff, as I say neither the JSON nor the
dispatcher implementations are necessarily part of this project. It's up
to you to scope it. Clearly, if you went this route you would implement
fewer plugins. Knowing in advance what you want to achieve helps me as
a mentor when it comes to evaluation. Of course, things can change once
you get started.
>> One of the goals of GSoC is to introduce new people to the ASF and how
>> it works. It appears you do not need this introduction. Can you tell me
>> why you feel you should be selected again? What do you feel a second
>> year in GSoC will give you? (it is well worth putting this into your app
>> as they are rated by the ASF community as a whole, not just the Forrest
>> community).
>
> Well, I really like challenges, and GSoC to me in a way, is a big
> challenge. I liked doing it last time and I guess I was naturally
> drawn to it this time as well. And yes, you are right.. I don't need
> an introduction, but I suppose I have lots more to learn! So, I
> consider this as a wonderful opportunity to learn new things, test my
> skills, interact with a new community and finally deliver something
> useful.
[The following comments will appear to some people, from some cultures,
including my own, to be rude, nobody likes talking about money. I hope
you understand that I do not mean to offend you, or anyone else]
You can get all that without the GSoC money.
Have you been active within Woden since GSoC 2006?
Did you consider looking through ASF projects *prior* to GSoC 2007 for
things that will fire up your interest in the semantic web and
contributing as an existing ASF committer?
>> How do you propose managing your commitments to GSoC and your work on
>> your final exams?
>
> Hmm.. tough one :)
Thanks for your candid responses.
Ross
Re: Google Summer of Code project
Posted by Oshani Seneviratne <os...@apache.org>.
Ross,
Thanks a lot for all your comments!
I have revised my proposal [1] a bit based on your suggestions and it
is yet again open for review. Please note that I did not change some
of the things, which I have certain doubts about on implementing.
However, based on your advice I am willing to change the proposal once
again.
As for the questions you raised, please see my comments inline.
On 3/25/07, Ross Gardler <rg...@apache.org> wrote:
> You have scheduled a whole week for "Design for plugins". Can you expand
> on exactly what you think this design will contain.
>
Actually, I've allocated more than a week for this task. Bulk of this
time is to learn about Forrest plugin development.
Although I've put the 'designs for plugins' as a deliverable, it will
be basically something to guide me during the implementation phase
later. This 'design' should ideally decide on the sort of xsl
transformations needed by each plugin.
> The reason I ask is that there is already a DOAP plugin in the
> whiteboard which is reasonably functional (and a little buggy). It works
> with both the skins and the dispatcher and may serve to act as a
> template for how your plugins will look. Then again, you may decide it's
> not quite right.
Actually I was unaware of the DOAP plugin! So during the last couple
of days, I tried to play with it a bit and learn how it works.
Unfortunately, I was not able to get it working with a custom DOAP
file. So, any points or links for documentation regarding this would
be appreciated.
> I like the idea of focussing on a FOAF plugin and using that to gather
> community feedback. I note that you have assigned a considerable amount
> of time to this, but provide very little information about what we can
> expect this plugin to do. For example, is it simply going to transform a
> FOAF file to XDoc or will it also include a number of indexes generated
> from the available FOAF files?
>
I imagined the FOAF plugin to generate the HTML view of the FOAF data.
However as you suggested we could also generate indexes. What I
understood by these 'indexes', is for example, to use FOAF 'knows'
relationship and give a structural view for the data in the xdocs. Is
that what you meant? If not, please do correct me.
> I'm particularly interested in producing JSON output to enable the FOAF
> data to be viewed with Exhibit (from Simile at MIT). I've started to do
> this in the DOAP plugin, but it is incomplete as other things have got
> in the way. Would you be interested in adding this kind of functionality
> (or finishing it in the DOAP plugin)?
>
Yes, I also like idea. IMO, producing JSON output off a FOAF will not
be a problem. However, I am not that clear about the relationship
between viewing it in Exhibit and using JSON output with Forrest.
Could it be that you would want the Exhibit like look-and-feel with
Forrest? Or did you mean something else?
With a bit of clarification on this, I am very much interested in
doing this for the FOAF as well as for the DOAP plugins.
> Are you familiar with Forrest already? If not, do you think you can
> grasp what you need to in the time allocated to the first plugin
> deliverable? What approach will you use for getting up to speed with
> Forrest? (don't worry, we are not necessarily looking for people with
> existing Forrest skills)
Development wise obviously I am a total new-comer to Forrest. However
I have used Apache Forrest in building the Apache Woden site couple of
times. That "user" level experience of course is not that much.
However, I believe I could grasp all what is needed and get up to
speed with Forrest by May 31st.
I have already gone through most of the documentation which is
available in the Forrest site, and hope to dive *deep* in to the code
soon! I hope that there will NOT be a huge learning curve and
hopefully with the help of the Forrest community I should be a very
well proficient in Forrest by the end of this project :).
> How did you come across Forrest and why what interests you about this
> GSoC project?
For GSoC, I came across Forrest in the ideas page for ASF.
This project interests me because I believe that it would give me an
opportunity to do an implementation based on the things I have learnt
(FYI, recently I did some considerable study on these various RDF
formats). Also, since I am planning on doing research on Semantic Web
for my grad studies, doing this project would personally help me a lot
in that as well.
> I *love* that you are planning on creating test code for the plugins.
> This is something we do not do enough of in Forrest. There are a number
> of problems with doing tests for Forrest outputs, you may find some
> useful info in a dev archives. Can you provide an outline of how you see
> these tests working.
For the XSLT code, I would first write valid and invalid xml documents
and test those against the XSLT code to see whether it would generate
the desired output. These will act as the examples I mentioned in the
proposal.
In the documentation, I saw that using WebTest is recommended for
testing during plugin development. Although I haven't used that
framework before, I thought it would be a very good opportunity to
learn and use WebTest.
> It is also worth pointing out that plugins are expected to be documented
> in such a way that the plugin docs themselves are a test case. That is
> they test all functionality.
Yes, I saw how this is done for the projectInfo plugin using use
cases. I believe the similar thing could be done with these plugins as
well.
> For my personal use case I need the plugins to be implemented using the
> Dispatcher, but for Forrest 0.8 release we need the code to be
> compatible with skins. Fortunately it's easy to do this (see the DOAP
> plugin for an example). It is not a requirement of the project to create
> Dispatcher code, in fact, I would be tempted to say that it may be
> better to leave that for the community, thus reducing your learning
> curve. However, if you are already confident with dispatcher or want to
> learn it that would also be fine. Can you please make a note in your
> application indicating what you preference will be (this is for
> evaluation purposes later in the project).
Well, since I am a newcomer to Forrest, I would like to try out with
the skins first.
I would also like to learn about Dispatcher and fulfill your use case.
But at this point I am not so sure of the scope involved. So, I would
take the safe option and not promise to create the dispatcher code.
> Finally, with respect to evaluating your success or failure on the
> program we need to know just how many plugins you intend to implement.
> "Currently it says FOAF + Plugins for DOAP, DOAC, RDF Calendar,
> Microformats, and etc., along with the associated examples", I suggest
> it would be better for you to indicate exactly which plugins you plan to
> implement. Success or failure is not tied to implementing everything,
> just using your time realistically.
Thank you very much for pointing this out. I have now changed the
proposal to reflect when I think each of the plugins would be
delivered. Please advice if this needs any revision.
> One of the goals of GSoC is to introduce new people to the ASF and how
> it works. It appears you do not need this introduction. Can you tell me
> why you feel you should be selected again? What do you feel a second
> year in GSoC will give you? (it is well worth putting this into your app
> as they are rated by the ASF community as a whole, not just the Forrest
> community).
Well, I really like challenges, and GSoC to me in a way, is a big
challenge. I liked doing it last time and I guess I was naturally
drawn to it this time as well. And yes, you are right.. I don't need
an introduction, but I suppose I have lots more to learn! So, I
consider this as a wonderful opportunity to learn new things, test my
skills, interact with a new community and finally deliver something
useful.
> How do you propose managing your commitments to GSoC and your work on
> your final exams?
Hmm.. tough one :). Honestly, I do not think I could do much work
before finishing my final exams in mid June. After the exams however,
I am 100% free and could do GSoC work full-time. From last year's
experience, bulk of the implementation work, and thus the
deliverables, happened in-between the mid and the final evaluations,
which according to the GSoC time line this year, falls between July
9th and August 20th. Therefore, if I get accepted, I would be totally
committed to GSoC during this period.
Also, I would use the period leading up to the mid evals (that is from
April to June) in learning and experimenting with Forrest in order to
deliver the initial FOAF plugin by July 9th.
So I sincerely believe that my university work will not get in the way
of completing the work for GSoC project according to the current
time-line.
Thank you very much for taking your time to review my proposal.
[1] http://wiki.apache.org/general/OshaniSeneviratne/GSoC2007/proposal
Oshani
Re: Google Summer of Code project
Posted by Ross Gardler <rg...@apache.org>.
Oshani Seneviratne wrote:
> Hi Devs,
>
> I am interested in doing the SoC project on 'Creating plugins for
> embedding/producing RDF/XML and microformats in Forrest content
> objects'. My proposal is available at [1] and I would love to hear any
> of your comments on that.
>
> [1] http://wiki.apache.org/general/OshaniSeneviratne/GSoC2007/proposal
Thanks for your project outline, and more importantly, thanks for
seeking community feedback before the deadline passes. For ASF projects
involvement with the community is critical, we don't want to bring in
people who will work in isolation. The fact you are here now, and the
fact that your project plan actually allows for community feedback is great.
So, onto the feedback about your application.
You have scheduled a whole week for "Design for plugins". Can you expand
on exactly what you think this design will contain.
The reason I ask is that there is already a DOAP plugin in the
whiteboard which is reasonably functional (and a little buggy). It works
with both the skins and the dispatcher and may serve to act as a
template for how your plugins will look. Then again, you may decide it's
not quite right.
I like the idea of focussing on a FOAF plugin and using that to gather
community feedback. I note that you have assigned a considerable amount
of time to this, but provide very little information about what we can
expect this plugin to do. For example, is it simply going to transform a
FOAF file to XDoc or will it also include a number of indexes generated
from the available FOAF files?
I'm particularly interested in producing JSON output to enable the FOAF
data to be viewed with Exhibit (from Simile at MIT). I've started to do
this in the DOAP plugin, but it is incomplete as other things have got
in the way. Would you be interested in adding this kind of functionality
(or finishing it in the DOAP plugin)?
Are you familiar with Forrest already? If not, do you think you can
grasp what you need to in the time allocated to the first plugin
deliverable? What approach will you use for getting up to speed with
Forrest? (don't worry, we are not necessarily looking for people with
existing Forrest skills)
How did you come across Forrest and why what interests you about this
GSoC project?
I *love* that you are planning on creating test code for the plugins.
This is something we do not do enough of in Forrest. There are a number
of problems with doing tests for Forrest outputs, you may find some
useful info in a dev archives. Can you provide an outline of how you see
these tests working.
It is also worth pointing out that plugins are expected to be documented
in such a way that the plugin docs themselves are a test case. That is
they test all functionality.
For my personal use case I need the plugins to be implemented using the
Dispatcher, but for Forrest 0.8 release we need the code to be
compatible with skins. Fortunately it's easy to do this (see the DOAP
plugin for an example). It is not a requirement of the project to create
Dispatcher code, in fact, I would be tempted to say that it may be
better to leave that for the community, thus reducing your learning
curve. However, if you are already confident with dispatcher or want to
learn it that would also be fine. Can you please make a note in your
application indicating what you preference will be (this is for
evaluation purposes later in the project).
Finally, with respect to evaluating your success or failure on the
program we need to know just how many plugins you intend to implement.
"Currently it says FOAF + Plugins for DOAP, DOAC, RDF Calendar,
Microformats, and etc., along with the associated examples", I suggest
it would be better for you to indicate exactly which plugins you plan to
implement. Success or failure is not tied to implementing everything,
just using your time realistically.
I note that you say:
* I successfully completed a GSoC project last year. So I know how
the competition works and how best to manage a GSoC project.
* I am an Apache Committer already. So I have a very good
understanding about how the community works.
One of the goals of GSoC is to introduce new people to the ASF and how
it works. It appears you do not need this introduction. Can you tell me
why you feel you should be selected again? What do you feel a second
year in GSoC will give you? (it is well worth putting this into your app
as they are rated by the ASF community as a whole, not just the Forrest
community).
* My final exams will be over by June 2007, and I would be starting at
MIT in September 2007. So, I have lots of free time in-between, which
luckily coincides with the GSoC timeline :-).
How do you propose managing your commitments to GSoC and your work on
your final exams?
---
I look forward to reading your final proposal and rating it after the
deadline passes. In case you haven't heard through other channels,
Google have just extended the deadline to Monday, March 26th at 5:00 PM
Pacific time (12:00 AM UTC March 27, 2007).
Good luck...
Ross
RE: Google Summer of Code project
Posted by "Gav...." <br...@brightontown.com.au>.
> -----Original Message-----
> From: oshanis@gmail.com [mailto:oshanis@gmail.com] On Behalf Of Oshani
> Seneviratne
> Sent: Saturday, 24 March 2007 11:44 AM
> To: dev@forrest.apache.org
> Subject: Google Summer of Code project
>
> Hi Devs,
>
> I am interested in doing the SoC project on 'Creating plugins for
> embedding/producing RDF/XML and microformats in Forrest content
> objects'. My proposal is available at [1] and I would love to hear any
> of your comments on that.
>
> [1] http://wiki.apache.org/general/OshaniSeneviratne/GSoC2007/proposal
>
> Thanks and Regards,
> Oshani
Great Proposal Oshani, Ross is the main Mentor for this project and so I'm
sure after the weekend he'll get round to looking at it for you, just didn't
want to see this message go unanswered for too long.
Gav...
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.17/730 - Release Date: 3/22/2007
> 7:44 AM