-
Notifications
You must be signed in to change notification settings - Fork 16
JSON LD.ex implementation report
These are the results for the tests of the JSON-LD test suite
A proper JSON-LD EARL implementation report will be produced as soon as the required infrastructure is available to produce it automatically.
All tests passing.
Issue #1 causes the following tests to fail. Note that actually correct values are produced, but the ordering is different, which from a graph perspective is irrelevant.
- Test 0034 - Multiple properties expanding to the same IRI
- Test 0035 - Language maps with @vocab, default language, and colliding property
- Test 0038 - Expanding blank node labels
Issue #1 causes the following tests to fail. Note that actually correct values are produced, but the ordering is different, which from a graph perspective is irrelevant.
- Test 0034 - Multiple properties expanding to the same IRI
- Test 0035 - Language maps with @vocab, default language, and colliding property
- Test 0038 - Flattening blank node labels
Not implemented yet.
All tests except the ones using remote documents (0002, 0003, 0004, 0005) are passing.
Test 0118 - produce generalized RDF flag: This is also caused by Issue #1. The different ordering during expansion causes the generation of different blank nodes, but the produced graph is isomorph to the test graph.
- Test 0020 and Test 0021 fail due to a bug in the spec itself. Hopefully this gets fixed in JSON-LD 1.1.
- Another, more fundamental ordering problem causes the following tests to fail:
- Test 0001 - Object Lists
- Test 0002 - Native Types
- Test 0017 - Remove duplicate triples
- Test 0018 - use native types flag set to true
- Test 0019 - use rdf:type flag set to false
The later failing tests result from a missing property of Elixir's maps, used for the input data: Elixir's maps have no order, esp. the order is independent of the additions, i.e.
%{} |> Map.put(true, 1) |> Map.put(false, 1)
%{} |> Map.put(false, 1) |> Map.put(true, 1)
both result in Maps with the same ordering of the values. So, fixing that would require a different representation of graphs in RDF.ex in general.
Note that actually correct values are produced, only the ordering is different, which from a graph perspective is irrelevant.