- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Wed, 29 Sep 2021 09:35:09 +0200
- To: public-hydra@w3.org, Kristoffer Garcia <lambdakris@gmail.com>
Hello Kristoffer Thank you for asking those questions, they are very good indeed. Let me answer inline Tom On 29 September 2021 at 09:12:00, Kristoffer Garcia (lambdakris@gmail.com) wrote: > Greetings fellow HYDRA heads, > > I have a couple of HYDRA (and JSON-LD) related questions: > > 1. How essential is the entrypoint to a HYDRA api? Quite important. A client discovers a full picture of what constitutes a given API in a single representation of the ApiDocumentation resource. It is a single, mostly static resource which will get cached early on by clients and intermediaries. However, I see how you could argue that it might be superficial. The alternative would be to dereference models (classes) independently and provide possible operations inline. You probably will not escape the former but the latter would effective unnecessarily increase the size of all your responses. > Why isn't a dedicated EntryPoint class defined? I guess we never found a use for such a class. You would typically use an API-specific type or maybe schema:WebPage to offer predictable semantics. Hydra itself does not care what is the representation of the entrypoint. It is only important to offer that link to the clients. Let me ask you in return, what would you expect from a hypothetical hydra:EntryPoint class? > Could the ApiDocumentation function as the entrypoint resource (I doesn't seem so, but figured I'd ask)? Technically anything could be the entrypoint, given the weak semantic relation between the ApiDocumentation and API's entrypoint. IMO it could only make sense if you were to provide an API to control that very API. In that case however, you might in fact end up with two separate APIs altogether. > > 2. What is the functional difference between the @context and the @type > keywords? More specifically, why would you opt to use @type instead of or > in addition to @context, when it seems that you can achieve sufficient > descriptiveness with the use of just @context and sub/scoped contexts? I've > read through https://json-ld.org/spec/latest/json-ld/#the-context and > https://json-ld.org/spec/latest/json-ld/#specifying-the-type, but it is not > clear what the use of one is accomplishing in contrast to the other. I’m not sure I understand what you mean by “sufficient descriptiveness”. @type is pretty mostly an alias of property rdf:type. Relating to @context, you can actually redefine any other JSON key to serve as a substitute of @type but I see limited utility of such a choice. Do compare the 3 JSON-LD below, all of which represent the same RDF data: https://tinyurl.com/3erhyf67 https://tinyurl.com/56w224z9 https://tinyurl.com/pux6wt72 > > Thank you all, > > Kris >
Received on Wednesday, 29 September 2021 07:35:31 UTC