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