Re: Rules Endpoint: Persistent rules, recipes & SPARQL CONSTRUCT

[Andrea Giovanni Nuzzolese <nu...@cs.unibo.it>]

Hi Adrian,

I found some inaccuracy in the documentation.
I'll fix it and I am going to explain in this email how to solve some problem you experienced.

First of all a recipe is a container for collection of rules.
Before adding rules to a recipe you have to create a recipe. Probably it would be easier to create a recipe while adding rules in case the recipe provided does not exist. We can discuss about it.
The refactor works only on recipes. If you need to apply refactoring to a single rule nobody prevents you to create a recipe containing only a rule.

Coming back to your recipe and foaf rdf (I have attached back to this email), what you need to do is to follow these steps:

1. to create a recipe. The documentation shows how in the request an ID for the recipe should be provided as actual path parameter (e.g., recipeTestA in http://localhost:8080/rules/recipe/recipeTestA). 
This is correct, but I found a bug in the code as the service accepts only URIs as IDs for the recipe. This means that the value for the recipe ID should be something like http://myrecipe.foo/recipeTestA in order to have
a request like http://localhost:8080/rules/recipe/http://myrecipe.foo/recipeTestA. In order to have any king of identifier for recipes I opened an issue on Jira (STANBOL-758) [1].

In order to make your request working right now you should do the following

  $> curl -X PUT -d description="A test recipe." http://localhost:8080/rules/recipe/http://myrecipe.foo/recipeTestA

2. to add rules to a recipe. The previous step creates an empty recipe to which you can add rules. If you write multiple rules into a file you can add multiple rules via a single request. 
With the rule file you provided we can do the following:

  $> curl -X POST -H "Content-type: multipart/form-data" -F rules=@domain.rule -F description="The rule Adrian provided me." http://localhost:8080/rules/recipe/http://myrecipe.foo/recipeTestA

You can test that the rules have been added to recipe with the following request:

  $> curl -X GET http://localhost:8080/rules/recipe/http://myrecipe.foo/recipeTestA

You should see an RDF describing your recipe with the rules (actually just one) you have added.

3. to apply refactoring. You should use the service /refactor instead of /refactor/apply. The latter needs that both the RDF and the recipe have to be provided as input streams, while the former needs the recipe internally stored in the rule store
(what we did with previous steps). So you can do the following:

  $> curl -X POST -H "Content-type: multipart/form-data" -H "Accept: application/rdf+xml" -F recipe=http://myrecipe.foo/recipeTestA -F input=@foaf.rdf http://localhost:8080/refactor

You should have back the refactored graph.



I hope this helps.
I am completely available in helping you.
Sorry for my late reply.

Andrea

[1] https://issues.apache.org/jira/browse/STANBOL-758




On Sep 24, 2012, at 5:06 PM, Adrian Gschwend wrote:

> On 11.09.12 12:00, Andrea Giovanni Nuzzolese wrote:
> 
> Hi Andrea,
> 
>> you are right, the documentation is not exhaustive and not helpful at all.
>> I am going to add more details.
> 
> Now I'm on the latest SVN version where the doc is better, unfortunately
> I can't get a lot to work from the REST examples and I have some general
> questions as well:
> 
> - /recipe does not work, there seems to be no handler for that (in terms
> of I get a "not found"). Is this really supposed to be there?
> - What exactly is the difference between recipes and rules? Is a recipe
> a collection of rules?
> - Am I right that a rule has to belong to a recipe and I have to post a
> recipe before I can post a rule?
> - From what I can read I always apply a refactor on a recipe and not on
> a rule. But in the end of the documentation I find:
> 
> --
> Request example which shows how to perform a refactoring applying an
> existing recipe in the rule store:
> $ curl -X POST -H "Content-Type: multipart/form-data" \
>      -H "Accept: application/turtle" \
>      -F recipe="
>           has(, ?x, ?z) . \
>           has(, ?z, ?y) \
>              -> \
>           has(, ?x, ?y)" \
>      -F input=@graph.rdf
>      http://localhost:8080/refactor/apply
> --
> 
> and you write:
> 
> --
> Parameters:
> recipe (Mandatory). The recipe's identifier that is basically an URI
> input-graph (Mandatory). The ID of the graph to transform
> output-graph (Mandatory). The ID that the transformed graph has to have
> in the IKS triple store
> --
> 
> This does not fit at all IMHO. Either the variable is an ID or it is
> data, in your example 'recipe' becomes data as well as 'input', which
> you call 'input-graph' above and the "mandatory" field output-graph is
> missing, which gives me all together total confusion.
> 
> Would be nice if you could explain that a bit more, I *really* want to
> get it to work :)
> 
> cu
> 
> Adrian

