7.1.0 release soon, building to 8.0.0

9 views
Skip to first unread message

Nicholas Car

unread,
Sep 30, 2024, 1:40:57 PM9/30/24
to rdflib-dev
Dear RDFLib users,

Ashely, Edmond, David and I are preparing for an RDFLib 7.1.0 release next week to make available all the recent month's changes. we will then prepare for an 8.0.0 release in perhaps 2 months time. 

7.1.0 is planned to be the last 7.x release and 8.0.0 will fix/break a few things.

Proposed for 8.0.0 are:

  • Python 3.11+ only 
    • removing support for older Python allows us to remove dependency on six & isodate which prevent some packaging systems making RDFLib available
  • Rationalise the supported Stores
    • remove BerkeleyDB - it's old, not completely implemented and likely unused. If you want to use it, it will always be available via 7.1.0
  • Fix the Dataset API
    • ConjunctiveGraph is deprecated already and will be removed
    • The Dataset API has been annoying for many of us for years, we will fix it
  • Switch the current default & longturtle serialisations
    • longturtle is more modern (Turtle 1.1 syntax), better arranged for Git and moving to support better sorting
  • Tidying up the Namespace Manager functions for all Stores
    • ensuring that unbinding/replacement binding works correctly for all known stores
  • improved documentation
    • an ever-present issue

We also plan to improve the build system a bit too by:

  • removing the pre-commit tool
    • this duplicates work done by our stying & test suites and causes build problems
  • removing the Poetry lock file
    • this complicates PR merging
    • it is not appropriate for RDFLib as a library
    • we will implement a requirements.min.txt file for working minimum versions of dependencies

This is fairly small stuff and still we have the following larger things on the horizon (for after 8.0.0):

  • RDF-star handling
    • several un-merged PRs have attempted to address this
  • improved SPARQL handing
    • complete the handing of SPARQL 1.1 grammar
    • SPARQL-Star
  • Tidying the parser & seralizer interfaces
  • comprehensive documentation review
    • many function's options are undocumented
    • command line tools are not listed everywhere
    • we could do with more examples of how to use RDFLib in modern ways

Please reply to this or put Issues into GitHub.

Happy RDFing, Nick

Wes Turner

unread,
Oct 1, 2024, 12:43:30 AM10/1/24
to rdfli...@googlegroups.com

- JSON-LD 1.1 Framing:
  - 
  - is there a way to specify JSON-LD 1.1 Framing parameters as arguments to RDFpipe and the rdflib Python API?

- W3C YAML-LD: 
  - 
  - links to specs, src, tests: 

- RDF 1.2:
  -
  - "Changes between RDF 1.1 and RDF 1.2"


- Pyodide WASM and rdflib
  - JupyterLite works in a browser without a server, on chromebooks too;  does rdflib work - do the tests pass - in JupyterLite with the Pyodide JupyterLite kernel?
  - there's a shim from python to js fetch()
  - there's SQLite in WASM (with synchronization to postgres) or indexeddb

- Is there a longturtle respec spec?

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/4xawYFmRtja_y6KX3PL0mby69XUmULtResuWgW9B6v9Cijg-bpseHvCetnlGQbjMtj9gGdMfqH8iTvXZky7Agor67vim6gY2AQYp1lt1SIA%3D%40kurrawong.ai.

Nicholas Car

unread,
Oct 28, 2024, 10:04:49 PM10/28/24
to rdfli...@googlegroups.com
Hi Wes,

- is there a way to specify JSON-LD 1.1 Framing parameters as arguments to RDFpipe and the rdflib Python API?

We want to do a lot more regarding the options for the various parsers and serializers in RDFLib in 8.x. At the moment there are a number of parse/serialize options that are either hard to discover or undocumented. 

We plan on properly documenting the function signatures for all parsers and serializers and, In the case of JSON-LD, this will likely allow for framing. My team have personally being making good use of framing with JSON-LD

- Is there a longturtle respec spec?

No. It's just an opinionated version of turtle that I made to improve Git diffs and readability. It mostly just inserts more linebreaks to output than the original RDFLib Turtle serializer. It's closer to the RDFLib original serializer than, say, Jena's Turtle serializer.

At some point (8.x, 9.x??) we want to replace the current Turtle parser/serializer with a PEG-based soemthing, in line with other grammar-based toolkits in other projects, but this will likely only come after the parser/serializer function signature improvements, unless someone wants to submit a PR...

Cheers, Nick


Wes Turner

unread,
Oct 28, 2024, 11:12:42 PM10/28/24
to rdfli...@googlegroups.com
Hi Nick,


On Mon, Oct 28, 2024, 6:04 PM Nicholas Car <ni...@kurrawong.net> wrote:
Hi Wes,

- is there a way to specify JSON-LD 1.1 Framing parameters as arguments to RDFpipe and the rdflib Python API?

We want to do a lot more regarding the options for the various parsers and serializers in RDFLib in 8.x. At the moment there are a number of parse/serialize options that are either hard to discover or undocumented. 

Are the main() methods already argparse with support for e.g. argcomplete tab-completion, or click, or just better help= strings with a few usage examples in the manpage 


We plan on properly documenting the function signatures for all parsers and serializers and, In the case of JSON-LD, this will likely allow for framing.

With docstrings && annotations for mypy checking at ide-time
and/or e.g. icontracts for runtime type checks with icontract-hypothesis and docs with sphinx-icontract someday?

Also, deal-solver does formal verification of Python code with Z3

My team have personally being making good use of framing with JSON-LD

If the app API always produces JSON-LD with the same framing, is JSON Schema enough or isn't it SHACL for graph validation?


- Is there a longturtle respec spec?

No. It's just an opinionated version of turtle that I made to improve Git diffs and readability. It mostly just inserts more linebreaks to output than the original RDFLib Turtle serializer. It's closer to the RDFLib original serializer than, say, Jena's Turtle serializer.

Good call


At some point (8.x, 9.x??) we want to replace the current Turtle parser/serializer with a PEG-based soemthing, in line with other grammar-based toolkits in other projects, but this will likely only come after the parser/serializer function signature improvements, unless someone wants to submit a PR...

Hey, CPython implemented PEG parsing awhile back,

CPython docs > "10. Full Grammar specification": 

"PEP 617 – New PEG parser for CPython"

pegen: 


/? fastest turtle parser: 

  > A fast and lightweight Python RDF parser which wraps bindings to Rust's Rio using PyO3

latex2sympy is built on ANTLR, which is not plain Python but FWIU is typically more performant than PEG [1]   https://news.ycombinator.com/item?id=2331234

Thanks


Reply all
Reply to author
Forward
0 new messages