W3C home > Mailing lists > Public > public-hydra@w3.org > June 2014

Re: Relating hydra:Classes to hydra:IriTemplates

From: Jindřich Mynarz <mynarzjindrich@gmail.com>
Date: Tue, 24 Jun 2014 09:03:56 +0200
Message-ID: <CAE=8Bu8yrnqhP4BpLFf2VEtJTrreBNTh7DKSYHkYxZw_0-fwPA@mail.gmail.com>
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
Received on Tuesday, 24 June 2014 07:04:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:53:59 UTC