Re: Using an IriTemplate with a class or property

Just an additional note on this that the CSV on the Web Working Group have
proposed a csvw:uriTemplate property that is used to construct URIs for
resources from the cell values in a CSV table.
If the corresponding thing were added for JSON, it would arguably fit better in
the JSON-LD spec than Hydra (and probably was already discussed during
development of JSON-LD spec).


> On January 5, 2015 at 10:31 AM John Walker <john.walker@semaku.com> wrote:
> 
>  Hi Tom,
> 
>  > On January 3, 2015 at 11:27 PM tomasz@t-code.pl wrote:
>  >
>  >
>  > Hi John
>  >
>  > AFAIK templates are used to allow the client to build request URI but by
>  > using the user's input. A generic client would generate an appropriate form
>  > with fields for template variables. In the case you describe the server has
>  > all the necessary information required to build the URI and I would expect
>  > them to be included in a resource's representation.
>  >
>  > I understand your reasoning though. However I'm quite undecided whether I
>  > agree or not. The tradeoff here is that less code is required on the server
>  > but more on the client. The problem is that you would effectively deny
>  > access to part of your API to clients, which don't process Hydra at all
>  > such as crawlers or simple Linked Data browsers.
>  >
>  > Bottom line is it would an anti-goal, because such templates would mix two
>  > distinct functionalities. I'm not saying I don't like the idea. I fact I
>  > had similar though at some point. But it should be something different from
>  > the current IriTemplate IMO.
> 
>  Yes, I agree with you that it makes sense for the publisher to explicitly
> state the URIs in the response. A recent post from Martynas over on the
> public-declarative-apps list about Graphity [1] gets me thinking that it would
> be nice to have a declarative definition of the API that could be used to
> generate some kind of Linked Data wrapper/middleware for an existing JSON API.
> This would need to include the URI template for how to generate the URIs for
> the 'things' described by the API. This is most likely beyond the scope of the
> Hydra Core vocabulary, but could perhaps be an extension of it.
> 
>  John
> 
>  [1]
> http://lists.w3.org/Archives/Public/public-declarative-apps/2015Jan/0000.html
> 
>  >
>  > Regards,
>  > Tom
>  >
>  > December 31 2014 5:34 PM, "John Walker" <john.walker@semaku.com> wrote:
>  > > Hi All,
>  > >
>  > > After having played about the past days making a JSON-LD wrapper for an
>  > > existing API, it seems that
>  > > alot of what I'm doing is related to IRI templates.
>  > >
>  > > Is there any way that a hydra:IriTemplate can be linked to a class or
>  > > property to allow the client
>  > > to figure out what is the next request to make?
>  > >
>  > > As an example here is the JSON-LD for a thing:
>  > >
>  > > http://breweryld.semaku.com/beer/CTKv9o
>  > >
>  > > Which was built from this original JSON:
>  > >
>  > > http://breweryld.semaku.com/beer/CTKv9o?json
>  > >
>  > > So for example I would define a template like this for the beer:
>  > > http://breweryld.semaku.com/beer/{id}#id
>  > >
>  > > This would be linked to the Beer class and a client would know how to
>  > > build the URI by populating
>  > > the template with the data at hand, in this case the value of the id key.
>  > >
>  > > Similarly I might define a template like this for a style:
>  > > http://breweryld.semaku.com/style/{styleId}#id
>  > >
>  > > This template can be linked to the styleId property and that the client
>  > > would know how to build the
>  > > URI based on the property value.
>  > >
>  > > Putting this logic in the Hydra client would help having to implement
>  > > similar logic on server side
>  > > in many APIs.
>  > >
>  > > Regards,
>  > >
>  > > John Walker
>  > > Principal Consultant & co-founder
>  > > Semaku B.V.
>  > > SFJ 4.009, Torenallee 20, 5617 BC Eindhoven
>  > > Mobile: +31 6 475 22030
>  > > Email: john.walker@semaku.com
>  > > Skype: jaw111
>  > >
>  > > KvK: 58031405
>  > > BTW: NL852842156B01
>  > > IBAN: NL94 INGB 0008 3219 95
>  >
>