Details About The Project

[yanhuojunjun]

Dear @pradeeban ,

I hope this message finds you well. I am writing to inquire about some details about the project:

1. When the photos are uploaded, besides the images themselves, what additional information can we obtain? For example, is there a brief description accompanying the photo, or details about the location where the photo was taken?

2. I'm planning to develop a simple demo in the next few weeks, utilizing MySQL + Django to construct a basic database system and set up a straightforward database application website. I'd like to inquire if this approach aligns with your expectations, and if so, would it be possible to submit it to you for review once completed?

Best regards,
Mingjun Li

[pradeeban]

Hi @yanhuojunjun,
Thanks for your interest and carefully crafted questions.

1. The information is going to be entered by the subject (such as the patient). Usually, it is in the format of a narrative (i.e., a bulk of text). We could also make it more structured (as in, information entered through textboxes in a front end) or unstructured. But I believe, we will deal with something in between (as in, some information such as location, identified condition (person recovering from addiction, unhoused, person with diseases - can be a dropdown), in addition to a bulk text as narrative.

This information, regardless of how this is collected from the user/subject/patient, needs to be stored in the database (more likely, the image stored somewhere and the database that holds all these textual data points to the image).

2. That sounds good to me. Sure, you can send it for review.
   The ideal approach would be for you tom make the demo in your own GitHub repo (you could fork Beehive and develop there in your fork, or just create a new repo - whatever works for you), and send a link through the comments. That way, your development is documented as open source contributions.

[dipak101505]

Hi @pradeeban,

Thank you for reviewing the repository. To streamline the documentation process, I leveraged the readme.md and building.md files from the Keycloak repository as references for the boilerplate content.

I've chosen a minimal configuration in my starter pom, utilizing H2 database, JPA, Spring Web, and Lombok. I would appreciate your feedback on any of these dependencies that might be unnecessary for this project, allowing me to further optimize the code.

The application was developed entirely from scratch using Spring Initializr, featuring a REST controller, entity classes, and a repository. I consulted the official Spring Boot documentation for guidance on specific annotations.

Please note that the included method for uploading images to the cloud, which currently relies on a paid subscription service, is intentionally disabled. I used Ai to generate this particular method.

Could you please review the api's and provide feedback. Please let me know about any changes that need to be implemented and other functionalities that can be added.

[dipak101505]

Hi @pradeeban ,
Did you get a chance to go through the API documentation and test the two APIs
https://github.com/dipak101505/Beehive

[pradeeban]

@dipak101505 Thanks for the explanations.

You shouldn't be using any paid subscription services. Images should be local, rather than cloud. Commits should be incremental and intentional with proper logs. It is a bit difficult to review a fully-fledged undocumented APIs.

I assume your APIs will work as they are, although I did not test it. We will review it during the review period.
Although having an API gateway can be a good addition, your code looks slightly confusing and bulky.

To improve the readability, you can include a proper README.md and code-level / method-level comments.
Make sure the images are storing locally only, and remove any unnecessary code from your repository and make it minimal, but a complete prototype (currently, it is still loaded with several unclear stuff such as API Keys).

[dipak101505]

@pradeeban Thanks so much for your insights! I'm going to streamline the code by removing all the image storage stuff in the cloud. This will make everything much lighter and easier to manage. On top of that, I'll be adding clear documentation and comments throughout the code to make it crystal clear for everyone.

[pradeeban]

That is awesome. Simple codes are easier to maintain.

[ChathuraAbeygunawardhana]

Hey @pradeeban
I am interested in this project and I think it's within my technical capabilities . Before diving deeper into the implementation of the project , I got some questions to get clarified if you don't mind.

1)Can you provide more details about the target users of the Beehive platform? Understanding the needs and preferences of the end-users will help guide the development process.

2)How will the Beehive platform handle the storage and organization of digital images? Are there any specific requirements or constraints regarding the database structure? I am aware it should be done with either MYSQL or mongo but , I want to know if there any constraints
related to the structure of the database

3)Could you explain more about the process of translating digital images into the database? What are the key considerations in this process?

4)What features or functionalities are prioritized for the initial development of the Beehive platform? Are there any specific milestones or deadlines to keep in mind?

thank you
regards

[pradeeban]

