Clarify how client's JSON-LD context, flattening and the hydra helper from namespaces should work together about heracles.ts

[elf-pavlik]

Capturing #17

@elf-pavlik: This assumes relying on hydra helper from namespaces module. At the same time I would like to understand better advantages of relying on that helper instead of keeping hydra: prefix in JSON-LD context and rely on use of CURIEs hydra.Collection (helper) vs. "hydra:Collection" (CURIE)

@alien-mcl: As for the question regarding hydra helper - it's purely for code readability and to avoid string literals flying here and there. We could have a list of constants defining each term IRI, but I thought that having a hierarchy of IRIS arranged with constant names relating to original prefixes are a better way. It has nothing to do with the JSON-LD context and it's purely for TypeScript/JavaScrpt readability while accessing some of the JSON-LD originating Javascript objects.

It seems to me that hydra namespace helper depends directly on the JSON-LD context used for framing the "hypermedia interface". Terms from hydra vocab used in that interface get matched in code against full IRIs provided by that namespace helper. In PR #17 we can see that matching against the IRIs provided by helper puts particular requirements on the JSON-LD context used for framing.

Do we intend that hydra namespace helper only gets used internally by the client or also expose it to the developers who use the client in their applications?

[alien-mcl]

The situation now is Heracles.ts no more uses JSON-LD framing for data model processing. The namespace helper is still used for obtaining hydra (and couple of other vocabs) specific resources, but there is no assumption for the data payload which is obtain from the server.

The response is first flattened to contextles form with all IRIs (including blank nodes) expanded and all values normalized. Then the internal engine traverse such a graph searching for resources matching hydra IRIs to build a data model. The only assumption is these resources and their matching is compliant with the spec and how they were expected to be organized.

I hope this answers your doubtes.

As for the JSON-LD context used - there is neither special requirement nor limitation on using it by other developers.