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> 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>>. >> >> -- >> -- 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>.