Re: [rdflib-dev] RDFLib roadmap & governance
ndency: https://github.com/RDFLib/rdflib/pull/744 <https://github.com/RDFLib/rdflib/pull/744> > > It's not very likely to happen very soon from my side though. > > Jörn should chime in himself, but I think we'd both be happy to have > someone else come in and take more responsibility - if you want to > help code-review PRs, discuss future changes, make releases etc. I > would only be glad to see RDFLib be more alive! > > - Gunnar > > > On 27 April 2018 at 04:55, Stefano Cossu > wrote: >> I am not sure if there is a "non-dev" group for RDFLib but I might as well >> start asking here. >> >> I find RDFLib to be an amazing project and the only RDF libray for Python >> (if we don't count the Redland Python bindings). Lately I have been >> wondering how the roadmap is laid out (I understand 5.0.0 is the next >> release and a major overhaul) and if there is some governance around the >> project. Is it completely volunteer-based or is there an institutional >> commitment? Is there a group that works on the roadmap and high-level goals? >> Is there any maintenance for 4.x planned once 5.x is out? >> >> This would be helpful for me to understand how the project is doing and what >> to expect from it. As RDFLib is a fundamental library for handling an >> increasingly popular data format with one of the most popular programming >> languages, I would love to see more PRs merged, more issues closed, more >> questions answered, more test coverage, more exhaustive documentation, more >> regular commits; in short, a mature project. I may not have the bandwidth to >> commit to the code directly but I may be able to volunteer some of my spare >> time for strategic planning. >> >> Thanks for your great efforts so far and for any information you may want to >> share. >> >> Stefano >> >> >> -- >> Stefano Cossu >> Director of Application Services, Collections >> >> The Art Institute of Chicago >> 116 S. Michigan Ave. >> Chicago, IL 60603 >> 312-499-4026 >> >> -- >> http://github.com/RDFLib >> --- You received this message because you are subscribed to the Google >> Groups "rdflib-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rdflib-dev+...@googlegroups.com . >> To post to this group, send email to rdfli...@googlegroups.com . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rdflib-dev/c3fa068d-ea99-df1d-b5da-27f527dbcb06%40artic.edu <https://groups.google.com/d/msgid/rdflib-dev/c3fa068d-ea99-df1d-b5da-27f527dbcb06%40artic.edu>. >> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>. > > > > -- > http://gromgull.net > > -- > http://github.com/RDFLib > --- > You received this message because you are subscribed to the Google Groups "rdflib-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to rdflib-dev+...@googlegroups.com . > To post to this group, send email to rdfli...@googlegroups.com . > To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/CAGm1OD%3DMxNnF9by4WEPOfctAVe48SV6nU7O9m%2B1E8tcqDzhqLQ%40mail.gmail.com <https://groups.google.com/d/msgid/rdflib-dev/CAGm1OD%3DMxNnF9by4WEPOfctAVe48SV6nU7O9m%2B1E8tcqDzhqLQ%40mail.gmail.com>. > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>. -- http://github.com/RDFLib --- You received this message because you are subscribed to a topic in the Google Groups "rdflib-dev" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/rdflib-dev/9XAyxUbawlQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to rdflib-dev+unsubscr...@googlegroups.com <mailto:rdflib-dev+unsubscr...@googlegroups.com>. To post to this group, send email to rdflib-dev@googlegroups.com <mailto:rdflib-dev@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/57f57963-60a6-4406-9fad-02a5729fb0dc%40googlegroups.com <https://groups.google.com/d/msgid/rdflib-dev/57f57963-60a6-4406-
[rdflib-dev] RDFLib roadmap & governance
I am not sure if there is a "non-dev" group for RDFLib but I might as well start asking here. I find RDFLib to be an amazing project and the only RDF libray for Python (if we don't count the Redland Python bindings). Lately I have been wondering how the roadmap is laid out (I understand 5.0.0 is the next release and a major overhaul) and if there is some governance around the project. Is it completely volunteer-based or is there an institutional commitment? Is there a group that works on the roadmap and high-level goals? Is there any maintenance for 4.x planned once 5.x is out? This would be helpful for me to understand how the project is doing and what to expect from it. As RDFLib is a fundamental library for handling an increasingly popular data format with one of the most popular programming languages, I would love to see more PRs merged, more issues closed, more questions answered, more test coverage, more exhaustive documentation, more regular commits; in short, a mature project. I may not have the bandwidth to commit to the code directly but I may be able to volunteer some of my spare time for strategic planning. Thanks for your great efforts so far and for any information you may want to share. Stefano -- Stefano Cossu Director of Application Services, Collections The Art Institute of Chicago 116 S. Michigan Ave. Chicago, IL 60603 312-499-4026 -- http://github.com/RDFLib --- You received this message because you are subscribed to the Google Groups "rdflib-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to rdflib-dev+unsubscr...@googlegroups.com. To post to this group, send email to rdflib-dev@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/c3fa068d-ea99-df1d-b5da-27f527dbcb06%40artic.edu. For more options, visit https://groups.google.com/d/optout.
Re: [rdflib-dev] Why are contexts stored as graphs?
Thanks Gunnar. I started adapting my implementation to this behavior: https://github.com/scossu/lakesuperior/blob/store_ctx_as_uri/lakesuperior/store_layouts/ldp_rs/lmdb_store.py But the SPARQL query breaks. I believe it is because the contexts() method not only is expected to return a list of graphs rather than URIs, but also these are expected to be graphs that can be queried for contents and return the triples in the store contained in that context (at least they are in the Sleepycat implementation). I can try to add this change to my store implementation, or just store graphs as Sleepycat does, but it feels I am propagating the odd behavior... this may be especially problematic if I inadvertently pass a very large graph as a context, and the whole of it gets stored as a giant pickle. Any chance that your PR could be merged, or that some clarity is made about the Store interface and its methods? Thanks, Stefano On 02/19/2018 02:13 AM, Gunnar Aastrand Grimnes wrote: That's a good question, and I don't think anyone who still maintains RDFLib actually knows :) I wanted to fix it, but never got it out the door: https://github.com/RDFLib/rdflib/pull/409 (4 years ago :see_no_evil:) - Gunnar On 19 February 2018 at 02:43, scossu wrote: Hello, I am working on an alternate back end implementation of the Store interface that uses LMDB as its persistence layer: https://github.com/scossu/lakesuperior/blob/lmdb_strategy5/lakesuperior/store_layouts/ldp_rs/lmdb_store.py I noticed that the Dataset class passes a Graph instance to the Store when handling contexts: http://rdflib.readthedocs.io/en/stable/_modules/rdflib/graph.html#Dataset.graph The Sleepycat store seems to support this too. I am not sure about the reason why the context has to be the whole graph rather than a URI reference (i.e. the context graph identifier). This increases storage size and seems to make the implementation of both the back end and the upstream code consuming Graph and Dataset instances more complex. I guess there is a reason for this approach. Can someone explain the rationale? Would it be otherwise OK to just strip the identifier off the graph and only store that (which would introduce some back and forth conversion efforts but it would keep things consistent)? Thank you. -- http://github.com/RDFLib --- You received this message because you are subscribed to the Google Groups "rdflib-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to rdflib-dev+unsubscr...@googlegroups.com. To post to this group, send email to rdflib-dev@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/66ac519b-0b54-4997-bc1d-d23353be282a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stefano Cossu Director of Application Services, Collections The Art Institute of Chicago 116 S. Michigan Ave. Chicago, IL 60603 312-499-4026 -- http://github.com/RDFLib --- You received this message because you are subscribed to the Google Groups "rdflib-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to rdflib-dev+unsubscr...@googlegroups.com. To post to this group, send email to rdflib-dev@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/d4f45986-ac71-a8ef-0afe-bf2a0661fd08%40artic.edu. For more options, visit https://groups.google.com/d/optout.
