Test `ld_context`

[sdruskat]

Test all functions comprehensively.

[led02]

I think we have to clarify things here.

I initially wrote ContextPrefix to facilitate my development, being tired of writing full IRIs all the time.

This does not fully align with the test.
For example, there is not such a thing as a "default prefix".
If you supply an URI as @context, the vocabulary is fetched and used.
You can explicitly define prefixes within your vocabulary ... complicated stuff.
However, in the end the behavior is well defined by the W3C.
I use the implementation of these algorithms provided by pyld.

Regarding ContextPrefix, it is a shortcut used to avoid the complexity of pyld and all those subtle differences between vocabulary expansion and IRI expansion...

All places where this class is used could also directly use the full IRI of the vocabulary.
Every internal handling of vocabulary is delegated to pyld and does not use ContextPrefix at all.

I see that the tester expects the ContextPrefix to do some more.
The question that arises is, whether it is useful to expand the implementation of the class to match these expectations.
Basically, I see two possible implementations here:

• Expand the ContextPrefix to use pyld for expansion. This could be done but in the end, it would be pretty slow
• Implement some basic extended vocabulary expansion. This would mean that the class is not fully compliant to the standard but is probably a good bit faster than using pyld.

Of course, both implementations could be used by making ContextPrefix configurable.

My proposal is to get rid of ContextPrefix first by using full IRIs instead of this convenience utility.
This would also make the sources more explicit, which is good.

To put the work done here into actual use, I propose to implement a user API that behaves (almost) exactly as the test require.

Sorry for the long post, thank you for reading.

PS: @sdruskat Thanks for breaking things. :-)

[led02]

My proposal is to get rid of ContextPrefix first by using full IRIs instead of this convenience utility.
This would also make the sources more explicit, which is good.

a44a6a1 Only minor changes required in the implementation. (Even the small changes are be subject to discussion whether these are required.)

[led02]

To help us use appropriate vocabulary: https://www.w3.org/TR/json-ld11/#the-context

[sdruskat]

To help us use appropriate vocabulary: https://www.w3.org/TR/json-ld11/#the-context

Related: #392.

[sdruskat]

To put the work done here into actual use, I propose to implement a user API that behaves (almost) exactly as the test require.

I believe that this is exactly what the API proposed in #376 should do!
See #376 (comment) there.