You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Adrian Gschwend <ml...@netlabs.org> on 2012/09/10 22:51:32 UTC

Rules Endpoint: Persistent rules, recipes & SPARQL CONSTRUCT

Hi group,

Some more questions regarding

https://incubator.apache.org/stanbol/docs/trunk/components/rules/store.html

Rules Manager & Recipe Manager:
- How can I CRUD rules & recipes over the REST API?
- How does a recipe look like? Couldn't find any examples in the docs

https://incubator.apache.org/stanbol/docs/trunk/components/rules/

-
Rule language - specifies the syntax used in Stanbol in order to
represent rules. Stanbol rules can be as SWRL, Jena rules or SPARQL
CONSTRUCT;
-

-> IIRC it was told at the last workshop in Salzburg that I cannot use
SPARQL CONSTRUCTS right now, is this still the case?

thanks

Adrian


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

Posted by 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

Posted by 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


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

Posted by 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

Posted by Adrian Gschwend <ml...@netlabs.org>.
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

Posted by Adrian Gschwend <ml...@netlabs.org>.
On 11.09.12 12:54, Alessandro Adamou wrote:

Hi Alessandro,

> IIRC I was asked if it was possible to store rules written directly as
> SPARQL constructs of SWRL rules instead of the Stanbol syntax, rather
> than just exporting them as such (which is already possible).

Jup that was exactly my question.

thanks

Adrian


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

Posted by Alessandro Adamou <ad...@cs.unibo.it>.
On 9/11/12 12:00 PM, Andrea Giovanni Nuzzolese wrote:
> What do you mean with
>
>> -> IIRC it was told at the last workshop in Salzburg that I cannot use
>> SPARQL CONSTRUCTS right now, is this still the case?
> ?

I'll follow up on that since I was the spokesman at that workshop.

IIRC I was asked if it was possible to store rules written directly as 
SPARQL constructs of SWRL rules instead of the Stanbol syntax, rather 
than just exporting them as such (which is already possible).

Back then I knew this feature was part of future plans, I cannot tell 
its state today though. Certainly Andrea knows better.

Best,

Alessandro


> On Sep 10, 2012, at 10:51 PM, Adrian Gschwend wrote:
>
>> Hi group,
>>
>> Some more questions regarding
>>
>> https://incubator.apache.org/stanbol/docs/trunk/components/rules/store.html
>>
>> Rules Manager & Recipe Manager:
>> - How can I CRUD rules & recipes over the REST API?
>> - How does a recipe look like? Couldn't find any examples in the docs
>>
>> https://incubator.apache.org/stanbol/docs/trunk/components/rules/
>>
>> -
>> Rule language - specifies the syntax used in Stanbol in order to
>> represent rules. Stanbol rules can be as SWRL, Jena rules or SPARQL
>> CONSTRUCT;
>> -
>>
>> -> IIRC it was told at the last workshop in Salzburg that I cannot use
>> SPARQL CONSTRUCTS right now, is this still the case?
>>
>> thanks
>>
>> Adrian
>>
>


-- 
M.Sc. Alessandro Adamou

Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy

Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy


"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)

Not sent from my iSnobTechDevice


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

Posted by Andrea Giovanni Nuzzolese <nu...@cs.unibo.it>.
Hi Adrian,

> ok great, as I said I'm more than willing to contribute my findings to
> the documentation as well. Can you point me to the correct files? I will
> add stuff and send you a patch when I figured everything out and
> documented some more things.

you can find the latest documentation about rules here [1].
Probably you are more interested about REST docs. [2] and [3] should help.

> Please let me know when you documented more, I'm trying to finish the
> demo for my early adopter proposal and I should start hurry up a bit ;)
> I promised a first demo mid next week.

I have just added some new parts in the documentation about rules :) 

> If I get that correctly the SWRL rules get transformed in a SPARQL
> CONSTRUCT statement and executed like this. So my question is can I also
> add a SPARQL CONSTRUCT rule instead of a SWRL rule to the POST request?

Right now we don't have any subcomponent in Rules able to accept SPARQL CONSTRUCTS as rules.
I think that it could be not so hard to design and implement one for SPARQL 1.0. 
I understand that it would be very helpful. 
One comment is that the general idea behind Stanbol Rules is to have an abstract syntax for expressing axioms as rules and then to adapt them to concrete rule engine implementation, e.g., Jena, Hermit, Pellet, SPARQL CONSTRUCT, etc.
Hence, the mapping direction is from Stanbol Rules to concrete rule implementations. For example, every Stanbol Rule is a valid Jena Rule, but the inverse is not always true. 
Coming back to CONSTRUCTs, SPARQL 1.1 is much more expressive than Stanbol Rules in a way that it would be hard to adapt  SPARQL 1.1 CONSTRUCTs to rules in Stanbol.

Andrea

[1] http://stanbol.staging.apache.org/stanbol/docs/trunk/components/rules/
[2] http://stanbol.staging.apache.org/stanbol/docs/trunk/components/rules/store.html
[3] http://stanbol.staging.apache.org/stanbol/docs/trunk/components/rules/refactor.html

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

Posted by Adrian Gschwend <ml...@netlabs.org>.
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.

ok great, as I said I'm more than willing to contribute my findings to
the documentation as well. Can you point me to the correct files? I will
add stuff and send you a patch when I figured everything out and
documented some more things.

Please let me know when you documented more, I'm trying to finish the
demo for my early adopter proposal and I should start hurry up a bit ;)
I promised a first demo mid next week.

> What do you mean with
> 
>> -> IIRC it was told at the last workshop in Salzburg that I cannot use
>> SPARQL CONSTRUCTS right now, is this still the case?

If I get that correctly the SWRL rules get transformed in a SPARQL
CONSTRUCT statement and executed like this. So my question is can I also
add a SPARQL CONSTRUCT rule instead of a SWRL rule to the POST request?

cu

Adrian



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

Posted by Andrea Giovanni Nuzzolese <nu...@cs.unibo.it>.
Hi Adrian,

you are right, the documentation is not exhaustive and not helpful at all.
I am going to add more details.

What do you mean with

> -> IIRC it was told at the last workshop in Salzburg that I cannot use
> SPARQL CONSTRUCTS right now, is this still the case?

?

Andrea

On Sep 10, 2012, at 10:51 PM, Adrian Gschwend wrote:

> Hi group,
> 
> Some more questions regarding
> 
> https://incubator.apache.org/stanbol/docs/trunk/components/rules/store.html
> 
> Rules Manager & Recipe Manager:
> - How can I CRUD rules & recipes over the REST API?
> - How does a recipe look like? Couldn't find any examples in the docs
> 
> https://incubator.apache.org/stanbol/docs/trunk/components/rules/
> 
> -
> Rule language - specifies the syntax used in Stanbol in order to
> represent rules. Stanbol rules can be as SWRL, Jena rules or SPARQL
> CONSTRUCT;
> -
> 
> -> IIRC it was told at the last workshop in Salzburg that I cannot use
> SPARQL CONSTRUCTS right now, is this still the case?
> 
> thanks
> 
> Adrian
>