1. The target user base is two-fold.
   One is, the marginalized folks (I don't like to call them "patients" since not everyone is with a condition that is identified as a disease.) The marginalized folks include the unhoused, people recovering from addiction such as alcohol abuse, people with addiction, prisoners, re-entry (those released from prison), ...
   Second is, those who volunteer to work with these marginalized folks (Minimal in number. You could call them "admins." For instance, one deployment - would be in Alaska, and the set of users under this category will be largely researchers of the University of Alaska System. But then, eventually, other communities can also use this framework.

2. There must be IRBs in place since we are dealing with images produced by marginalized folks. For the scope of GSoC, we will just use random images (that you could find from the Internet with free use licenses or our own photos). In the end, for software perspective, it does not matter.

Not to forget the textual inputs (such as the narrative). Already discussed elsewhere in the discussion forum here. Just look through other comments.

3. This includes storing the images and their associated text entry (you could call that "metadata") somewhere. Perhaps, images just in the local file system, and the text in the database with pointers to image? These are things you have freedom to choose, given this is a new project.

4. As any new open-source research project supported by GSoC (or similar time-constrained summer internship), making realistic assumptions to build a working prototype.

While it is good to learn how the framework will eventually be used in Alaska (and elsewhere), at this stage, leveraging existing open source tools to build this framework with maintenance and extensibility in mind, addressing the keypoints listed in the ideas list page in your proposal.

[ChathuraAbeygunawardhana]

thanks and I got few more questions

1. what kind of application are you looking for? a web , mobile or a standalone application
2. Do you propose a specific technology stack or can we use a preferred stack on our own

[pradeeban]

1. A simplistic approach (such as Google Forms type input) is what we are after. We need to keep the goals realistic (350 hours), as this includes backend and data store too.
2. You can propose your own preferred stack as this is a new project.

[JiuYou2020]

Hi @pradeeban,

I'm very interested in this project and believe I have the capability to complete it. However, I still have some questions regarding certain aspects of the project:

1. What kind of content should be retrieved in the search? For instance, when users input "unhoused," what specific search results are expected?

2. In developing the database to support user-content interactions, is there a need for statistical analysis? Should the analyzed data be presented to administrators in a particular format?

3. Does the project require support for user authentication, facilitating certain actions for administrators? Or is it solely focused on fulfilling the project requirements?

These are the uncertainties I have regarding the project details. I would appreciate clarification on these points.

Thank you.
Kun Gao

[pradeeban]

Hi @JiuYou2020,

1. You will return the metadata (i.e., the textual entry) and their attached images. You might want to consider something smart (such as a lazy-loading approach) to make this query/retrieve process more efficient.
2. No, that is not an expected part of the project. But you are always free to add optional features (like, nice to have, but no deal breaker if you cannot complete if time runs out).
3. An OpenID login (such as Google single sign on) should work. We still need certain level of authentication so that a malicious user won't just log in and drop the database or look into others' details.

I hope I have answered your questions sufficiently. Let me know if you have more questions.

[yanhuojunjun]

Dear @pradeeban ,

I hope this message finds you well.

I'm writing to update you on the recent progress of the Beehive project. After our previous discussions regarding the details of Beehive, I've been working to bring the project to fruition, and I've completed a basic Beehive demo based on MySQL and Django.

Could you please take some time to review the project I've written? https://github.com/yanhuojunjun/Beehive
(demo videos are provided in the readme.md)

1. It's just an initial demo of Beehive, I am willing to add more features to it in the future to better help people. Honestly, I am a newcomer to open-source projects, so please let me know if I make any mistakes, I would be happy to correct them.
2. Does the demo I've created align with your expectations? Do you have any suggestions for it?
3. May I draft a specific proposal for this project and discuss the details of my proposal with you via email ?

Best regards,
Mingjun Li

[pradeeban]

Hi @yanhuojunjun,
Thank you for getting back.
Your demo looks pretty neat. You are on the right track!
Pls go ahead with the proposal. Then we can provide more feedback from the proposal draft itself.

Regards,
Pradeeban.

[yanhuojunjun]

@pradeeban Thank you for reviewing my demo! I still have something uncleared while drafting my proposal:

1. About target users: like you said elsewhere, the target users are divided into admins and marginalized folks. I understand that admins are mainly researchers, which correspond to the admin interface in my demo. However, there seems to be a discrepancy between marginalized folks you described and my understanding of the other users. I thought that the other users extend far beyond marginalized folks, also including the outsider artists (who are not suffering from different problems) and anyone in the world who is concerned about marginalized folks. Where did I go wrong? Please clarify my confusion.

2. About proposal review: Is it an idea approach to send my proposal via email for your review? Should I also send my proposal to other mentors?

[pradeeban]

@yanhuojunjun:
You can send the draft to all the mentors cc'd in a single email. (Do not send 3 individual emails).

No, the target users are only marginalized folks, as that is our research use case for understanding expressions of specific vulnerable population groups of Alaska (and elsewhere, eventually). But I think it is a good idea to have an entry for "Other," which can cover both marginalized folks who are not listed above, who do not want to go into specific details, or those who do not identify as marginalized in the first place (we shouldn't have included them in the target group; we can imagine sometimes miscategorization may occur although very unlikely at our scale).

The research use case goes to understand how self-expression varies along the timeline during the recovery process (from being unhoused, recovering addicts, or a healing process from a disease, trauma, or a life-altering event).

However, misunderstanding the research use case in your demo is not a huge issue. You can easily remove and add user groups from the software since it is not really tied to the research question. For instance, if someone wants to deploy Beehive in a different setting (such as for a group of high school students), they should be able to do that by changing the text descriptors. So, indeed, leaving those group definitions (unhoused, recovering addicts, ...) in a configuration file that can be easily changed is a good idea.

Essentially, we can imagine three groups of users. One is "super admins" who can modify the configurations (such as the one I mentioned above) and make changes to the deployment (this will be pretty much the developer community of the project), the other one is the caretakers/social-care workers who can enter images on the marginalized folks' behalf, and the final one is the marginalized folks themselves. By extension, you may even come up with more roles. But I think the above three makes sense to me.