I have aubmitted my proposal, taking into consideration the expanded deadline. Thank you once again, G.Papoulidis On Tue, Apr 2, 2024, 17:47 Alexios Zavras <zvr+gsoc [ at ] zvr [ dot ] gr> wrote: > Great! > > As you wrote, it will definitely be a "large" project. > You should propose a timeline that you're comfortable > following, but (if accepted) we can agree on a different one > depending on work (e.g., we add another evaluation, > or we simplify the benchmarking -- these can add/remove time). > > On Tue, Apr 2, 2024, at 15:19, Γιώργος Παπουλίδης wrote: > > Greetings once again. > > > > I am almost ready to submit my proposal regarding the Triplestore > > Alternatives project. The only thing that concerns me right now is > > whether I should assume a standard 3 month or an extended period for my > > weekly planning. It is mentioned that the project is large (350 hours), > > and thus, an extended period would be sensible. Should I assume that > > the project would have to be submitted by 26 of August, November 4th or > > something in between? > > > > Thank you for your time and I am looking forward to working with you, > > G.Papoulidis > > > > On Mon, Apr 1, 2024 at 1:30 PM Γιώργος Παπουλίδης <geopapougr [ at ] gmail [ dot ] com> > wrote: > >> Thank you for the clarification. The scope of the project is much > clearer now. > >> > >> On Mon, Apr 1, 2024, 13:05 Alexios Zavras <zvr+gsoc [ at ] zvr [ dot ] gr <mailto: > zvr%2Bgsoc [ at ] zvr [ dot ] gr>> wrote: > >>> Hi George, thanks for your interest and your questions. > >>> > >>> On your first question, no, this is *not* about non-triplestores > >>> like relational or NoSQL databases. This idea would made > >>> for a nice project, but it's not what we're looking for here. > >>> We are only talking about triplestore databases -- > >>> but there are a number of them out there. > >>> As I've written before, a web search can provide links > >>> to things like Jena, Oxigraph, TerminusDB, Neo4J, ... > >>> (and lots of non open-source ones, like AllegroGraph, GraphDB, etc.). > >>> > >>> You are correct that SPARQL is usually a common way of interacting > >>> with the data stored in them (although not always), but this is not > enough. > >>> Let me give the analogy in relational database systems: > >>> for example all of PostgreSQL, MariaDB, SQLite or even Oracle > >>> support SQL for interaction, but actually working with any of them > >>> is different than working with another one: different calls to connect, > >>> to specify database options, to actually provide the SQL and > >>> get the results, etc. etc. > >>> Therefore you need an abstraction layer, which for example > >>> might be provided by something like JDBC or Python's DB API. > >>> > >>> What this project is about is creating something similar > >>> to this abstraction, but oriented towards triplestores. > >>> So you could write your code using this, > >>> and seamlessly exchange your triplestore implementation > >>> (from Jena to Oxigraph, for example). > >>> Is this clearer now? > >>> > >>> Regarding the benchmarking, there is no focus on any specific use. > >>> We will create some basic code to generate some data, > >>> import them, query them, etc. > >>> > >>> For the last point, the project idea was about a library > >>> with a Python interface, since this would be both easier > >>> to implement (since many databases provide Python connectivity) > >>> and easier to use. I'm open t considering alternatives, > >>> but I fear that the lack of already existing interfaces > >>> might make the project too difficult -- for example, > >>> if Rust were chosen, one might need to firstly create Rust libraries > >>> to talk to each of the triplestores before creating an abstraction > >>> to all of them. > >>> > >>> On Mon, Apr 1, 2024, at 02:38, Γιώργος Παπουλίδης wrote: > >>> > Greetings! > >>> > > >>> > I am interested in the proposed project for *Exploring and > Abstracting > >>> > Triplestore Alternatives.* But there are some points in the > explanation > >>> > which aren't clear to me. > >>> > > >>> > The whole proposal revolves around the phrase "triplestore > >>> > alternatives", without having a clear scope of where we will look > for > >>> > such alternatives. It is stated that we have to build an abstraction > >>> > layer to access triplestore alternatives. Since SPARQL already > provides > >>> > such a layer for native triplestore databases, I would assume that > the > >>> > *alternatives* would have to be expanded to relational databases, or > >>> > even NoSQL databases and that we would have to provide a common > >>> > interface for all such databases, as long as they store triples. Is > >>> > that correct? > >>> > > >>> > Also, regarding how we choose and benchmark such databases. Will our > >>> > scope be more focused to any type of dataset? Will we gear our focus > >>> > towards any specific market, allowing us to make assumptions about > how > >>> > the database is used? > >>> > > >>> > Lastly, will the said *well-documented library *be written in > python, > >>> > or is there flexibility on the language used? > >>> > > >>> > Thank you for your time. > >>> > > >>> > > >>> > ---- > >>> > Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και > >>> > συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων > του > >>> > Google Summer of Code - A discussion list for student developers and > >>> > mentors of Google Summer of Code projects., > >>> > https://lists.ellak.gr/gsoc-developers/listinfo.html > >>> > Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. > >>> > ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr > <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr> > >>> > <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr <mailto: > gsoc-developers%252Bunsubscribe [ at ] ellak [ dot ] gr>>>. > >>> > >>> -- > >>> -- zvr - > > -- > -- zvr - >
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., https://lists.ellak.gr/gsoc-developers/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.