Re: MyProfile REST API.

On 8/10/12 5:15 PM, Andrei Sambra wrote:
> Greetings,
>
> Today marks the first release of MyProfile REST API [1], which is 
> supposed to be an interface between standard social web applications 
> (i.e. MyProfile included), and linked data storage, especially SPARQL 
> endpoints (i.e. Virtuoso).
>
> The API offers WebID authentication as well as WebID delegated 
> authorization[2]. It will offer access control at the triple level 
> very soon (a few weeks maximum). For now I'm just testing that I'm 
> doing it right.
>
> A very important feature of the API is that it serves data based on 
> the desired Content-Type. This means if you specify in your request 
> that you Accept: text/rdf+n3, then you will get the data back in that 
> format.
>
> The API currently supports viewing of user profiles (i.e. GET 
> methods), as well as removing cached profiles (i.e. DELETE methods). 
> Once I switch the Wall posts and Messages to full RDF storage 
> (probably based on SIOC), I will also enable those resources.
>
>
>
> Anyway, here is a quick example for viewing a user's profile:
>
> The request:
>
> HTTP/1.1 GET https://auth.my-profile.eu/profile/?webid=<urlencoded WebID>
>
> With these extra header options:
>
> Accept: text/rdf+n3
> On-Behalf-Of: https://my-profile.eu/people/deiu/card#me
>
> Returns*:
>
> <https://my-profile.eu/people/deiu/card#me>
>     a foaf:Person ;
>     foaf:name "Andrei Vlad Sambra" ;
>     foaf:givenName "Andrei Vlad" ;
>     . . .
>
> *the returned profile matches the access control policies specific to 
> the user on whose behalf the request is being made, and optionally the 
> agent doing the request.
>
>
> Another example for deleting the cached copy of a profile:
>
> The request:
> HTTP/1.1 DELETE 
> https://auth.my-profile.eu/profile/cache/?webid=<urlencoded WebID>

Why does a WebID need to be url encoded ? In this context, a WebID is an 
opaque denotation  (name) mechanism. Indirection via redirection is 
where encoded URLs come into play.

Example:

URI: https://my-profile.eu/people/deiu/card#me

Implicit Indirection leads to the actual data source being at the URL: 
https://my-profile.eu/people/deiu/card .

The resource above is associated with the subject it describes, assuming 
its a profile document. Thus, the resource will bear the complete 
description graph for itself and the entity it describes. Basically, 
<https://my-profile.eu/people/deiu/card#me> and 
<https://my-profile.eu/people/deiu/card> are two distinct URIs that 
resolve to a common resource (the actual eav/spo based structured content).

The subtlety here is that we need to url encode document URLs but not so 
for generic HTTP URIs . This is an important Linked Data nuance that's 
best groked via the images I reference below [1][2].

>
> Returns*:
> Successfully deleted profile https://my-profile.eu/people/deiu/card#me.
>
> *for now, the operation will be performed only if the request is made 
> by profile owner, or on his/her behalf (!)

Shouldn't that be subject to the ACL associated with the resource?

Links:

1. http://twitpic.com/5m2lu5 -- Denotation (Naming) is opaque (re. 
Linked Data there's a duality re. denotation and web resource 
identification handled via implicit or explicit indirection, subject to 
your URI style choices i.e., hash or hashless)

2. http://twitpic.com/5m2pp9 -- RESTFul URLs don't require opacity

Kingsley
>
> Andrei
>
> [1] https://auth.my-profile.eu/
> [2] http://www.w3.org/wiki/WebID/Authorization_Delegation
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen