Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Thomas Tanon
    @Tpt
    I am considering for the next versions of Oxigraph to completely drop RocksDB in favor of Sled
    ces10
    @ces10
    no problem whit compiler, I compiled yesterday oxygraph-server
    Thomas Tanon
    @Tpt
    Great!
    ces10
    @ces10
    with rocksdb
    I'll read bout sled now, thanks another time, see later
    Thomas Tanon
    @Tpt
    See you!
    Adrian Gschwend
    @ktk
    @Tpt what I wanted to ask for a while, did you ever consider psql as backend? there seems to be a graph backend and the json store stuff seems to work pretty well by now
    there was also a guy working on psql showing up on the W3C graph workshop in 2019, they seem to at least explore if graph should become a thing in pg
    Thomas Tanon
    @Tpt
    Hi! It's a great question. Yes, it would be definitely possible to use psql as a backend but it would be a quite different software:
    1. No easy embedability, WASM...
    2. Having native RDF storage allows to optimize indexing and such to RDF/SPARQL specific structure and usage patterns. It's slightly harder to do it efficiently using a SQL system. It's why most of systems like Jena moved to native storage instead of relying on a SQL database. My impression is that the best way to get performant stuff out of psql would be to load the data into psql using a schema that fits well the data and then use tools like Ontop for SPARQL queries if the user wants SPARQL.
    I would say it's definitely something to consider for some usage patterns
    Adrian Gschwend
    @ktk
    it's surely a different beast to set up
    the one benefit I see with pgsql is that it's "native" on cloud providers today
    as in you can get it deployed and don't have to worry about backend or backups & stuff
    I have no idea how they do it for key-values & what the approach ist for the graph backend
    not sure if it's really just all sql in the back
    anyway not important, I agree on low footprint for oxigraph
    we don't have any contender in that domain so it's useful
    Thomas Tanon
    @Tpt
    Yes, for cloud stuff it makes a lot of sense
    It would be a great project to have
    Jena had something for that
    I was not aiming for cloud at first because features like replication are important in that use case
    having something on top of psql makes a lot of sense
    It might be a derivation of Oxigraph reusing the parsers...
    Adrian Gschwend
    @ktk
    yeah that's what I thought as well
    maybe they go the gsql path sooner or later, then one could at least benefit of the backend stuff they figure out
    Thomas Tanon
    @Tpt
    Indeed, it would be a great project to have some oxigraph+pgsql. However, doing it efficiently is a lot of work so not sure when.
    Rust is a bit less useful in this target (most of the heavy code is done py psql) so stuff like nodeJS might also be proper tools for that
    Adrian Gschwend
    @ktk
    stone old but it's RDF on postgres
    found it in Appendix A in this paper https://arxiv.org/pdf/2102.13027.pdf
    that is a gigantic list of triplestore implementations
    but most dead
    Thomas Tanon
    @Tpt
    Thank you! There is also Ontop for the querying part: https://ontop-vkg.org/
    And this research project: https://github.com/Quetzal-RDF/quetzal
    Thomas Tanon
    @Tpt
    A follow-up dumb question: at least on AWS, what would be the advantage of a SPARQL layer on top of psql compared to Neptune?
    Adrian Gschwend
    @ktk
    yeah on AWS that would not make too much sense
    we use for example digital oceans and they provide hosted psql
    we use fuseki there at the moment but then we have to take care of everything
    backup etc
    Thomas Tanon
    @Tpt
    Indeed, that would make sense for this kind of hosting. But then we would have to weight what makes more sence: develop an automated backup solution for fuseki/oxigraph or an at least partially new frontend on top of psql?
    Thomas Tanon
    @Tpt
    (that's a genuine question, I have no real opinion on this)
    Adrian Gschwend
    @ktk
    that's pretty much what we do now
    Thomas Tanon
    @Tpt
    Ok ! I see.
    @ktk My current state of mind is: if there are enough interest and people funding the work, I am willing to take the time for an "Oxigraph+PSQL" variant. If not, I am quite happy with the current Oxigraph design (optimized for the fun of the development done during my free time).
    Adrian Gschwend
    @ktk
    @Tpt right now not, was more curious on general conext. I think your focus is good & I would rather have a conversation about a consortium to solve the wikidata problem
    I thought about this job offer and I have to say I have no idea what I would do in their position
    Thomas Tanon
    @Tpt

    Ok! I agree!

    I thought about this job offer and I have to say I have no idea what I would do in their position

    Me neither, I guess they made this job offer because they have no idea what they shoud do either.

    Adrian Gschwend
    @ktk
    lol that's a good observation :-D