Agent API

[lecoqlibre]

Discuss about the agent API here.

We should build a LDP like API.

GET /jobs
POST /jobs

GET /job/

[balessan]

For unitary jobs I would say:

• GET on /jobs/{resource_title}.{desired_extension}
• PUT on /jobs/{resource_title}.{desired_extension}
• PATCH on /jobs/{resource_title}.{desired_extension}
• DELETE on /jobs/{resource_title}{.desired_extension}

[FabienGandon]

in LDP using the HTTP Header Slug: resource-name you can control the name of the created resource ex. herefoaf in the container fabien

POST /fabien/ HTTP/1.1
Host: inria.fr
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle
Slug: foaf

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
<> a foaf:PersonalProfileDocument;
    foaf:primaryTopic <#me> ;
    dc:title 'Fabien’s FOAF profile' .
<#me> a foaf:Person;
    foaf:name 'Fabien Gandon'  .    

[balessan]

Yes I hesitated to use {resource_title} or {slug} as we do it on Startin'blox.

[pchampin]

Following Tim's vision of Solid as a "universal API", I think we should not define a new API, but rather fit all the interactions between the user, the agent, and the pod, in the Solid protocol.

For jobs, I think that the user-facing application should write them on the user's pod, set up ACL so that the agent can access them, and put them in the TypeIndex so that the agent can discover them.

[balessan]

We should rely on the LDP but even then it has a container structure that we could define, should'nt we ?

I'd like to see an architecture diagram of those interactions because that is quite unclear to me :-)

[pchampin]

@balessan

We should rely on the LDP but even then it has a container structure that we could define, should'nt we ?

I would rather rely on TypeIndex than on a fixed container name. Namely, when the agent or the user-facing application (used to configure jobs) discover the user's WebID, they looks for the type index to see in which container(s) jobs (instances of ex:IndexerAgentJobs) are stored, and by default store new job in the same folder.

Of course, the user-facing application should also

• create such a container if none exist (e.g. /Jobs)
• provide advanced users with the ability to chose another containers

Is that clearer?

[balessan]

Makes more sense yes ! Thanks !