RE: hydra:supportedOperation and hydra:IriTemplate

On Wednesday, November 9, 2016 6:34 PM, Christopher Johnson wrote:
> Hi Markus,
> 
> Yes, for the most part, thank you.  The open filtering/view discussion
> informs me that IriTemplate has many operation definition
> possibilities with rather complex semantics and nothing is normative
> (yet).

The IriTemplate is fully specified. By itself, it has rather weak (and simple) semantics.


>  The alternative (and complementary?) possibilty of minting a
> new link relation type (hydra:IriTemplate?) seems direct and within
> immediate reach.  So, if the server declares a TemplatedLink property
> as an IriTemplate relation, then the client will know "up front" that
> it has to parse it and is then free to implement any (tbd) view or
> filter as defined in the document for that property.  And, it makes
> sense that a unique IriTemplate "method" is not preferred, because a
> TemplatedLink operation remains a normal GET (at least for the
> server).  I remain unclear on several details (e.g. when does a
> TemplatedLink become a Link), but I will follow the list closely.


You could define a userUrlTemplate property. It would be of a TemplatedLink, i.e., a property that whose value is an IriTemplate. You could then define the semantics of userUrlTemplate so that it points you to a Collection of users whose properties match the variables in the IriTemplate. In pseudo syntax:

@id: userUrlTemplate
@type: TemplatedLink

---

userUrlTemplate:
  template: /users/{?lastname}
  mapping: 
    variable: lastname
    property: schema.org/givenName
    required: true

This would then tell a client that it can retrieve users with the lastname "Johnson" by dereferencing /users/?lastname=Johnson. The goal of the filtering/view discussion is to make that possible in a generic manner so that a client wouldn't need to understand userUrlTemplate but just the Hydra vocabulary.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 10 November 2016 20:20:04 UTC