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