Re: hydra and void

On 10/30/14 12:52 PM, Gregg Kellogg wrote:
>> On Oct 30, 2014, at 6:16 AM, Melvin Carvalho<melvincarvalho@gmail.com>  wrote:
>> >
>> >
>> >
>> >On 30 October 2014 13:58, Ruben Verborgh<ruben.verborgh@ugent.be>  wrote:
>> >Hi Melvin,
>> >
>>> > >Just about using the right tool for the right job.  In an ideal world everything would be 5 star linked data, and (1) would be dominant.  But we have some work to go before that is true.
>> >
>> >Sure. But if you're looking to design an API, the easy way would be to add the link.
>> >
>>> > >Got it, trying to work out how it would look.
>>> > >
>>> > >My use case is:
>>> > >
>>> > ><user> <predicate> <payment_processor> .
>> >
>> >So let me interpret that.
>> >You want to make sure that users can pay?
>> >
>> >So I'll assume that they have some shopping cart then.
>> >Or maybe just an article they want to buy.
>> >
>> >Remember that Hydra is for resource-oriented APIs,
>> >so “payment_processor” would probably not fit into that category.
>> >Rather, it could be something like:
>> >
>> >- the status of this shopping cart can go from "unpaid" to "paid";
>> >- or: this shopping cart has the following payment form
>> >
>> >This could translate to a relation such as:
>> ></shopping-cart/2645> <hasPaymentForm> </shopping-cart/2645/payment>.
>> >
>> >We haven't solved the "what predicate" question yet;
>> >I'm just trying to figure out how things are modelled.
>> >(But note that you likely would not have a "user" as subject.)
>> >
>> >Thanks for the response, apologies for not providing a context.
>> >
>> >By payment processor, I mean more like a banking facility.  So the API provides:
>> >
>> >Read functions:
>> >- Get balance (based on a URI)
>> >- Get transaction history (based on a URI)
>> >
>> >Write functions
>> >- Transfer to another URI
>> >- Withdraw to another wallet (using crypto currency addresses)
>> >- Deposit funds
>> >
>> >Both the read and write functions ideally will occur using self describing RDF.  So I think adding hydra here would be a nice way to document such interfaces.
>> >
>> >My client side app will authenticate a user, and from there it need to know, 'Which service does this user hold a balance with' ie 'Where can I find the banking facilities for this user'.
>> >
>> > From that triple (or triples) it needs to work out where are the APIs for balance, deposit etc.  Later on there will be more APIs such as trust scores and reputation for various URIs
>> >
>> >So, I wonder can I say:
>> >
>> ><:user>  <:hasProvider><http://example.org>
>> >
>> >then
>> >
>> ><http://example.org>  <:hasAPIDocs> <URL> .
>> >
>> >Or something like.  My use case it to integrate payments into the world of linked data, if that makes any sense.
> Also, note the Link header which should be returned by a server implementing Hydra as described in 4.3:http://www.hydra-cg.com/spec/latest/core/#discovering-a-hydra-powered-web-api
>
> [[[
> EXAMPLE 11: Discovering Hydra API documentation documents
> HEAD / HTTP/1.1
> Host:www.example.com
>
> ====================================
>
> HTTP/1.1 200 OK
> ...
> Content-Type: text/html; charset=utf-8
>
> Link:<http://api.example.com/doc/>; rel="http://www.w3.org/ns/hydra/core#apiDocumentation"
> ]]]
>
> Go to any page of the site, see the Link header response, and load the associated Hydra API document to understand how to interact with this, or other resources.
>
> Gregg
>

+1

-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Received on Thursday, 30 October 2014 17:05:14 UTC