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

RE: Relating hydra:Classes to hydra:IriTemplates

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Mon, 23 Jun 2014 13:33:47 +0200
To: <public-hydra@w3.org>
Message-ID: <079b01cf8ed7$018ffc40$04aff4c0$@gmx.net>
On 23 Jun 2014 at 10:36, Jindřich Mynarz wrote:
> On Sun, Jun 22, 2014 at 10:01 PM, Markus Lanthaler wrote:
>> On 17 Jun 2014 at 12:19, Jindřich Mynarz wrote:
>>> I was thinking a bit more about relating hydra:Classes to
>>> hydra:IriTemplates. It seems to me that the intended way how to do
>>> that is by using hydra:TemplatedLink to mint a property (like
>>> hydra:search is defined). Consider the following example:
>> You still have search in mind, right? In my response below, I assume you want to tell a
> client that the API supports schema:Person and how to find a specific person.
> Yes, as I wrote in the example: :simple-search-person
> rdfs:subPropertyOf hydra:search.
> Let's return to the core topic of this thread. Is the following
> example relating hydra:Class to hydra:IriTemplate in a way that's
> consistent with the intended use of Hydra?
> :simple-search-api a hydra:ApiDocumentation ;
>   hydra:supportedClass schema:Person .
> schema:Person a hydra:Class ;
>   :simple-search-person :simple-search-person-template .
> :simple-search-person a hydra:TemplatedLink ;
>   rdfs:subPropertyOf hydra:search .
> :simple-search-person-template a hydra:IriTemplate ;
>   hydra:template "/person{?name}" ;
>   hydra:mapping [
>       a hydra:IriTemplateMapping ;
>       hydra:variable "name" ;
>       hydra:property schema:name ;
>       hydra:required true
>     ] .
> 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. I can't think of a different interpretation right now but that doesn't mean there isn't any. The only argument against doing this is the tight coupling it might promotes as we've already discussed. 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?

Markus Lanthaler
Received on Monday, 23 June 2014 11:34:20 UTC

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