Re: Rules Endpoint: Persistent rules, recipes & SPARQL CONSTRUCT

[Andrea Giovanni Nuzzolese <nu...@cs.unibo.it>]

Hi Adrian,

the last version of the rules module does suppurt strings for recipes' names instead of qualified URIs.
Let me know if it works for you.

Andrea

On Oct 25, 2012, at 7:13 PM, Adrian Gschwend wrote:

> On 02.10.12 17:54, Andrea Giovanni Nuzzolese wrote:
> 
> Hi Andrea,
> 
> Sorry for the late reply, we have a lot of Stanbol based work in our FP7
> project right now so I'm lagging behind.
>> In order to make your request working right now you should do the following
>> 
>>  $> curl -X PUT -d description="A test recipe."
>> http://localhost:8080/rules/recipe/http://myrecipe.foo/recipeTestA
> 
> Thanks, this works now. That explains why it didn't work as written in
> the documentation/samples. Current code still seems to have the problem
> right? (I run trunk here)
> 
>> 2. to add rules to a recipe. The previous step creates an empty recipe
>> to which you can add rules. If you write multiple rules into a file you
>> can add multiple rules via a single request. 
> 
> works as well now!
> 
>> You can test that the rules have been added to recipe with the following
>> request:
> 
> looks good as well
> 
>> 3. to apply refactoring. You should use the service /refactor instead
>> of /refactor/apply. The latter needs that both the RDF and the recipe
>> have to be provided as input streams, while the former needs the
>> recipe internally stored in the rule store
>> (what we did with previous steps). So you can do the following:
> 
> thanks seems to work as well!
> 
> I did everything via curl now, will try to finish my Node.js "module"
> which does the work automated!
> 
> @John: Will give you feedback on that ASAP!
> 
> cu
> 
> Adrian
> 

Re: Rules Endpoint: Persistent rules, recipes & SPARQL CONSTRUCT

[Adrian Gschwend <ml...@netlabs.org>]

On 02.10.12 17:54, Andrea Giovanni Nuzzolese wrote:

Hi Andrea,

Sorry for the late reply, we have a lot of Stanbol based work in our FP7
project right now so I'm lagging behind.
> In order to make your request working right now you should do the following
> 
>   $> curl -X PUT -d description="A test recipe."
> http://localhost:8080/rules/recipe/http://myrecipe.foo/recipeTestA

Thanks, this works now. That explains why it didn't work as written in
the documentation/samples. Current code still seems to have the problem
right? (I run trunk here)

> 2. to add rules to a recipe. The previous step creates an empty recipe
> to which you can add rules. If you write multiple rules into a file you
> can add multiple rules via a single request. 

works as well now!

> You can test that the rules have been added to recipe with the following
> request:

looks good as well

> 3. to apply refactoring. You should use the service /refactor instead
> of /refactor/apply. The latter needs that both the RDF and the recipe
> have to be provided as input streams, while the former needs the
> recipe internally stored in the rule store
> (what we did with previous steps). So you can do the following:

thanks seems to work as well!

I did everything via curl now, will try to finish my Node.js "module"
which does the work automated!

@John: Will give you feedback on that ASAP!

cu

Adrian