Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RDF 1.1 tests & support #450

Closed
4 of 7 tasks
joernhees opened this issue Jan 5, 2015 · 8 comments
Closed
4 of 7 tasks

RDF 1.1 tests & support #450

joernhees opened this issue Jan 5, 2015 · 8 comments
Labels
critical enhancement New feature or request parsing Related to a parsing. serialization Related to serialization. testing
Milestone

Comments

@joernhees
Copy link
Member

joernhees commented Jan 5, 2015

we should properly test & support RDF 1.1.

I see the following TODOs: (help welcome)

As discussed in #400 backwards compatibility would be nice.

  • For parsers this hopefully means that the new version can still parse the old one.
  • For serializers we should probably provide a way to write the old style RDF 1.0 files in the specified format and default to writing the new style RDF 1.1 files.

Any thoughts on this welcome @RDFLib/rdflib

@joernhees joernhees added enhancement New feature or request parsing Related to a parsing. serialization Related to serialization. testing critical labels Jan 5, 2015
@joernhees joernhees added this to the rdflib 5.0 milestone Jan 5, 2015
@niklasl
Copy link
Member

niklasl commented Apr 25, 2015

+1. Solving #436 is probably part of this work.

@ghost
Copy link

ghost commented Dec 23, 2021

As far as I can tell from the W3's What's New in RDF 1.1 RDFLib now fully supports it.

@ghost ghost closed this as completed Dec 23, 2021
@aucampia
Copy link
Member

I'm not sure we are running all these test suites, and even if we are I think we are skipping large amounts of them.

@ghost
Copy link

ghost commented Apr 15, 2022

I guess it's worth checking that the desired coverage is achieved. grepping for read_manifest turns up, for example,

read_manifest("test/w3c/trig/manifest.ttl"),
and the tests in the corresponding folder match those of the W3 test suite

Elsewhere, these tests call read_manifest and run the corresponding tests:

test/test_trig_w3c.py
test/test_parsers/test_nquads_w3c.py
test/test_parsers/test_turtle_w3c.py
test/test_parsers/test_nt_w3c.py

Seem to be missing the 1.1 rdfxml tests (the rdfxml 1.0 tests don't use read_manifest but test/test_rdfxml.py instead) and the RDF 1.1 Semantics tests.

Most of the skipped tests (in skiptests.list) are sparql11 tests

@ghost
Copy link

ghost commented Apr 16, 2022

Further to this. I'm working on collecting up the test suites into a single test_suites directory to live in consistent_test_data and it appears that tests/n3 is unused apart from a couple of specific tests because renamingn3 to _n3 only produces these two failures:

FAILED test/test_n3.py::TestN3Case::test_issue156 - FileNotFoundError: [Errno 2] No such file or directory: '.../test/n3/issue156.n3'
FAILED test/test_misc/test_parse_file_guess_format.py::FileParserGuessFormatTest::test_n3 - FileNotFoundError: [Errno 2] No such file or directory: '.../test/n3/example-lots_of_graphs.n3'

Uh-huh, the n3 suite was originally for checking n3 serialization roundtripping and atm, I'm not entirely sure that test has been replaced by a later version, so I recovered and updated gromgull's test code, pro tem. Tests out okay but we probably don't actually need it if notation3 roundtripping is already being comprehensively tested.

@aucampia
Copy link
Member

I will hold off with fixing reporting then. I would prefer we do open a new issue for this though. Also I think it may make sense to just put test data in 'test/data/' as that already implies that is test data and it should be consistent from the outset.

@aucampia
Copy link
Member

Maybe we should make an issue for tracking test reorg also to discuss layout.

@ghost
Copy link

ghost commented Apr 16, 2022

Also I think it may make sense to just put test data in 'test/data/' as that already implies that is test data and it should be consistent from the outset.

Agreed.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
critical enhancement New feature or request parsing Related to a parsing. serialization Related to serialization. testing
Projects
None yet
Development

No branches or pull requests

3 participants