You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
to my understanding to enforce full IRIs which later get matched against hydra helper exported from namespaces module. Possibly currently JSON-LD context, flattening of the response and use of hydra helper from namespaces module don't work together as good as they can.
@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?
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.
PR #11 introduces in JSON-LD context
to my understanding to enforce full IRIs which later get matched against
hydra
helper exported fromnamespaces
module. Possibly currently JSON-LD context, flattening of the response and use of hydra helper from namespaces module don't work together as good as they can.@lanthaler also questioned the two lines above in JSON-LD context in #11 (comment)
I see this issue a distinct but related to #14
The text was updated successfully, but these errors were encountered: