- From: Jindřich Mynarz <mynarzjindrich@gmail.com>
- Date: Tue, 24 Jun 2014 09:03:56 +0200
- To: public-hydra@w3.org
On Mon, Jun 23, 2014 at 1:33 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote: >> Or, distilled even more, is the following pattern in line with Hydra? >> >> :A :B :C . >> :A a hydra:Class . >> :B a hydra:TemplatedLink . >> :C a hydra:IriTemplate . > > IMO it is, but it is currently still undefined what it means, i.e., the specification doesn't mention this pattern at all. This is why I'd like a clarification. In fact, the Hydra specification doesn't contain any examples of hydra:TemplatedLinks used in a wider context; the sector 5.2 (http://www.hydra-cg.com/spec/latest/core/#templated-links) shows only atomic examples, where there's no relation indicated to the rest of the API description. > I can't think of a different interpretation right now but that doesn't mean there isn't any. If the pattern by itself is ambiguous, then further documentation may clarify the indended way of interpretation. (Given that we'd still think this is a good way to represent things.) Meanwhile, I think we could get a consensus on a slightly similar, but likely less controversial pattern, that you proposed: :A :B :C . :A a hydra:Collection . :B a hydra:TemplatedLink . :C a hydra:IriTemplate . Do you think the Hydra specification can contain an example of this pattern being used? > The only argument against doing this is the tight coupling it might promotes as we've already discussed. I'm on the fence with the argument against tight coupling. I think things like hydra:statusCode, hydra:returns (ISSUE #32) and maybe even the whole mechanism of hydra:supportedOperation may also promote tight coupling. If decoupling clients from APIs is a key design goal of Hydra, then it should be clarified what kinds of coupling are acceptable, and this could be referred to when making further design decisions about the vocabulary. > An alternative to kind of get the best of both worlds might be to specify a specific type of entry point in more detail (as you implicitly proposed, I think). So some form of entry point which does nothing else than listing all available collections (persons, orderds, etc.) along with their interaction models (querying, adding members, etc.). What do you think? I don't see how creating a specific type of entry point would help to address how hydra:IriTemplates should be related to hydra:Classes. Do you propose to create a specific entry point class that would link to hydra:Collections and those in turn would be related to hydra:IriTemplates via hydra:TemplatedLinks? - Jindřich -- Jindřich Mynarz http://mynarz.net/#jindrich
Received on Tuesday, 24 June 2014 07:04:43 UTC