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