You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Melanie Reiplinger <me...@dfki.de> on 2012/07/03 15:02:16 UTC
Re: POST status code
Hi Alessandro and all.
Today we found a strange behaviour in one of my tests that uses update
functionality of the entityhub/entity. When trying to update a
non-existing entity ( = erroneous or non-existing id), an error code 304
(Not Modified) is returned.
This makes my test notify me of a success, although intuitively, one
would think of this as a fail (since I tried to update something that
does not exist).
curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
"http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
HTTP/1.1 100 Continue
HTTP/1.1 304 Not Modified
Server: Jetty(6.1.x)
Best,
melanie
Am 28.06.2012 08:13, schrieb Fabian Christ:
> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>> So far I've made these methods return 303 See Other with the created
>> resource, basically because I wanted browsers to automatically redirect to
>> that URL when the ontology is added using the HTML form. But I've been
>> thinking that perhaps returning a 201 CREATED would be more appropriate on
>> the REST side.
> I think 201 is the right way to go. The response of a POST just tells
> you that the resource was created and optionally where it was created
> using the Location header.
>
> You can also use 303 and hope that the client interprets it correctly.
> But this response may not be the right one for all clients. Another
> client than a browser may not need the redirect and will perhaps be
> confused.
>
> Therefore, the 201 is IMO the best solution and instead implement the
> redirect separately.
>
> Best,
> - Fabian
Re: POST status code
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Rupert.
Great, I will try first thing tomorrow.
Best,
melanie
Am 03.07.2012 17:48, schrieb Rupert Westenthaler:
> On Tue, Jul 3, 2012 at 5:18 PM, Rupert Westenthaler
> <ru...@gmail.com> wrote:
>> Hi Melanie,
>>
>> I think this is because the parsed RDF data do not contain any
>> information (rdf triples) about the parsed id
>>
>> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm
>>
>> I will add a check that ensures that a BAD_REQUEST is thrown in those cases.
>>
> fixed with http://svn.apache.org/viewvc?rev=1356788&view=rev
>
>> best
>> Rupert
>>
>>
>> On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger
>> <me...@dfki.de> wrote:
>>> Hi Alessandro and all.
>>>
>>> Today we found a strange behaviour in one of my tests that uses update
>>> functionality of the entityhub/entity. When trying to update a non-existing
>>> entity ( = erroneous or non-existing id), an error code 304 (Not Modified)
>>> is returned.
>>> This makes my test notify me of a success, although intuitively, one would
>>> think of this as a fail (since I tried to update something that does not
>>> exist).
>>>
>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
>>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>> HTTP/1.1 100 Continue
>>>
>>> HTTP/1.1 304 Not Modified
>>> Server: Jetty(6.1.x)
>>>
>>> Best,
>>> melanie
>>>
>>>
>>> Am 28.06.2012 08:13, schrieb Fabian Christ:
>>>
>>>> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>>>>> So far I've made these methods return 303 See Other with the created
>>>>> resource, basically because I wanted browsers to automatically redirect
>>>>> to
>>>>> that URL when the ontology is added using the HTML form. But I've been
>>>>> thinking that perhaps returning a 201 CREATED would be more appropriate
>>>>> on
>>>>> the REST side.
>>>> I think 201 is the right way to go. The response of a POST just tells
>>>> you that the resource was created and optionally where it was created
>>>> using the Location header.
>>>>
>>>> You can also use 303 and hope that the client interprets it correctly.
>>>> But this response may not be the right one for all clients. Another
>>>> client than a browser may not need the redirect and will perhaps be
>>>> confused.
>>>>
>>>> Therefore, the 201 is IMO the best solution and instead implement the
>>>> redirect separately.
>>>>
>>>> Best,
>>>> - Fabian
>>>
>>
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
>
>
Re: rules endpoint refactoring
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Melanie, sorry for the delay but I've been sick today.
On 8/22/12 12:47 PM, Melanie Reiplinger wrote:
> Thank you a lot, for me this seems to work. I get e.g.
>
> [...]
> and also for the SPARQLObject it works:
>
> {"recipe":"<http:\/\/www.dfki.de\/mere01\/recipe\/r1>","adaptedTo":"org.apache.stanbol.rules.base.api.SPARQLObject","result":"[org.apache.stanbol.rules.adapters.sparql.SPARQLQuery@1648c53]"}
>
>
> but not for the other two classes, there it logs
> ClassNotFoundExceptions, just as for you.
I checked it back. Those two classes work for me too. I know the output
for the SPARQLObject type is not very significant for the REST API, but
I guess that's because adapters are mainly used for the Java API.
I'm just guessing, but probably those two types are working because the
classes belong to packages exported by dependencies of the
org.apache.stanbol.rules.web bundle. Whereas Rules and ConstructQuery
are contributed by plugins that are not dependencies. Perhaps a solution
would be to do the Class.forName() trick from within the adapter manager.
> But anyway, thanks for letting me know, that already helped me. Now I
> just need CORS access. Do you think it makes sense for me to try that
> on my own by changing my version of the server according to the
> samples of endpoints where CORS already works? In principle, most of
> it seems to be about calling the addCORS and enableCORS methods in the
> right places, so maybe I'll try that once I'm done with the cmsadapter.
That's right. I can see the addCORSOrigin() call is there for the
adapter methods though. It's not working for you? Perhaps then there
should be OPTIONS preflight methods - with the enableCORSOrigin() call
- for /adapters and /adapters/{recipe} ... but should they? There are
only GET methods there.
If you would like to try it out and test it, please feel free to post a
patch to STANBOL-712 <https://issues.apache.org/jira/browse/STANBOL-712>
. Thanks a lot!
Alessandro
> Am 20.08.2012 11:59, schrieb Alessandro Adamou:
>> Sorry, this message slipped over.
>>
>> On 8/8/12 3:28 PM, Melanie Reiplinger wrote:
>>> is there any reference for the
>>> rules/adapters
>>> ( and rules/adapters/recipe)
>>> ?
>>
>> I'm afraid I don't know much about them because they're the newest
>> addition to the rules API as far as I know.
>>
>> But from the code I see, the RESTful API should be handled like this
>> (in GET methods)
>>
>> curl [-X GET]
>> http://[stanbol]/rules/adapters/{recipeID}?format={returnType}
>>
>> The adapted recipe should be wrapped in a JSON object with the fields
>> - "recipe" (the original recipe)
>> - "adaptedTo" (the format)
>> - "result" (the content)
>>
>> "returnType" is the canonical name of the Java class. From what I can
>> see the supported types should be:
>>
>> * com.hp.hpl.jena.reasoner.rulesys.Rule
>> * org.apache.clerezza.rdf.core.sparql.query.ConstructQuery
>> * org.apache.stanbol.rules.base.api.SPARQLObject
>> * org.semanticweb.owlapi.model.SWRLRule
>>
>> However this isn't working for me, since every time I tried these
>> classes, a java.lang.ClassNotFoundException was logged on a
>> class.forName() method call.
>>
>> Either the classes cannot be found because they are registered with
>> the classloaders of other OSGi bundles, and the rules.web bundle
>> doesn't have them in its classloader, or I am doing something wrong.
>> Hope someone behind this feature knows better.
>>
>> Sorry for not being of so much help here.
>>
>> Best
>> -- Alessandro
>>
>>
>>> Am 06.08.2012 17:33, schrieb Alessandro Adamou:
>>>> On 8/6/12 10:10 AM, Melanie Reiplinger wrote:
>>>>>> Do not use "application/turtle" for Turtle Syntax. Either use
>>>>>> "text/turtle" (normative MIME type) or "application/x-turtle"
>>>>>> (pre-registration MIME type). For the latter you should svn
>>>>>> update and reinstall rules/web now (I also added some additional
>>>>>> CORS support for that endpoint and fixed some wrong media type
>>>>>> headers).
>>>>>
>>>>> for which paths was it that you added the CORS support?
>>>>
>>>> /refactor/apply and /refactor/applyfile, but neither has PUT or
>>>> DELETE methods so perhaps it was not necessary.
>>>>
>>>> Alessandro
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
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 refactoring
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro.
Thank you a lot, for me this seems to work. I get e.g.
curl -i -X GET
http://[stanbol]/rules/adapters/http://www.dfki.de/mere01/recipe/r1?format=org.semanticweb.owlapi.model.SWRLRule
HTTP/1.1 200 OK
Content-Type: application/rdf+json
Transfer-Encoding: chunked
Server: Jetty(6.1.x)
{"recipe":"<http:\/\/www.dfki.de\/mere01\/recipe\/r1>",
"adaptedTo":"org.semanticweb.owlapi.model.SWRLRule",
"result":"[DLSafeRule(
Body(
ObjectPropertyAtom(<http:\/\/incubator.apache.org\/stanbol\/rules\/variables\/r>
Variable(<http:\/\/incubator.apache.org\/stanbol\/rules\/variables\/x>)
Variable(<http:\/\/incubator.apache.org\/stanbol\/rules\/variables\/z>)
)
ObjectPropertyAtom(<http:\/\/incubator.apache.org\/stanbol\/rules\/variables\/r>
Variable(<http:\/\/incubator.apache.org\/stanbol\/rules\/variables\/z>)
Variable(<http:\/\/incubator.apache.org\/stanbol\/rules\/variables\/y>)
)
)
Head(
ObjectPropertyAtom(<http:\/\/incubator.apache.org\/stanbol\/rules\/variables\/r>
Variable(<http:\/\/incubator.apache.org\/stanbol\/rules\/variables\/x>)
ariable(<http:\/\/incubator.apache.org\/stanbol\/rules\/variables\/y>)
)
)
)]"}
and also for the SPARQLObject it works:
curl -i -X GET
http://lnv-89012.dfki.uni-sb.de:9001/rules/adapters/http://www.dfki.de/mere01/recipe/r1?format=org.apache.stanbol.rules.base.api.SPARQLObject
HTTP/1.1 200 OK
Content-Type: application/rdf+json
Transfer-Encoding: chunked
Server: Jetty(6.1.x)
{"recipe":"<http:\/\/www.dfki.de\/mere01\/recipe\/r1>","adaptedTo":"org.apache.stanbol.rules.base.api.SPARQLObject","result":"[org.apache.stanbol.rules.adapters.sparql.SPARQLQuery@1648c53]"}
but not for the other two classes, there it logs
ClassNotFoundExceptions, just as for you. But anyway, thanks for letting
me know, that already helped me. Now I just need CORS access. Do you
think it makes sense for me to try that on my own by changing my version
of the server according to the samples of endpoints where CORS already
works? In principle, most of it seems to be about calling the addCORS
and enableCORS methods in the right places, so maybe I'll try that once
I'm done with the cmsadapter.
Best,
Melanie
Am 20.08.2012 11:59, schrieb Alessandro Adamou:
> Sorry, this message slipped over.
>
> On 8/8/12 3:28 PM, Melanie Reiplinger wrote:
>> is there any reference for the
>> rules/adapters
>> ( and rules/adapters/recipe)
>> ?
>
> I'm afraid I don't know much about them because they're the newest
> addition to the rules API as far as I know.
>
> But from the code I see, the RESTful API should be handled like this
> (in GET methods)
>
> curl [-X GET]
> http://[stanbol]/rules/adapters/{recipeID}?format={returnType}
>
> The adapted recipe should be wrapped in a JSON object with the fields
> - "recipe" (the original recipe)
> - "adaptedTo" (the format)
> - "result" (the content)
>
> "returnType" is the canonical name of the Java class. From what I can
> see the supported types should be:
>
> * com.hp.hpl.jena.reasoner.rulesys.Rule
> * org.apache.clerezza.rdf.core.sparql.query.ConstructQuery
> * org.apache.stanbol.rules.base.api.SPARQLObject
> * org.semanticweb.owlapi.model.SWRLRule
>
> However this isn't working for me, since every time I tried these
> classes, a java.lang.ClassNotFoundException was logged on a
> class.forName() method call.
>
> Either the classes cannot be found because they are registered with
> the classloaders of other OSGi bundles, and the rules.web bundle
> doesn't have them in its classloader, or I am doing something wrong.
> Hope someone behind this feature knows better.
>
> Sorry for not being of so much help here.
>
> Best
> -- Alessandro
>
>
>> Am 06.08.2012 17:33, schrieb Alessandro Adamou:
>>> On 8/6/12 10:10 AM, Melanie Reiplinger wrote:
>>>>> Do not use "application/turtle" for Turtle Syntax. Either use
>>>>> "text/turtle" (normative MIME type) or "application/x-turtle"
>>>>> (pre-registration MIME type). For the latter you should svn update
>>>>> and reinstall rules/web now (I also added some additional CORS
>>>>> support for that endpoint and fixed some wrong media type headers).
>>>>
>>>> for which paths was it that you added the CORS support?
>>>
>>> /refactor/apply and /refactor/applyfile, but neither has PUT or
>>> DELETE methods so perhaps it was not necessary.
>>>
>>> Alessandro
>>>
>>>
>>
>>
>
>
Re: rules endpoint refactoring
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Sorry, this message slipped over.
On 8/8/12 3:28 PM, Melanie Reiplinger wrote:
> is there any reference for the
> rules/adapters
> ( and rules/adapters/recipe)
> ?
I'm afraid I don't know much about them because they're the newest
addition to the rules API as far as I know.
But from the code I see, the RESTful API should be handled like this (in
GET methods)
curl [-X GET] http://[stanbol]/rules/adapters/{recipeID}?format={returnType}
The adapted recipe should be wrapped in a JSON object with the fields
- "recipe" (the original recipe)
- "adaptedTo" (the format)
- "result" (the content)
"returnType" is the canonical name of the Java class. From what I can
see the supported types should be:
* com.hp.hpl.jena.reasoner.rulesys.Rule
* org.apache.clerezza.rdf.core.sparql.query.ConstructQuery
* org.apache.stanbol.rules.base.api.SPARQLObject
* org.semanticweb.owlapi.model.SWRLRule
However this isn't working for me, since every time I tried these
classes, a java.lang.ClassNotFoundException was logged on a
class.forName() method call.
Either the classes cannot be found because they are registered with the
classloaders of other OSGi bundles, and the rules.web bundle doesn't
have them in its classloader, or I am doing something wrong. Hope
someone behind this feature knows better.
Sorry for not being of so much help here.
Best
-- Alessandro
> Am 06.08.2012 17:33, schrieb Alessandro Adamou:
>> On 8/6/12 10:10 AM, Melanie Reiplinger wrote:
>>>> Do not use "application/turtle" for Turtle Syntax. Either use
>>>> "text/turtle" (normative MIME type) or "application/x-turtle"
>>>> (pre-registration MIME type). For the latter you should svn update
>>>> and reinstall rules/web now (I also added some additional CORS
>>>> support for that endpoint and fixed some wrong media type headers).
>>>
>>> for which paths was it that you added the CORS support?
>>
>> /refactor/apply and /refactor/applyfile, but neither has PUT or
>> DELETE methods so perhaps it was not necessary.
>>
>> Alessandro
>>
>>
>
>
--
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 refactoring
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi again,
is there any reference for the
rules/adapters
( and rules/adapters/recipe)
?
Am 06.08.2012 17:33, schrieb Alessandro Adamou:
> On 8/6/12 10:10 AM, Melanie Reiplinger wrote:
>>> Do not use "application/turtle" for Turtle Syntax. Either use
>>> "text/turtle" (normative MIME type) or "application/x-turtle"
>>> (pre-registration MIME type). For the latter you should svn update
>>> and reinstall rules/web now (I also added some additional CORS
>>> support for that endpoint and fixed some wrong media type headers).
>>
>> for which paths was it that you added the CORS support?
>
> /refactor/apply and /refactor/applyfile, but neither has PUT or DELETE
> methods so perhaps it was not necessary.
>
> Alessandro
>
>
Re: rules endpoint refactoring
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
On 8/6/12 10:10 AM, Melanie Reiplinger wrote:
>> Do not use "application/turtle" for Turtle Syntax. Either use
>> "text/turtle" (normative MIME type) or "application/x-turtle"
>> (pre-registration MIME type). For the latter you should svn update
>> and reinstall rules/web now (I also added some additional CORS
>> support for that endpoint and fixed some wrong media type headers).
>
> for which paths was it that you added the CORS support?
/refactor/apply and /refactor/applyfile, but neither has PUT or DELETE
methods so perhaps it was not necessary.
Alessandro
--
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 refactoring
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro,
Am 02.08.2012 12:02, schrieb Alessandro Adamou:
> Hi Melanie,
>
> On 8/2/12 10:38 AM, Melanie Reiplinger wrote:
>> curl -X POST -H "Content-Type: multipart/form-data" -H "Accept:
>> application/turtle" -F recipe="is(http://dbpedia.org/ontology/Person,
>> ?x) -> is(http://rdf.data-vocabulary.org/Person, ?x)" -F
>> input=@personsRDF.xml
>> http://lnv-89012.dfki.uni-sb.de:9001/refactor/apply
>>
>> For this, I get HTTP ERROR 406 Problem accessing /refactor/apply.
>> Reason: Not Acceptable.
>
> Do not use "application/turtle" for Turtle Syntax. Either use
> "text/turtle" (normative MIME type) or "application/x-turtle"
> (pre-registration MIME type). For the latter you should svn update and
> reinstall rules/web now (I also added some additional CORS support for
> that endpoint and fixed some wrong media type headers).
for which paths was it that you added the CORS support?
thanks
melanie
Re: rules endpoint refactoring
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Melanie,
On 8/2/12 10:38 AM, Melanie Reiplinger wrote:
> curl -X POST -H "Content-Type: multipart/form-data" -H "Accept:
> application/turtle" -F recipe="is(http://dbpedia.org/ontology/Person,
> ?x) -> is(http://rdf.data-vocabulary.org/Person, ?x)" -F
> input=@personsRDF.xml http://lnv-89012.dfki.uni-sb.de:9001/refactor/apply
>
> For this, I get HTTP ERROR 406 Problem accessing /refactor/apply.
> Reason: Not Acceptable.
Do not use "application/turtle" for Turtle Syntax. Either use
"text/turtle" (normative MIME type) or "application/x-turtle"
(pre-registration MIME type). For the latter you should svn update and
reinstall rules/web now (I also added some additional CORS support for
that endpoint and fixed some wrong media type headers).
Also, do not forget that 1) full IRIs must be enclosed in <>, and the
rules must be named and enclosed in square brackets, e.g.
personTypes[is(<http://dbpedia.org/ontology/Person>, ?x) ->
is(<http://rdf.data-vocabulary.org/Person>, ?x)]
> curl -X POST -H "Accept: application/rdf+xml" -F input=@personsRDF.xml
> -F
> recipe="http://<stanbol>/rules/recipe/http://www.dfki.de/mere01/recipe/TestRecipe"
> http://<stanbol>/refactor
>
> for an existing recipe with at least one rule in it gives me 'HTTP
> ERROR 404 Problem accessing /refactor/. Reason: Not Found
Perhaps the recipe was not found. You need to use the recipe ID, not the
full URL e.g. "recipe=http://www.dfki.de/mere01/recipe/TestRecipe"
(you can try if simpler recipe IDs work as well)
> Or does it have to be curl -d for /refactor ? (because in one of the
> versions on the RESTful API it is also shown with GET -G -d). But for
> this I also get the Not Found error.
No it doesn't look like there's any methods that accepts URLencoded
forms so I think there's no need for -d .
> Btw: how do I get namespace specification into my recipes? (like the
> google or dbpedia shorthands shown in the tutorial) Do I simply add
> them in the rules body?
At the beginning of the recipe, like this:
dbpont = <http://dbpedia.org/ontology/> .
datavoc = <http://rdf.data-vocabulary.org/> .
personTypes[is(dbpont:Person, ?x) -> is(datavoc:Person, ?x)]
Note that you must not enclose resources in the rule body with "<" ">"
when you use prefixes.
hth
Alessandro
--
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
rules endpoint refactoring
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi all.
Has someone already used the /refactor and /refactor/apply(file)
services of the rules endpoint?
I tried the curl commands from the hands-on tutorial, none would work
for me. Maybe I'm just making syntax errors here ? (although I already
tried some variants) e.g.:
curl -X POST -H "Content-Type: multipart/form-data" -H "Accept:
application/turtle" -F recipe="is(http://dbpedia.org/ontology/Person,
?x) -> is(http://rdf.data-vocabulary.org/Person, ?x)" -F
input=@personsRDF.xml http://lnv-89012.dfki.uni-sb.de:9001/refactor/apply
For this, I get HTTP ERROR 406 Problem accessing /refactor/apply.
Reason: Not Acceptable.
curl -X POST -H "Accept: application/rdf+xml" -F input=@personsRDF.xml
-F
recipe="http://<stanbol>/rules/recipe/http://www.dfki.de/mere01/recipe/TestRecipe"
http://<stanbol>/refactor
for an existing recipe with at least one rule in it gives me 'HTTP ERROR
404 Problem accessing /refactor/. Reason: Not Found
Or does it have to be curl -d for /refactor ? (because in one of the
versions on the RESTful API it is also shown with GET -G -d). But for
this I also get the Not Found error.
Btw: how do I get namespace specification into my recipes? (like the
google or dbpedia shorthands shown in the tutorial) Do I simply add them
in the rules body?
Thanks,
Melanie
Re: CORS for rules endpoint
Posted by Melanie Reiplinger <me...@dfki.de>.
Ok, I opened a 'wish' (https://issues.apache.org/jira/browse/STANBOL-712)
let's see if someone will find the time to grant it :-)
Am 01.08.2012 12:43, schrieb Alessandro Adamou:
> I'm not sure if this is the source of the problem, but the rules
> endpoint seems to be handling CORS preflight only on the root resource
> and not in the subresources. And there are a few GET methods that
> still need to add the CORS origin.
>
> I'm afraid I don't have the time to fix and test it myself, but a
> ticket could be opened in the meantime.
>
> Alessandro
>
>
> On 8/1/12 12:01 PM, Melanie Reiplinger wrote:
>> Hi Alessandro and all,
>>
>>
>> Is CORS access to the rules endpoint granted?
>>
>> When I do e.g. a PUT to
>> http://<stanbol>/rules/recipe/http://www.dfki.de/mere01/recipe/melaniesRecipe
>>
>> in order to create a new recipe
>> "http://www.dfki.de/mere01/recipe/melaniesRecipe",
>> I'm getting a real strange response header:
>>
>> Allow:
>> OPTIONS,POST,GET,DELETE,HEAD,PUT
>>
>> This looks a bit ancient, most of the other endpoints return at least
>>
>> Access-Control-Allow-Origin
>> and
>>
>> 1.
>> Access-Control-Allow-Headers
>> 2.
>> Access-Control-Allow-Methods
>>
>>
>>
>>
>> Best,
>> melanie
>>
>> Am 15.07.2012 13:21, schrieb Melanie Reiplinger:
>>> Hi Alessandro.
>>>
>>> Sorry to bother you again, but I have a few more questions for the
>>> rules endpoint.
>>>
>>> Am 13.07.2012 16:09, schrieb Alessandro Adamou:
>>>> On 7/13/12 3:57 PM, Melanie Reiplinger wrote:
>>>>> Am 13.07.2012 15:33, schrieb Alessandro Adamou:
>>>>>> Here is what worked for me:
>>>>>>
>>>>>> curl -X POST -F "rules=transitivity[has(?r, ?x, ?z) . has(?r, ?z,
>>>>>> ?y) -> has(?r, ?x, ?y)]" -F "description=Test rule"
>>>>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>>>
>>>>> great, works fine. Now, if I want to get the rule itself, to what
>>>>> URL do I send the GET? I tested
>>>>> <stanbol>/rules/rule/transitivity
>>>>> <stanbol>/rules/transitivity
>>>>> <stanbol>/rule/transitivity
>>>>> <stanbol>/rules/find/rules
>>>>
>>>> The last one with query parameters is correct. Try this:
>>>>
>>>> curl -H "Accept: application/rdf+xml"
>>>> http://[stanbol]/rules/find/rules?name=rans
>>>>
>>>> curl -H "Accept: application/rdf+xml"
>>>> http://[stanbol]/rules/find/rules?description=irst
>>>
>>> hmm, ok, so one could assume that it works analogously for the
>>> rules/find/recipes. But when doing
>>>
>>> curl -H "Accept: text/turtle"
>>> http://<stanbol>/rules/find/recipes?name=r2
>>> or
>>> curl -H "Accept: text/turtle"
>>> http://<stanbol>/rules/find/recipes?name=http://www.dfki.de/mere01/recipe/r2
>>>
>>> I get a 404 Not Found.
>>> (for a recipe named 'r2', created by
>>> curl -i -X PUT
>>> http://lnv-89012.dfki.uni-sb.de:9001/rules/recipe/http://www.dfki.de/mere01/recipe/r2
>>> )
>>>
>>> what am I doing wrong?
>>>
>>>
>>> Also: How do we then remove rules from a recipe, if we cannot
>>> address them simply by attaching their URI or name to the endpoint's
>>> URL?
>>>
>>> And one more: For the refactoring functionality I didn't get very
>>> far. First thing I wanted to give some minimal toy RDF graph as an
>>> input and refactor via the RESTful Interface. This gives me the (not
>>> very informative) message:
>>> "The site <stanbol> says: Error".
>>> (in the form of an alert window). This error might be due to
>>> virtually anything. My toy example is
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <rdf:RDF
>>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>> xmlns:dbpedia="http://dbpedia.org/property/">
>>> <rdf:Description rdf:about="urn:example:person:ernie">
>>> <dbpedia:Person>Ernie</dbpedia:Person>
>>> <dbpedia:profession>Friend of Bert</dbpedia:profession>
>>> </rdf:Description>
>>> </rdf:RDF>
>>>
>>> and I was hoping for something like an application of the
>>> "peopleProfessionRule" rule or something. (I already checked on
>>> http://www.w3.org/RDF/Validator/ to make sure it is well-formed).
>>>
>>> best
>>> melanie
>>>
>>>
>>>>
>>>> You can also ask for:
>>>>
>>>> text/turtle
>>>> text/owl-manchester
>>>> text/owl-functional
>>>> application/owl+xml
>>>> application/rdf+json
>>>>
>>>> Theoretically, it should also support
>>>>
>>>> application/json (JSON-LD)
>>>> text/plain
>>>>
>>>> but I don't see a body writer registered with rule lists so it
>>>> didn't work for me.
>>>>
>>>> Best,
>>>> Alessandro
>>>>
>>>>
>>>>>> To check if it has been stored (and therefore parsed), you can do
>>>>>> a GET on
>>>>>>
>>>>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>>>>
>>>>>> requesting text/plain or some KR format such as
>>>>>>
>>>>>> text/turtle
>>>>>> application/rdf+xml
>>>>>> text/owl-manchester
>>>>>>
>>>>>> Hope this helps,
>>>>>>
>>>>>> Alessandro
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: CORS for rules endpoint
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
I'm not sure if this is the source of the problem, but the rules
endpoint seems to be handling CORS preflight only on the root resource
and not in the subresources. And there are a few GET methods that still
need to add the CORS origin.
I'm afraid I don't have the time to fix and test it myself, but a ticket
could be opened in the meantime.
Alessandro
On 8/1/12 12:01 PM, Melanie Reiplinger wrote:
> Hi Alessandro and all,
>
>
> Is CORS access to the rules endpoint granted?
>
> When I do e.g. a PUT to
> http://<stanbol>/rules/recipe/http://www.dfki.de/mere01/recipe/melaniesRecipe
>
> in order to create a new recipe
> "http://www.dfki.de/mere01/recipe/melaniesRecipe",
> I'm getting a real strange response header:
>
> Allow:
> OPTIONS,POST,GET,DELETE,HEAD,PUT
>
> This looks a bit ancient, most of the other endpoints return at least
>
> Access-Control-Allow-Origin
> and
>
> 1.
> Access-Control-Allow-Headers
> 2.
> Access-Control-Allow-Methods
>
>
>
>
> Best,
> melanie
>
> Am 15.07.2012 13:21, schrieb Melanie Reiplinger:
>> Hi Alessandro.
>>
>> Sorry to bother you again, but I have a few more questions for the
>> rules endpoint.
>>
>> Am 13.07.2012 16:09, schrieb Alessandro Adamou:
>>> On 7/13/12 3:57 PM, Melanie Reiplinger wrote:
>>>> Am 13.07.2012 15:33, schrieb Alessandro Adamou:
>>>>> Here is what worked for me:
>>>>>
>>>>> curl -X POST -F "rules=transitivity[has(?r, ?x, ?z) . has(?r, ?z,
>>>>> ?y) -> has(?r, ?x, ?y)]" -F "description=Test rule"
>>>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>>
>>>> great, works fine. Now, if I want to get the rule itself, to what
>>>> URL do I send the GET? I tested
>>>> <stanbol>/rules/rule/transitivity
>>>> <stanbol>/rules/transitivity
>>>> <stanbol>/rule/transitivity
>>>> <stanbol>/rules/find/rules
>>>
>>> The last one with query parameters is correct. Try this:
>>>
>>> curl -H "Accept: application/rdf+xml"
>>> http://[stanbol]/rules/find/rules?name=rans
>>>
>>> curl -H "Accept: application/rdf+xml"
>>> http://[stanbol]/rules/find/rules?description=irst
>>
>> hmm, ok, so one could assume that it works analogously for the
>> rules/find/recipes. But when doing
>>
>> curl -H "Accept: text/turtle"
>> http://<stanbol>/rules/find/recipes?name=r2
>> or
>> curl -H "Accept: text/turtle"
>> http://<stanbol>/rules/find/recipes?name=http://www.dfki.de/mere01/recipe/r2
>>
>> I get a 404 Not Found.
>> (for a recipe named 'r2', created by
>> curl -i -X PUT
>> http://lnv-89012.dfki.uni-sb.de:9001/rules/recipe/http://www.dfki.de/mere01/recipe/r2
>> )
>>
>> what am I doing wrong?
>>
>>
>> Also: How do we then remove rules from a recipe, if we cannot address
>> them simply by attaching their URI or name to the endpoint's URL?
>>
>> And one more: For the refactoring functionality I didn't get very
>> far. First thing I wanted to give some minimal toy RDF graph as an
>> input and refactor via the RESTful Interface. This gives me the (not
>> very informative) message:
>> "The site <stanbol> says: Error".
>> (in the form of an alert window). This error might be due to
>> virtually anything. My toy example is
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <rdf:RDF
>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>> xmlns:dbpedia="http://dbpedia.org/property/">
>> <rdf:Description rdf:about="urn:example:person:ernie">
>> <dbpedia:Person>Ernie</dbpedia:Person>
>> <dbpedia:profession>Friend of Bert</dbpedia:profession>
>> </rdf:Description>
>> </rdf:RDF>
>>
>> and I was hoping for something like an application of the
>> "peopleProfessionRule" rule or something. (I already checked on
>> http://www.w3.org/RDF/Validator/ to make sure it is well-formed).
>>
>> best
>> melanie
>>
>>
>>>
>>> You can also ask for:
>>>
>>> text/turtle
>>> text/owl-manchester
>>> text/owl-functional
>>> application/owl+xml
>>> application/rdf+json
>>>
>>> Theoretically, it should also support
>>>
>>> application/json (JSON-LD)
>>> text/plain
>>>
>>> but I don't see a body writer registered with rule lists so it
>>> didn't work for me.
>>>
>>> Best,
>>> Alessandro
>>>
>>>
>>>>> To check if it has been stored (and therefore parsed), you can do
>>>>> a GET on
>>>>>
>>>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>>>
>>>>> requesting text/plain or some KR format such as
>>>>>
>>>>> text/turtle
>>>>> application/rdf+xml
>>>>> text/owl-manchester
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>> Alessandro
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
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
CORS for rules endpoint
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro and all,
Is CORS access to the rules endpoint granted?
When I do e.g. a PUT to
http://<stanbol>/rules/recipe/http://www.dfki.de/mere01/recipe/melaniesRecipe
in order to create a new recipe
"http://www.dfki.de/mere01/recipe/melaniesRecipe",
I'm getting a real strange response header:
Allow:
OPTIONS,POST,GET,DELETE,HEAD,PUT
This looks a bit ancient, most of the other endpoints return at least
Access-Control-Allow-Origin
and
1.
Access-Control-Allow-Headers
2.
Access-Control-Allow-Methods
Best,
melanie
Am 15.07.2012 13:21, schrieb Melanie Reiplinger:
> Hi Alessandro.
>
> Sorry to bother you again, but I have a few more questions for the
> rules endpoint.
>
> Am 13.07.2012 16:09, schrieb Alessandro Adamou:
>> On 7/13/12 3:57 PM, Melanie Reiplinger wrote:
>>> Am 13.07.2012 15:33, schrieb Alessandro Adamou:
>>>> Here is what worked for me:
>>>>
>>>> curl -X POST -F "rules=transitivity[has(?r, ?x, ?z) . has(?r, ?z,
>>>> ?y) -> has(?r, ?x, ?y)]" -F "description=Test rule"
>>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>
>>> great, works fine. Now, if I want to get the rule itself, to what
>>> URL do I send the GET? I tested
>>> <stanbol>/rules/rule/transitivity
>>> <stanbol>/rules/transitivity
>>> <stanbol>/rule/transitivity
>>> <stanbol>/rules/find/rules
>>
>> The last one with query parameters is correct. Try this:
>>
>> curl -H "Accept: application/rdf+xml"
>> http://[stanbol]/rules/find/rules?name=rans
>>
>> curl -H "Accept: application/rdf+xml"
>> http://[stanbol]/rules/find/rules?description=irst
>
> hmm, ok, so one could assume that it works analogously for the
> rules/find/recipes. But when doing
>
> curl -H "Accept: text/turtle" http://<stanbol>/rules/find/recipes?name=r2
> or
> curl -H "Accept: text/turtle"
> http://<stanbol>/rules/find/recipes?name=http://www.dfki.de/mere01/recipe/r2
>
> I get a 404 Not Found.
> (for a recipe named 'r2', created by
> curl -i -X PUT
> http://lnv-89012.dfki.uni-sb.de:9001/rules/recipe/http://www.dfki.de/mere01/recipe/r2
> )
>
> what am I doing wrong?
>
>
> Also: How do we then remove rules from a recipe, if we cannot address
> them simply by attaching their URI or name to the endpoint's URL?
>
> And one more: For the refactoring functionality I didn't get very far.
> First thing I wanted to give some minimal toy RDF graph as an input
> and refactor via the RESTful Interface. This gives me the (not very
> informative) message:
> "The site <stanbol> says: Error".
> (in the form of an alert window). This error might be due to virtually
> anything. My toy example is
>
> <?xml version="1.0" encoding="UTF-8"?>
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:dbpedia="http://dbpedia.org/property/">
> <rdf:Description rdf:about="urn:example:person:ernie">
> <dbpedia:Person>Ernie</dbpedia:Person>
> <dbpedia:profession>Friend of Bert</dbpedia:profession>
> </rdf:Description>
> </rdf:RDF>
>
> and I was hoping for something like an application of the
> "peopleProfessionRule" rule or something. (I already checked on
> http://www.w3.org/RDF/Validator/ to make sure it is well-formed).
>
> best
> melanie
>
>
>>
>> You can also ask for:
>>
>> text/turtle
>> text/owl-manchester
>> text/owl-functional
>> application/owl+xml
>> application/rdf+json
>>
>> Theoretically, it should also support
>>
>> application/json (JSON-LD)
>> text/plain
>>
>> but I don't see a body writer registered with rule lists so it didn't
>> work for me.
>>
>> Best,
>> Alessandro
>>
>>
>>>> To check if it has been stored (and therefore parsed), you can do a
>>>> GET on
>>>>
>>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>>
>>>> requesting text/plain or some KR format such as
>>>>
>>>> text/turtle
>>>> application/rdf+xml
>>>> text/owl-manchester
>>>>
>>>> Hope this helps,
>>>>
>>>> Alessandro
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: rules endpoint
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Melanie,
On 8/1/12 11:26 AM, Melanie Reiplinger wrote:
> ok so I tried this. I first created a recipe r2 and then uploaded a
> rule by
>
> curl -X POST -F "rules=transitivity[has(?r, ?x, ?z) . has(?r, ?z, ?y)
> -> has(?r, ?x, ?y)]" -F "description=transitivity"
> http://dev.iks-project.eu:8081/rules/recipe/http://www.dfki.de/mere01/recipe/r2
>
> This works fine, by GET I can see that the rule has been integrated
> into the recipe. Now I try to delete:
>
> curl -i -X DELETE
> http://dev.iks-project.eu:8081/rules/recipe/http://www.dfki.de/mere01/recipe/r2?rule=transitivity
>
> and I get '200 OK'. But when checking with GET, the 'transitivity'
> rule is still part of the r2 recipe. Seems it was not deleted.
I haven't dug this as I'm not very rule store savvy, but it might be a
bug in the Clerezza rule store. Maybe you could open a ticket on
https://issues.apache.org/jira/browse/STANBOL ? (be sure to include
Rules in the component field).
> Also, submitting the very same rule twice to this recipe does not
> throw any error.
From what I can see, Rule does not override equals() or hashCode() so
in general if two rules have the same body, they won't be recognized as
equal unless their names are. But I guess you're right, it should at
least return a 409 Conflict if the rule names matched.
>> Did you use an HTML interface somewhere? Seems like the refactor
>> endpoint doesn't have one at the moment. Did you try it through the
>> tutorial in the /rules endpoint?
>
> It doesn't have an interface??? I was trying on the /rules/ RESTful
> interface. You can load an RDF file and then click at 'refactor'. I
> thought that would do the job while only testing the default
> transformation patterns.
Yes that's the "hands-on" form, it's intended for the live tutorial but
I'm sure a 'regular' GUI will be added too at some point. In the
meantime, I guess you can use that form for testing.
What I meant is that literally the "[stanbol]/refactor" endpoint doesn't
have a GUI yet (returns 500 on me), but that's okay because I think that
endpoint should be moved to a sub-endpoint of /rules.
> Sorry, I didn't try that since it requires that I pass a recipe ID
> there, and I don't know by which ID these default rules go. So I'll
> report on that as soon as I have my own recipe to use for transformation.
I think it doesn't have one. It is also possible to refactor by passing
the recipe in the payload without storing it with an ID. I think the
tutorial does exactly that.
HTH
--alessandro
>>>> You can also ask for:
>>>>
>>>> text/turtle
>>>> text/owl-manchester
>>>> text/owl-functional
>>>> application/owl+xml
>>>> application/rdf+json
>>>>
>>>> Theoretically, it should also support
>>>>
>>>> application/json (JSON-LD)
>>>> text/plain
>>>>
>>>> but I don't see a body writer registered with rule lists so it
>>>> didn't work for me.
>>>>
>>>> Best,
>>>> Alessandro
>>>>
>>>>
>>>>>> To check if it has been stored (and therefore parsed), you can do
>>>>>> a GET on
>>>>>>
>>>>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>>>>
>>>>>> requesting text/plain or some KR format such as
>>>>>>
>>>>>> text/turtle
>>>>>> application/rdf+xml
>>>>>> text/owl-manchester
>>>>>>
>>>>>> Hope this helps,
>>>>>>
>>>>>> Alessandro
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
--
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
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro.
Am 16.07.2012 12:18, schrieb Alessandro Adamou:
> On 7/15/12 1:21 PM, Melanie Reiplinger wrote:
>> hmm, ok, so one could assume that it works analogously for the
>> rules/find/recipes. But when doing
>>
>> curl -H "Accept: text/turtle"
>> http://<stanbol>/rules/find/recipes?name=r2
>> or
>> curl -H "Accept: text/turtle"
>> http://<stanbol>/rules/find/recipes?name=http://www.dfki.de/mere01/recipe/r2
>>
>> I get a 404 Not Found.
>> (for a recipe named 'r2', created by
>> curl -i -X PUT
>> http://lnv-89012.dfki.uni-sb.de:9001/rules/recipe/http://www.dfki.de/mere01/recipe/r2
>> )
>>
>> what am I doing wrong?
>
> Nothing, except for assuming (with good reason) that it worked exactly
> the same. The rules/find/recipes resource does not support the "name"
> parameter at present, it only supports "description".
>
> This means that if you want a recipe to be found, it must have been
> created with a comment, such as
>
> curl -i -X PUT
> http://lnv-89012.dfki.uni-sb.de:9001/rules/recipe/http://www.dfki.de/mere01/recipe/r2?description=Test%20recipe
>
> (not sure what happens with the URLencoded value for "description",
> though)
>
> then
>
> curl -H "Accept: text/turtle"
> http://lnv-89012.dfki.uni-sb.de:9001/rules/find/recipes?description=est
>
> Sorry for not finding this out earlier and misleading you.
Never mind, I'm here to test these things :-)
Fine, this one works.
>
>> Also: How do we then remove rules from a recipe, if we cannot address
>> them simply by attaching their URI or name to the endpoint's URL?
>
> (again by checking the code) The recipe/rule path is currently in the
> form
>
> /rules/recipe/{recipeId}?rule={ruleId}
>
> and the DELETE works the same way, depending on "rule" having a value
> or not.
>
> It might be better to have something like
>
> /rules/recipe/{recipeId}/{ruleId}
ok so I tried this. I first created a recipe r2 and then uploaded a rule by
curl -X POST -F "rules=transitivity[has(?r, ?x, ?z) . has(?r, ?z, ?y)
-> has(?r, ?x, ?y)]" -F "description=transitivity"
http://dev.iks-project.eu:8081/rules/recipe/http://www.dfki.de/mere01/recipe/r2
This works fine, by GET I can see that the rule has been integrated into
the recipe. Now I try to delete:
curl -i -X DELETE
http://dev.iks-project.eu:8081/rules/recipe/http://www.dfki.de/mere01/recipe/r2?rule=transitivity
and I get '200 OK'. But when checking with GET, the 'transitivity' rule
is still part of the r2 recipe. Seems it was not deleted. Also,
submitting the very same rule twice to this recipe does not throw any
error.
>
> but before that we should make sure that recipeId allows simple
> non-URI identifiers and refactoring works with non-URIs (which maybe
> now does).
>
>> And one more: For the refactoring functionality I didn't get very
>> far. First thing I wanted to give some minimal toy RDF graph as an
>> input and refactor via the RESTful Interface. This gives me the (not
>> very informative) message:
>> "The site <stanbol> says: Error".
>> (in the form of an alert window). This error might be due to
>> virtually anything. My toy example is
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <rdf:RDF
>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>> xmlns:dbpedia="http://dbpedia.org/property/">
>> <rdf:Description rdf:about="urn:example:person:ernie">
>> <dbpedia:Person>Ernie</dbpedia:Person>
>> <dbpedia:profession>Friend of Bert</dbpedia:profession>
>> </rdf:Description>
>> </rdf:RDF>
>>
>> and I was hoping for something like an application of the
>> "peopleProfessionRule" rule or something. (I already checked on
>> http://www.w3.org/RDF/Validator/ to make sure it is well-formed).
>
> Here you're entering a realm I know even less, so I'm afraid I'm going
> to need some more info.
>
> What does the rule look like? Remember with that RDF there (with
> literal triples / datatype assertions in OWL) the rules must be of the
> form values() instead of has()
ok, I will try to build my own recipe with rules that use the values()
assertion.
>
> Did you use an HTML interface somewhere? Seems like the refactor
> endpoint doesn't have one at the moment. Did you try it through the
> tutorial in the /rules endpoint?
It doesn't have an interface??? I was trying on the /rules/ RESTful
interface. You can load an RDF file and then click at 'refactor'. I
thought that would do the job while only testing the default
transformation patterns.
>
> What response did you get by issuing the equivalent request to
> /refactor via curl?
Sorry, I didn't try that since it requires that I pass a recipe ID
there, and I don't know by which ID these default rules go. So I'll
report on that as soon as I have my own recipe to use for transformation.
Best,
melanie
>
> best
> -- Alessandro
>
>
>>> You can also ask for:
>>>
>>> text/turtle
>>> text/owl-manchester
>>> text/owl-functional
>>> application/owl+xml
>>> application/rdf+json
>>>
>>> Theoretically, it should also support
>>>
>>> application/json (JSON-LD)
>>> text/plain
>>>
>>> but I don't see a body writer registered with rule lists so it
>>> didn't work for me.
>>>
>>> Best,
>>> Alessandro
>>>
>>>
>>>>> To check if it has been stored (and therefore parsed), you can do
>>>>> a GET on
>>>>>
>>>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>>>
>>>>> requesting text/plain or some KR format such as
>>>>>
>>>>> text/turtle
>>>>> application/rdf+xml
>>>>> text/owl-manchester
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>> Alessandro
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
Re: rules endpoint
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
On 7/15/12 1:21 PM, Melanie Reiplinger wrote:
> hmm, ok, so one could assume that it works analogously for the
> rules/find/recipes. But when doing
>
> curl -H "Accept: text/turtle" http://<stanbol>/rules/find/recipes?name=r2
> or
> curl -H "Accept: text/turtle"
> http://<stanbol>/rules/find/recipes?name=http://www.dfki.de/mere01/recipe/r2
>
> I get a 404 Not Found.
> (for a recipe named 'r2', created by
> curl -i -X PUT
> http://lnv-89012.dfki.uni-sb.de:9001/rules/recipe/http://www.dfki.de/mere01/recipe/r2
> )
>
> what am I doing wrong?
Nothing, except for assuming (with good reason) that it worked exactly
the same. The rules/find/recipes resource does not support the "name"
parameter at present, it only supports "description".
This means that if you want a recipe to be found, it must have been
created with a comment, such as
curl -i -X PUT
http://lnv-89012.dfki.uni-sb.de:9001/rules/recipe/http://www.dfki.de/mere01/recipe/r2?description=Test%20recipe
(not sure what happens with the URLencoded value for "description", though)
then
curl -H "Accept: text/turtle"
http://lnv-89012.dfki.uni-sb.de:9001/rules/find/recipes?description=est
Sorry for not finding this out earlier and misleading you.
> Also: How do we then remove rules from a recipe, if we cannot address
> them simply by attaching their URI or name to the endpoint's URL?
(again by checking the code) The recipe/rule path is currently in the form
/rules/recipe/{recipeId}?rule={ruleId}
and the DELETE works the same way, depending on "rule" having a value or
not.
It might be better to have something like
/rules/recipe/{recipeId}/{ruleId}
but before that we should make sure that recipeId allows simple non-URI
identifiers and refactoring works with non-URIs (which maybe now does).
> And one more: For the refactoring functionality I didn't get very far.
> First thing I wanted to give some minimal toy RDF graph as an input
> and refactor via the RESTful Interface. This gives me the (not very
> informative) message:
> "The site <stanbol> says: Error".
> (in the form of an alert window). This error might be due to virtually
> anything. My toy example is
>
> <?xml version="1.0" encoding="UTF-8"?>
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:dbpedia="http://dbpedia.org/property/">
> <rdf:Description rdf:about="urn:example:person:ernie">
> <dbpedia:Person>Ernie</dbpedia:Person>
> <dbpedia:profession>Friend of Bert</dbpedia:profession>
> </rdf:Description>
> </rdf:RDF>
>
> and I was hoping for something like an application of the
> "peopleProfessionRule" rule or something. (I already checked on
> http://www.w3.org/RDF/Validator/ to make sure it is well-formed).
Here you're entering a realm I know even less, so I'm afraid I'm going
to need some more info.
What does the rule look like? Remember with that RDF there (with literal
triples / datatype assertions in OWL) the rules must be of the form
values() instead of has()
Did you use an HTML interface somewhere? Seems like the refactor
endpoint doesn't have one at the moment. Did you try it through the
tutorial in the /rules endpoint?
What response did you get by issuing the equivalent request to /refactor
via curl?
best
-- Alessandro
>> You can also ask for:
>>
>> text/turtle
>> text/owl-manchester
>> text/owl-functional
>> application/owl+xml
>> application/rdf+json
>>
>> Theoretically, it should also support
>>
>> application/json (JSON-LD)
>> text/plain
>>
>> but I don't see a body writer registered with rule lists so it didn't
>> work for me.
>>
>> Best,
>> Alessandro
>>
>>
>>>> To check if it has been stored (and therefore parsed), you can do a
>>>> GET on
>>>>
>>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>>
>>>> requesting text/plain or some KR format such as
>>>>
>>>> text/turtle
>>>> application/rdf+xml
>>>> text/owl-manchester
>>>>
>>>> Hope this helps,
>>>>
>>>> Alessandro
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
--
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
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro.
Sorry to bother you again, but I have a few more questions for the rules
endpoint.
Am 13.07.2012 16:09, schrieb Alessandro Adamou:
> On 7/13/12 3:57 PM, Melanie Reiplinger wrote:
>> Am 13.07.2012 15:33, schrieb Alessandro Adamou:
>>> Here is what worked for me:
>>>
>>> curl -X POST -F "rules=transitivity[has(?r, ?x, ?z) . has(?r, ?z,
>>> ?y) -> has(?r, ?x, ?y)]" -F "description=Test rule"
>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>
>> great, works fine. Now, if I want to get the rule itself, to what URL
>> do I send the GET? I tested
>> <stanbol>/rules/rule/transitivity
>> <stanbol>/rules/transitivity
>> <stanbol>/rule/transitivity
>> <stanbol>/rules/find/rules
>
> The last one with query parameters is correct. Try this:
>
> curl -H "Accept: application/rdf+xml"
> http://[stanbol]/rules/find/rules?name=rans
>
> curl -H "Accept: application/rdf+xml"
> http://[stanbol]/rules/find/rules?description=irst
hmm, ok, so one could assume that it works analogously for the
rules/find/recipes. But when doing
curl -H "Accept: text/turtle" http://<stanbol>/rules/find/recipes?name=r2
or
curl -H "Accept: text/turtle"
http://<stanbol>/rules/find/recipes?name=http://www.dfki.de/mere01/recipe/r2
I get a 404 Not Found.
(for a recipe named 'r2', created by
curl -i -X PUT
http://lnv-89012.dfki.uni-sb.de:9001/rules/recipe/http://www.dfki.de/mere01/recipe/r2
)
what am I doing wrong?
Also: How do we then remove rules from a recipe, if we cannot address
them simply by attaching their URI or name to the endpoint's URL?
And one more: For the refactoring functionality I didn't get very far.
First thing I wanted to give some minimal toy RDF graph as an input and
refactor via the RESTful Interface. This gives me the (not very
informative) message:
"The site <stanbol> says: Error".
(in the form of an alert window). This error might be due to virtually
anything. My toy example is
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dbpedia="http://dbpedia.org/property/">
<rdf:Description rdf:about="urn:example:person:ernie">
<dbpedia:Person>Ernie</dbpedia:Person>
<dbpedia:profession>Friend of Bert</dbpedia:profession>
</rdf:Description>
</rdf:RDF>
and I was hoping for something like an application of the
"peopleProfessionRule" rule or something. (I already checked on
http://www.w3.org/RDF/Validator/ to make sure it is well-formed).
best
melanie
>
> You can also ask for:
>
> text/turtle
> text/owl-manchester
> text/owl-functional
> application/owl+xml
> application/rdf+json
>
> Theoretically, it should also support
>
> application/json (JSON-LD)
> text/plain
>
> but I don't see a body writer registered with rule lists so it didn't
> work for me.
>
> Best,
> Alessandro
>
>
>>> To check if it has been stored (and therefore parsed), you can do a
>>> GET on
>>>
>>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>>
>>> requesting text/plain or some KR format such as
>>>
>>> text/turtle
>>> application/rdf+xml
>>> text/owl-manchester
>>>
>>> Hope this helps,
>>>
>>> Alessandro
>>>
>>
>>
>>
>
>
Re: rules endpoint
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
On 7/13/12 3:57 PM, Melanie Reiplinger wrote:
> Am 13.07.2012 15:33, schrieb Alessandro Adamou:
>> Here is what worked for me:
>>
>> curl -X POST -F "rules=transitivity[has(?r, ?x, ?z) . has(?r, ?z, ?y)
>> -> has(?r, ?x, ?y)]" -F "description=Test rule"
>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>
> great, works fine. Now, if I want to get the rule itself, to what URL
> do I send the GET? I tested
> <stanbol>/rules/rule/transitivity
> <stanbol>/rules/transitivity
> <stanbol>/rule/transitivity
> <stanbol>/rules/find/rules
The last one with query parameters is correct. Try this:
curl -H "Accept: application/rdf+xml"
http://[stanbol]/rules/find/rules?name=rans
curl -H "Accept: application/rdf+xml"
http://[stanbol]/rules/find/rules?description=irst
You can also ask for:
text/turtle
text/owl-manchester
text/owl-functional
application/owl+xml
application/rdf+json
Theoretically, it should also support
application/json (JSON-LD)
text/plain
but I don't see a body writer registered with rule lists so it didn't
work for me.
Best,
Alessandro
>> To check if it has been stored (and therefore parsed), you can do a
>> GET on
>>
>> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>>
>> requesting text/plain or some KR format such as
>>
>> text/turtle
>> application/rdf+xml
>> text/owl-manchester
>>
>> Hope this helps,
>>
>> Alessandro
>>
>
>
>
--
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
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro.
Am 13.07.2012 15:33, schrieb Alessandro Adamou:
> Hi Melanie,
>
> On 7/13/12 2:51 PM, Melanie Reiplinger wrote:
>> Thank you for your instructions. I was able to create a recipe
>> "http://www.dfki.de/mere01/recipe/r1" via PUT.
>> Now, when trying to upload/create a new rule, I again get the Method
>> not allowed error.
>>
>> curl -i -X POST -F "recipe=http://www.dfki.de/mere01/recipe/r1" -F
>> "description=first_rule" -F
>> "rule=http://www.dfki.de/mere01/rules/R.has_transitive" -F
>> "kres-syntax=has(, ?x, ?z) . has(, ?z, ?y) -> has(, ?x, ?y)"
>> http://<stanbol>/rules/recipe/
>> HTTP/1.1 100 Continue
>>
>> HTTP/1.1 405 Method Not Allowed
>> Allow: GET,OPTIONS,HEAD
>> Content-Type: text/html; charset=iso-8859-1
>> Cache-Control: must-revalidate,no-cache,no-store
>> Content-Length: 1396
>> Server: Jetty(6.1.x)
>>
>> (the same if I send it just to <stanbol>/rules, as it sais in the
>> docu). I guess my request is not correct?
>
> After a quick look at the resource code, it looks like the
> documentation is outdated again.
>
> The recipe ID is now a Path parameter. There's no "kres-syntax"
> parameter anymore, and "rule" is now "rules" and it accommodates the
> rule name and the syntax as well.
>
> Here is what worked for me:
>
> curl -X POST -F "rules=transitivity[has(?r, ?x, ?z) . has(?r, ?z, ?y)
> -> has(?r, ?x, ?y)]" -F "description=Test rule"
> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
great, works fine. Now, if I want to get the rule itself, to what URL do
I send the GET? I tested
<stanbol>/rules/rule/transitivity
<stanbol>/rules/transitivity
<stanbol>/rule/transitivity
<stanbol>/rules/find/rules
>
> To check if it has been stored (and therefore parsed), you can do a
> GET on
>
> http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
>
> requesting text/plain or some KR format such as
>
> text/turtle
> application/rdf+xml
> text/owl-manchester
>
> Hope this helps,
>
> Alessandro
>
Re: rules endpoint
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Melanie,
On 7/13/12 2:51 PM, Melanie Reiplinger wrote:
> Thank you for your instructions. I was able to create a recipe
> "http://www.dfki.de/mere01/recipe/r1" via PUT.
> Now, when trying to upload/create a new rule, I again get the Method
> not allowed error.
>
> curl -i -X POST -F "recipe=http://www.dfki.de/mere01/recipe/r1" -F
> "description=first_rule" -F
> "rule=http://www.dfki.de/mere01/rules/R.has_transitive" -F
> "kres-syntax=has(, ?x, ?z) . has(, ?z, ?y) -> has(, ?x, ?y)"
> http://<stanbol>/rules/recipe/
> HTTP/1.1 100 Continue
>
> HTTP/1.1 405 Method Not Allowed
> Allow: GET,OPTIONS,HEAD
> Content-Type: text/html; charset=iso-8859-1
> Cache-Control: must-revalidate,no-cache,no-store
> Content-Length: 1396
> Server: Jetty(6.1.x)
>
> (the same if I send it just to <stanbol>/rules, as it sais in the
> docu). I guess my request is not correct?
After a quick look at the resource code, it looks like the documentation
is outdated again.
The recipe ID is now a Path parameter. There's no "kres-syntax"
parameter anymore, and "rule" is now "rules" and it accommodates the
rule name and the syntax as well.
Here is what worked for me:
curl -X POST -F "rules=transitivity[has(?r, ?x, ?z) . has(?r, ?z, ?y) ->
has(?r, ?x, ?y)]" -F "description=Test rule"
http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
To check if it has been stored (and therefore parsed), you can do a GET on
http://[stanbol]/rules/recipe/http://www.dfki.de/mere01/recipe/r1
requesting text/plain or some KR format such as
text/turtle
application/rdf+xml
text/owl-manchester
Hope this helps,
Alessandro
--
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
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro.
Thank you for your instructions. I was able to create a recipe
"http://www.dfki.de/mere01/recipe/r1" via PUT.
Now, when trying to upload/create a new rule, I again get the Method not
allowed error.
curl -i -X POST -F "recipe=http://www.dfki.de/mere01/recipe/r1" -F
"description=first_rule" -F
"rule=http://www.dfki.de/mere01/rules/R.has_transitive" -F
"kres-syntax=has(, ?x, ?z) . has(, ?z, ?y) -> has(, ?x, ?y)"
http://<stanbol>/rules/recipe/
HTTP/1.1 100 Continue
HTTP/1.1 405 Method Not Allowed
Allow: GET,OPTIONS,HEAD
Content-Type: text/html; charset=iso-8859-1
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 1396
Server: Jetty(6.1.x)
(the same if I send it just to <stanbol>/rules, as it sais in the docu).
I guess my request is not correct?
>>
>> So, when stating
>>
>> curl -i -X POST -d recipe="r1" -d description="A test recipe."
>> http://<stanbol>/rules/recipe
>>
>> I get as response:
>>
>> HTTP/1.1 405 Method Not Allowed
>> Allow: GET,OPTIONS,HEAD
>> Content-Type: text/html; charset=iso-8859-1
>> Cache-Control: must-revalidate,no-cache,no-store
>> Content-Length: 1395
>> Server: Jetty(6.1.x)
>>
>> Am I doing it the wrong way, or do I need the methods POST (and
>> DELETE) to be allowed from server-side ?
>
> you have to PUT /rules/recipe/r1 and then POST the rules onto that
> resource.
>
> but as I said, there might be problems if you try to refactor an
> ontology afterwards. If so, maybe for the time being you're better off
> using
>
> /rules/recipe/http://www.dfki.de/melanie/recipe/r1
>
> or something like that.
>
> And don't forget that resource expects multipart formdata in the POST
>
> HTH
>
> Alessandro
>
>
Re: rules endpoint
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Melanie,
I'm groping my way a bit on this endpoint because I'm not as savvy on
the rule manager as on the ontology manager, but I've seen the code
quite a few times.
> 1) (just a minor issue)
> The RESTful docu is a bit confusing here, since it states as endpoints
> <stanbol>/rule
> <stanbol>/recipe
> <stanbol>/refactor
> <stanbol>/refactor/apply
>
> In the apache docu it's
> <stanbol>/rules/store
> <stanbol>/rules/recipe
> <stanbol>/rules/refactor
> <stanbol>/rules/refactor/apply
Looks like they're both outdated, but the Apache site seems more
up-to-date. I can see these endpoints:
/rules/recipe # for storing and organizing rules
/rules/recipe/[ID] # see below
/rules/find/recipes # search by description using SPARQL string matching
/rules/find/rules
/rules/adapters/ # for exporting in other formats such as SWRL and
SPARQL Construct
/rules/adapters/recipe
/refactor # uses a stored recipe. we should move this to /rules/refactor
/refactor/apply # uses a recipe supplied in the request payload
/refactor/applyfile # this is redundant, it's like calling
/refactor/apply on @filename
Theoretically the recipe identifier [ID] can be almost any string.
However, last time I tried refactoring it only worked if ID was an IRI,
such as
[stanbol-host]/rules/recipe/http://dfki.de/rules/recipe/1
Please bear with this, I'm sure it will be fixed if it hasn't been already.
> 2)
> Also, in the RESTful docu all examples name "http://localhost:8080" as
> <stanbol>. I guess this means that I have to set my stanbol home
> somewhere in the configuration ? ( I haven't found the right place as
> yet ).
You don't have to, not this time. It's just that the REST API
documentation uses hardcoded URLs rather that dynamically with
freemarker. Feel free to use your hostname instead.
> 3)
> To find something to start with, I tried to create a recipe, which is
> "a container *[...]***, which identifies a set of rules that share the
> same business logic and interpret them as a whole." [1]
> So, when stating
>
> curl -i -X POST -d recipe="r1" -d description="A test recipe."
> http://<stanbol>/rules/recipe
>
> I get as response:
>
> HTTP/1.1 405 Method Not Allowed
> Allow: GET,OPTIONS,HEAD
> Content-Type: text/html; charset=iso-8859-1
> Cache-Control: must-revalidate,no-cache,no-store
> Content-Length: 1395
> Server: Jetty(6.1.x)
>
> Am I doing it the wrong way, or do I need the methods POST (and
> DELETE) to be allowed from server-side ?
you have to PUT /rules/recipe/r1 and then POST the rules onto that resource.
but as I said, there might be problems if you try to refactor an
ontology afterwards. If so, maybe for the time being you're better off using
/rules/recipe/http://www.dfki.de/melanie/recipe/r1
or something like that.
And don't forget that resource expects multipart formdata in the POST
HTH
Alessandro
--
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
rules endpoint
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi all.
Here I go again: this time it's the /rules endpoint, and I'm having a
few questions on that (as usual).
1) (just a minor issue)
The RESTful docu is a bit confusing here, since it states as endpoints
<stanbol>/rule
<stanbol>/recipe
<stanbol>/refactor
<stanbol>/refactor/apply
In the apache docu it's
<stanbol>/rules/store
<stanbol>/rules/recipe
<stanbol>/rules/refactor
<stanbol>/rules/refactor/apply
2)
Also, in the RESTful docu all examples name "http://localhost:8080" as
<stanbol>. I guess this means that I have to set my stanbol home
somewhere in the configuration ? ( I haven't found the right place as
yet ).
3)
To find something to start with, I tried to create a recipe, which is "a
container *[...]***, which identifies a set of rules that share the same
business logic and interpret them as a whole." [1]
So, when stating
curl -i -X POST -d recipe="r1" -d description="A test recipe."
http://<stanbol>/rules/recipe
I get as response:
HTTP/1.1 405 Method Not Allowed
Allow: GET,OPTIONS,HEAD
Content-Type: text/html; charset=iso-8859-1
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 1395
Server: Jetty(6.1.x)
Am I doing it the wrong way, or do I need the methods POST (and DELETE)
to be allowed from server-side ?
Thank you,
melanie
[1] http://incubator.apache.org/stanbol/docs/trunk/rules.html
Re: CRUD and updateEntity
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
On 7/15/12 11:24 AM, Melanie Reiplinger wrote:
> When doing preflight request for PUT or DELETE, the response header I
> get looks like this:
>
> Allow:
> OPTIONS,POST,GET,DELETE,HEAD,PUT
>
>
> So maybe here we also need the CORS access with
>
> Access-Control-Allow-Origin:
> *
> Access-Control-Allow-Mehtods: OPTIONS, POST, GET, DELETE, PUT
I've checked the Rules resource code and there's only one CORS preflight
method for the root resource but not for the subpaths. Also, as I wrote
earlier, I don't know if it is supposed to specify the allowed methods
but it doesn't. So that might be it I guess.
> There's also another strange thing I just realized when doublechecking
> with the curl version: I can delete a non-existig recipe over and over
> again, i.e., I always get
>
> HTTP/1.1 200 OK
> Content-Length: 0
> Server: Jetty(6.1.x)
>
> although the recipe is not there any more.
There's an error in the Jersey code for that resource. The method on a
deleted recipe is supposed to return 412 Precondition Failed (maybe 404
would be better?), but the problem is, whatever the outcome, there's a
line that always replaces the response builder and is always reached:
responseBuilder = Response.ok();
I've opened https://issues.apache.org/jira/browse/STANBOL-690 , hope it
will be solved.
Thanks for reporting
Alessandro
> Am 13.07.2012 14:37, schrieb Alessandro Adamou:
>> Hi Melanie,
>>
>> On 7/13/12 2:01 PM, Melanie Reiplinger wrote:
>>> The CORS access works for ontonet/ontology and ontonet/session.
>>
>> *whew*
>>
>>> One thing I noticed is that when creating a scope, the parameter
>>> customont seems to be ignored. Coreont is set accordingly, but no
>>> ontology is loaded when specified as value for customont.
>>
>> I am retiring the "customont" and "customreg" query parameters. It
>> didn't make much sense to have custom space population occur during
>> the PUT, since the custom space is less privileged and it is now
>> possible to populate it afterwards using POST methods.
>>
>> When it's completed, the docs will also reflect the change.
>>
>> So I am considering to rename the parameters:
>>
>> "coreont" --> "ontology" or "ont"
>> "corereg" --> "library" or "lib" (because in the first implementation
>> entire registries were loaded, library selection was not supported.
>> now it is)
>>
>> which do you like better?
>>
>> In my recent commit it is also now possible to submit multiple
>> "coreont" and "corereg" parameter values and they should all be added
>> to the scope. However note that if any ontology corresponding to the
>> values of these params fails to load, the scope will not be created.
>>
>>> One more question on the ontonet endpoint: How can I load an
>>> ontology library? I.e., which URL do I have to specify when I want
>>> to load a library from the ontonet/registry ?
>>
>> The logical URI that identifies the library.
>>
>> Right now the way to know it is not very RESTful yet. you are going
>> to need a browser, but I'm working on having it return RDF at least.
>>
>> if you go to [stanbol]/ontonet/registry
>>
>> and expand the library list, you see a list of links. The URI you are
>> looking for is the link target.
>>
>> Right now the default libraries do not resolve because they use the
>> stanbol.apache.org namespace. But Stanbol has the library info stored
>> in its data bundle org.apache.stanbol.data.registries.default
>>
>> So for example you can do
>>
>> (for putting all the ontologies in the core space, you do it when
>> creating the scope)
>>
>> % curl -i -X PUT
>> [stanbol]/ontonet/ontology/twitter-mining?corereg=http://stanbol.apache.org/ontologies/registries/stanbol_network/SocialNetworks
>>
>> (otherwise for the custom space, you can do it afterwards)
>>
>> % curl -i -X POST -F
>> "library=http://stanbol.apache.org/ontologies/registries/stanbol_network/SocialNetworks"
>> [stanbol]/ontonet/ontology/twitter-mining
>>
>> I am figuring out the best way to add import statements for library
>> ontologies but that's more of a subtlety.
>>
>> If we decide to replace "corereg" with another parameter, that
>> obviously will have to be changed accordingly.
>>
>> Sorry for all these changes and WIP stuff, but you're perhaps the
>> first to extensively use the ontonet REST API, and my first chance to
>> really tune it up to user needs.
>>
>> So, I would be very interested in knowing which use case you are
>> working on and what you would like to achieve with the Satnbol
>> ontology manager.
>>
>> Best,
>> Alessandro
>>
>>> Am 10.07.2012 23:16, schrieb Melanie Reiplinger:
>>>> Hi Rupert, Alessandro.
>>>>
>>>> I followed Sebastian's advice and made a complete new and fresh
>>>> checkout of the stanbol trunk.
>>>> I briefly checked on my ontonet tests tonight and at first sight it
>>>> looks like the delete and put requests are now working for me.
>>>> For my update test on the entityhub/entity, I now get
>>>>
>>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
>>>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>
>>>> HTTP/1.1 100 Continue
>>>>
>>>> HTTP/1.1 400 Bad Request
>>>> Accept: application/json
>>>> Content-Type: text/plain
>>>> Transfer-Encoding: chunked
>>>> Server: Jetty(6.1.x)
>>>>
>>>> (So that's exactly what we were talking about).
>>>>
>>>> Let me test and check on everything tomorrow, then I can give you
>>>> detailed feedback. I'm sorry for troubling you lately by reporting
>>>> that these things didn't work for me. For a possible reason, I can
>>>> only guess that my stanbol version got messed up during the last 3
>>>> updates/rebuilds, and that it was a bit buggy in the end.
>>>>
>>>> best
>>>> melanie
>>>>
>>>>
>>>> Am 09.07.2012 17:17, schrieb Rupert Westenthaler:
>>>>> On Mon, Jul 9, 2012 at 4:54 PM, Melanie Reiplinger
>>>>> <me...@dfki.de> wrote:
>>>>>>>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>>>>>
>>>>>>> update the Entity "howto-proxy-falseaddress.html"?
>>>>>>> update the Entity "howto-proxy.html"?
>>>>>>> something else?
>>>>>>
>>>>>> hm, I expected something like: since the
>>>>>> "howto-proxy-falseaddress.html"
>>>>>> does not exist, I should get some error because I'm referencig my
>>>>>> to-be-updated entity by a wrong ID. The content of the rdf file
>>>>>> should be of
>>>>>> secondary relevance here (because if my ID is not addressing any
>>>>>> existing
>>>>>> entity, the update should fail anyway). In fact, I expected that
>>>>>> nothing
>>>>>> would be updated in this case. (wouldn't it be strange to update
>>>>>> entity
>>>>>> "howto-proxy.html" when I pass some non-existing ID ?)
>>>>>>
>>>>> As the check if the parsed id is present in the parsed data comes
>>>>> first you should get a "Bad Request" with a an according message.
>>>>>
>>>>> If the file would contain a triple with the subject
>>>>> "http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"
>>>>> you would get a "Bad Request" with the message telling you that you
>>>>> can not update an entity that does not exist on the Entityhub.
>>>>>
>>>>> I will try to use your exact scenario and check if I can reproduce.
>>>>> If not I will try to temporarily setup an test server for you to
>>>>> validate on the dev.iks-project.eu server for testing.
>>>>>
>>>>> best
>>>>> Rupert
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
--
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: CRUD and updateEntity
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro.
Could you please take one more look at the code of the rules endpoint?
When doing preflight request for PUT or DELETE, the response header I
get looks like this:
Allow:
OPTIONS,POST,GET,DELETE,HEAD,PUT
So maybe here we also need the CORS access with
Access-Control-Allow-Origin:
*
Access-Control-Allow-Mehtods: OPTIONS, POST, GET, DELETE, PUT
etc.
There's also another strange thing I just realized when doublechecking
with the curl version: I can delete a non-existig recipe over and over
again, i.e., I always get
HTTP/1.1 200 OK
Content-Length: 0
Server: Jetty(6.1.x)
although the recipe is not there any more.
When trying to create (PUT) the same recipe twice in a row, I get a
conflict (409), so that's fine.
thanks
melanie
Am 13.07.2012 14:37, schrieb Alessandro Adamou:
> Hi Melanie,
>
> On 7/13/12 2:01 PM, Melanie Reiplinger wrote:
>> The CORS access works for ontonet/ontology and ontonet/session.
>
> *whew*
>
>> One thing I noticed is that when creating a scope, the parameter
>> customont seems to be ignored. Coreont is set accordingly, but no
>> ontology is loaded when specified as value for customont.
>
> I am retiring the "customont" and "customreg" query parameters. It
> didn't make much sense to have custom space population occur during
> the PUT, since the custom space is less privileged and it is now
> possible to populate it afterwards using POST methods.
>
> When it's completed, the docs will also reflect the change.
>
> So I am considering to rename the parameters:
>
> "coreont" --> "ontology" or "ont"
> "corereg" --> "library" or "lib" (because in the first implementation
> entire registries were loaded, library selection was not supported.
> now it is)
>
> which do you like better?
>
> In my recent commit it is also now possible to submit multiple
> "coreont" and "corereg" parameter values and they should all be added
> to the scope. However note that if any ontology corresponding to the
> values of these params fails to load, the scope will not be created.
>
>> One more question on the ontonet endpoint: How can I load an ontology
>> library? I.e., which URL do I have to specify when I want to load a
>> library from the ontonet/registry ?
>
> The logical URI that identifies the library.
>
> Right now the way to know it is not very RESTful yet. you are going to
> need a browser, but I'm working on having it return RDF at least.
>
> if you go to [stanbol]/ontonet/registry
>
> and expand the library list, you see a list of links. The URI you are
> looking for is the link target.
>
> Right now the default libraries do not resolve because they use the
> stanbol.apache.org namespace. But Stanbol has the library info stored
> in its data bundle org.apache.stanbol.data.registries.default
>
> So for example you can do
>
> (for putting all the ontologies in the core space, you do it when
> creating the scope)
>
> % curl -i -X PUT
> [stanbol]/ontonet/ontology/twitter-mining?corereg=http://stanbol.apache.org/ontologies/registries/stanbol_network/SocialNetworks
>
> (otherwise for the custom space, you can do it afterwards)
>
> % curl -i -X POST -F
> "library=http://stanbol.apache.org/ontologies/registries/stanbol_network/SocialNetworks"
> [stanbol]/ontonet/ontology/twitter-mining
>
> I am figuring out the best way to add import statements for library
> ontologies but that's more of a subtlety.
>
> If we decide to replace "corereg" with another parameter, that
> obviously will have to be changed accordingly.
>
> Sorry for all these changes and WIP stuff, but you're perhaps the
> first to extensively use the ontonet REST API, and my first chance to
> really tune it up to user needs.
>
> So, I would be very interested in knowing which use case you are
> working on and what you would like to achieve with the Satnbol
> ontology manager.
>
> Best,
> Alessandro
>
>> Am 10.07.2012 23:16, schrieb Melanie Reiplinger:
>>> Hi Rupert, Alessandro.
>>>
>>> I followed Sebastian's advice and made a complete new and fresh
>>> checkout of the stanbol trunk.
>>> I briefly checked on my ontonet tests tonight and at first sight it
>>> looks like the delete and put requests are now working for me.
>>> For my update test on the entityhub/entity, I now get
>>>
>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
>>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>
>>> HTTP/1.1 100 Continue
>>>
>>> HTTP/1.1 400 Bad Request
>>> Accept: application/json
>>> Content-Type: text/plain
>>> Transfer-Encoding: chunked
>>> Server: Jetty(6.1.x)
>>>
>>> (So that's exactly what we were talking about).
>>>
>>> Let me test and check on everything tomorrow, then I can give you
>>> detailed feedback. I'm sorry for troubling you lately by reporting
>>> that these things didn't work for me. For a possible reason, I can
>>> only guess that my stanbol version got messed up during the last 3
>>> updates/rebuilds, and that it was a bit buggy in the end.
>>>
>>> best
>>> melanie
>>>
>>>
>>> Am 09.07.2012 17:17, schrieb Rupert Westenthaler:
>>>> On Mon, Jul 9, 2012 at 4:54 PM, Melanie Reiplinger
>>>> <me...@dfki.de> wrote:
>>>>>>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>>>>
>>>>>> update the Entity "howto-proxy-falseaddress.html"?
>>>>>> update the Entity "howto-proxy.html"?
>>>>>> something else?
>>>>>
>>>>> hm, I expected something like: since the
>>>>> "howto-proxy-falseaddress.html"
>>>>> does not exist, I should get some error because I'm referencig my
>>>>> to-be-updated entity by a wrong ID. The content of the rdf file
>>>>> should be of
>>>>> secondary relevance here (because if my ID is not addressing any
>>>>> existing
>>>>> entity, the update should fail anyway). In fact, I expected that
>>>>> nothing
>>>>> would be updated in this case. (wouldn't it be strange to update
>>>>> entity
>>>>> "howto-proxy.html" when I pass some non-existing ID ?)
>>>>>
>>>> As the check if the parsed id is present in the parsed data comes
>>>> first you should get a "Bad Request" with a an according message.
>>>>
>>>> If the file would contain a triple with the subject
>>>> "http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"
>>>> you would get a "Bad Request" with the message telling you that you
>>>> can not update an entity that does not exist on the Entityhub.
>>>>
>>>> I will try to use your exact scenario and check if I can reproduce.
>>>> If not I will try to temporarily setup an test server for you to
>>>> validate on the dev.iks-project.eu server for testing.
>>>>
>>>> best
>>>> Rupert
>>>>
>>>
>>>
>>
>>
>>
>
>
Re: CRUD and updateEntity
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Melanie,
On 7/13/12 2:01 PM, Melanie Reiplinger wrote:
> The CORS access works for ontonet/ontology and ontonet/session.
*whew*
> One thing I noticed is that when creating a scope, the parameter
> customont seems to be ignored. Coreont is set accordingly, but no
> ontology is loaded when specified as value for customont.
I am retiring the "customont" and "customreg" query parameters. It
didn't make much sense to have custom space population occur during the
PUT, since the custom space is less privileged and it is now possible to
populate it afterwards using POST methods.
When it's completed, the docs will also reflect the change.
So I am considering to rename the parameters:
"coreont" --> "ontology" or "ont"
"corereg" --> "library" or "lib" (because in the first implementation
entire registries were loaded, library selection was not supported. now
it is)
which do you like better?
In my recent commit it is also now possible to submit multiple "coreont"
and "corereg" parameter values and they should all be added to the
scope. However note that if any ontology corresponding to the values of
these params fails to load, the scope will not be created.
> One more question on the ontonet endpoint: How can I load an ontology
> library? I.e., which URL do I have to specify when I want to load a
> library from the ontonet/registry ?
The logical URI that identifies the library.
Right now the way to know it is not very RESTful yet. you are going to
need a browser, but I'm working on having it return RDF at least.
if you go to [stanbol]/ontonet/registry
and expand the library list, you see a list of links. The URI you are
looking for is the link target.
Right now the default libraries do not resolve because they use the
stanbol.apache.org namespace. But Stanbol has the library info stored in
its data bundle org.apache.stanbol.data.registries.default
So for example you can do
(for putting all the ontologies in the core space, you do it when
creating the scope)
% curl -i -X PUT
[stanbol]/ontonet/ontology/twitter-mining?corereg=http://stanbol.apache.org/ontologies/registries/stanbol_network/SocialNetworks
(otherwise for the custom space, you can do it afterwards)
% curl -i -X POST -F
"library=http://stanbol.apache.org/ontologies/registries/stanbol_network/SocialNetworks"
[stanbol]/ontonet/ontology/twitter-mining
I am figuring out the best way to add import statements for library
ontologies but that's more of a subtlety.
If we decide to replace "corereg" with another parameter, that obviously
will have to be changed accordingly.
Sorry for all these changes and WIP stuff, but you're perhaps the first
to extensively use the ontonet REST API, and my first chance to really
tune it up to user needs.
So, I would be very interested in knowing which use case you are working
on and what you would like to achieve with the Satnbol ontology manager.
Best,
Alessandro
> Am 10.07.2012 23:16, schrieb Melanie Reiplinger:
>> Hi Rupert, Alessandro.
>>
>> I followed Sebastian's advice and made a complete new and fresh
>> checkout of the stanbol trunk.
>> I briefly checked on my ontonet tests tonight and at first sight it
>> looks like the delete and put requests are now working for me.
>> For my update test on the entityhub/entity, I now get
>>
>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>
>> HTTP/1.1 100 Continue
>>
>> HTTP/1.1 400 Bad Request
>> Accept: application/json
>> Content-Type: text/plain
>> Transfer-Encoding: chunked
>> Server: Jetty(6.1.x)
>>
>> (So that's exactly what we were talking about).
>>
>> Let me test and check on everything tomorrow, then I can give you
>> detailed feedback. I'm sorry for troubling you lately by reporting
>> that these things didn't work for me. For a possible reason, I can
>> only guess that my stanbol version got messed up during the last 3
>> updates/rebuilds, and that it was a bit buggy in the end.
>>
>> best
>> melanie
>>
>>
>> Am 09.07.2012 17:17, schrieb Rupert Westenthaler:
>>> On Mon, Jul 9, 2012 at 4:54 PM, Melanie Reiplinger
>>> <me...@dfki.de> wrote:
>>>>>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>>>
>>>>> update the Entity "howto-proxy-falseaddress.html"?
>>>>> update the Entity "howto-proxy.html"?
>>>>> something else?
>>>>
>>>> hm, I expected something like: since the
>>>> "howto-proxy-falseaddress.html"
>>>> does not exist, I should get some error because I'm referencig my
>>>> to-be-updated entity by a wrong ID. The content of the rdf file
>>>> should be of
>>>> secondary relevance here (because if my ID is not addressing any
>>>> existing
>>>> entity, the update should fail anyway). In fact, I expected that
>>>> nothing
>>>> would be updated in this case. (wouldn't it be strange to update
>>>> entity
>>>> "howto-proxy.html" when I pass some non-existing ID ?)
>>>>
>>> As the check if the parsed id is present in the parsed data comes
>>> first you should get a "Bad Request" with a an according message.
>>>
>>> If the file would contain a triple with the subject
>>> "http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"
>>> you would get a "Bad Request" with the message telling you that you
>>> can not update an entity that does not exist on the Entityhub.
>>>
>>> I will try to use your exact scenario and check if I can reproduce.
>>> If not I will try to temporarily setup an test server for you to
>>> validate on the dev.iks-project.eu server for testing.
>>>
>>> best
>>> Rupert
>>>
>>
>>
>
>
>
--
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: CRUD and updateEntity
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Rupert and Alessandro.
The CORS access works for ontonet/ontology and ontonet/session.
One thing I noticed is that when creating a scope, the parameter
customont seems to be ignored. Coreont is set accordingly, but no
ontology is loaded when specified as value for customont.
One more question on the ontonet endpoint: How can I load an ontology
library? I.e., which URL do I have to specify when I want to load a
library from the ontonet/registry ?
Best
melanie
Am 10.07.2012 23:16, schrieb Melanie Reiplinger:
> Hi Rupert, Alessandro.
>
> I followed Sebastian's advice and made a complete new and fresh
> checkout of the stanbol trunk.
> I briefly checked on my ontonet tests tonight and at first sight it
> looks like the delete and put requests are now working for me.
> For my update test on the entityhub/entity, I now get
>
> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>
> HTTP/1.1 100 Continue
>
> HTTP/1.1 400 Bad Request
> Accept: application/json
> Content-Type: text/plain
> Transfer-Encoding: chunked
> Server: Jetty(6.1.x)
>
> (So that's exactly what we were talking about).
>
> Let me test and check on everything tomorrow, then I can give you
> detailed feedback. I'm sorry for troubling you lately by reporting
> that these things didn't work for me. For a possible reason, I can
> only guess that my stanbol version got messed up during the last 3
> updates/rebuilds, and that it was a bit buggy in the end.
>
> best
> melanie
>
>
> Am 09.07.2012 17:17, schrieb Rupert Westenthaler:
>> On Mon, Jul 9, 2012 at 4:54 PM, Melanie Reiplinger
>> <me...@dfki.de> wrote:
>>>>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>>
>>>> update the Entity "howto-proxy-falseaddress.html"?
>>>> update the Entity "howto-proxy.html"?
>>>> something else?
>>>
>>> hm, I expected something like: since the
>>> "howto-proxy-falseaddress.html"
>>> does not exist, I should get some error because I'm referencig my
>>> to-be-updated entity by a wrong ID. The content of the rdf file
>>> should be of
>>> secondary relevance here (because if my ID is not addressing any
>>> existing
>>> entity, the update should fail anyway). In fact, I expected that
>>> nothing
>>> would be updated in this case. (wouldn't it be strange to update entity
>>> "howto-proxy.html" when I pass some non-existing ID ?)
>>>
>> As the check if the parsed id is present in the parsed data comes
>> first you should get a "Bad Request" with a an according message.
>>
>> If the file would contain a triple with the subject
>> "http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"
>> you would get a "Bad Request" with the message telling you that you
>> can not update an entity that does not exist on the Entityhub.
>>
>> I will try to use your exact scenario and check if I can reproduce.
>> If not I will try to temporarily setup an test server for you to
>> validate on the dev.iks-project.eu server for testing.
>>
>> best
>> Rupert
>>
>
>
CRUD and updateEntity
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Rupert, Alessandro.
I followed Sebastian's advice and made a complete new and fresh checkout
of the stanbol trunk.
I briefly checked on my ontonet tests tonight and at first sight it
looks like the delete and put requests are now working for me.
For my update test on the entityhub/entity, I now get
curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
"http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
HTTP/1.1 100 Continue
HTTP/1.1 400 Bad Request
Accept: application/json
Content-Type: text/plain
Transfer-Encoding: chunked
Server: Jetty(6.1.x)
(So that's exactly what we were talking about).
Let me test and check on everything tomorrow, then I can give you
detailed feedback. I'm sorry for troubling you lately by reporting that
these things didn't work for me. For a possible reason, I can only guess
that my stanbol version got messed up during the last 3
updates/rebuilds, and that it was a bit buggy in the end.
best
melanie
Am 09.07.2012 17:17, schrieb Rupert Westenthaler:
> On Mon, Jul 9, 2012 at 4:54 PM, Melanie Reiplinger
> <me...@dfki.de> wrote:
>>>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>> update the Entity "howto-proxy-falseaddress.html"?
>>> update the Entity "howto-proxy.html"?
>>> something else?
>>
>> hm, I expected something like: since the "howto-proxy-falseaddress.html"
>> does not exist, I should get some error because I'm referencig my
>> to-be-updated entity by a wrong ID. The content of the rdf file should be of
>> secondary relevance here (because if my ID is not addressing any existing
>> entity, the update should fail anyway). In fact, I expected that nothing
>> would be updated in this case. (wouldn't it be strange to update entity
>> "howto-proxy.html" when I pass some non-existing ID ?)
>>
> As the check if the parsed id is present in the parsed data comes
> first you should get a "Bad Request" with a an according message.
>
> If the file would contain a triple with the subject
> "http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"
> you would get a "Bad Request" with the message telling you that you
> can not update an entity that does not exist on the Entityhub.
>
> I will try to use your exact scenario and check if I can reproduce.
> If not I will try to temporarily setup an test server for you to
> validate on the dev.iks-project.eu server for testing.
>
> best
> Rupert
>
Re: POST status code
Posted by Rupert Westenthaler <ru...@gmail.com>.
On Mon, Jul 9, 2012 at 4:54 PM, Melanie Reiplinger
<me...@dfki.de> wrote:
>>>
>>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>
>> update the Entity "howto-proxy-falseaddress.html"?
>> update the Entity "howto-proxy.html"?
>> something else?
>
>
> hm, I expected something like: since the "howto-proxy-falseaddress.html"
> does not exist, I should get some error because I'm referencig my
> to-be-updated entity by a wrong ID. The content of the rdf file should be of
> secondary relevance here (because if my ID is not addressing any existing
> entity, the update should fail anyway). In fact, I expected that nothing
> would be updated in this case. (wouldn't it be strange to update entity
> "howto-proxy.html" when I pass some non-existing ID ?)
>
As the check if the parsed id is present in the parsed data comes
first you should get a "Bad Request" with a an according message.
If the file would contain a triple with the subject
"http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"
you would get a "Bad Request" with the message telling you that you
can not update an entity that does not exist on the Entityhub.
I will try to use your exact scenario and check if I can reproduce.
If not I will try to temporarily setup an test server for you to
validate on the dev.iks-project.eu server for testing.
best
Rupert
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: POST status code
Posted by Melanie Reiplinger <me...@dfki.de>.
Am 09.07.2012 16:34, schrieb Rupert Westenthaler:
> Hi Melanie,
>
> now I am a little bit confused. I do no longer fully understand what
> you are trying to do.
>
> Are those assumptions true?
>
> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html
> ... does not exist on the Entityhub
correct
> http://developer.yahoo.com/javascript/howto-proxy.html
> ... does exist on the Entityhub
correct
> About the uploaded RDF data
>
> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html
> ... is the subject of at least one triple in the uploaded RDF data? YES/NO ?
NO
(its about http://developer.yahoo.com/javascript/howto-proxy.html, or
about http://baa.org/foo.html)
> http://developer.yahoo.com/javascript/howto-proxy.html
> ... is the subject of at least one triple in the uploaded RDF data? YES/NO ?
YES.
> What do you expect happening when calling
>
>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
> update the Entity "howto-proxy-falseaddress.html"?
> update the Entity "howto-proxy.html"?
> something else?
hm, I expected something like: since the "howto-proxy-falseaddress.html"
does not exist, I should get some error because I'm referencig my
to-be-updated entity by a wrong ID. The content of the rdf file should
be of secondary relevance here (because if my ID is not addressing any
existing entity, the update should fail anyway). In fact, I expected
that nothing would be updated in this case. (wouldn't it be strange to
update entity "howto-proxy.html" when I pass some non-existing ID ?)
> Can you also attach the file with the RDF data to the answer of this questions
They are just some toy files for testing, one of them containing e.g.:
<?xml version="1.0" encoding="UTF-8"?><rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"><rdf:Description
rdf:about="http://developer.yahoo.com/javascript/howto-proxy.html"><rdfs:label>Modified
Label of Howto-Proxy</rdfs:label></rdf:Description></rdf:RDF>
>
> Thanks in advance
> best
> Rupert
>
> On Mon, Jul 9, 2012 at 4:15 PM, Melanie Reiplinger
> <me...@dfki.de> wrote:
>> Am 07.07.2012 08:03, schrieb Rupert Westenthaler:
>>
>>> Hi
>>>
>>> On Fri, Jul 6, 2012 at 9:51 AM, Melanie Reiplinger
>>> <me...@dfki.de> wrote:
>>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
>>>>
>>>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>
>>>> HTTP/1.1 100 Continue
>>>>
>>>> HTTP/1.1 304 Not Modified
>>>> Server: Jetty(6.1.x)
>>>>
>>> One question: does the RDF data "someEntity" contain triples for the
>>> URL"http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"?
>>> If not, than you should get the exact same response as I do.
>>
>> No, it contains triples about
>> "http://developer.yahoo.com/javascript/howto-proxy.html" (of which the
>> falseaddress.html is a non-existing variant). The entity itself (described
>> in the file) exists on my entityhub; I'm principally trying to update it
>> under a wrong id here.
>> However, if I put into the rdf file some other, non-existing entity (about
>> some completely different URL), and state:
>>
>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T anotherEntity.rdf
>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>
>> HTTP/1.1 100 Continue
>>
>> HTTP/1.1 304 Not Modified
>> Server: Jetty(6.1.x)
>>
>>> So I am unable to reproduce this. If you can give me access to the
>>> Stanbol Server you test against I could try to further look into this.
>>
>> sorry, I am not allowed to do so. Is there a version online on a demo server
>> with your updates already integrated? Then I could simply try on that
>> 'public' version and see whether it works there.
>>
>>>> (where I try to update a non-existing entity).
>>>>
>>>> Best
>>>>
>>>> melanie
>>>>
>>>> Am 03.07.2012 17:48, schrieb Rupert Westenthaler:
>>>>> On Tue, Jul 3, 2012 at 5:18 PM, Rupert Westenthaler
>>>>>
>>>>> <ru...@gmail.com> wrote:
>>>>>> Hi Melanie,
>>>>>>
>>>>>> I think this is because the parsed RDF data do not contain any
>>>>>> information (rdf triples) about the parsed id
>>>>>>
>>>>>>
>>>>>> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm
>>>>>>
>>>>>> I will add a check that ensures that a BAD_REQUEST is thrown in those
>>>>>> cases.
>>>>>>
>>>>> fixed withhttp://svn.apache.org/viewvc?rev=1356788&view=rev
>>>>>
>>>>>
>>>>>> best
>>>>>> Rupert
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger
>>>>>> <me...@dfki.de> wrote:
>>>>>>> Hi Alessandro and all.
>>>>>>>
>>>>>>> Today we found a strange behaviour in one of my tests that uses update
>>>>>>> functionality of the entityhub/entity. When trying to update a
>>>>>>> non-existing
>>>>>>> entity ( = erroneous or non-existing id), an error code 304 (Not
>>>>>>> Modified)
>>>>>>> is returned.
>>>>>>> This makes my test notify me of a success, although intuitively, one
>>>>>>> would
>>>>>>> think of this as a fail (since I tried to update something that does
>>>>>>> not
>>>>>>> exist).
>>>>>>>
>>>>>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
>>>>>>>
>>>>>>>
>>>>>>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>>>> HTTP/1.1 100 Continue
>>>>>>>
>>>>>>> HTTP/1.1 304 Not Modified
>>>>>>> Server: Jetty(6.1.x)
>>>>>>>
>>>>>>> Best,
>>>>>>> melanie
>>>>>>>
>>>>>>>
>>>>>>> Am 28.06.2012 08:13, schrieb Fabian Christ:
>>>>>>>
>>>>>>>> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>>>>>>>>> So far I've made these methods return 303 See Other with the created
>>>>>>>>> resource, basically because I wanted browsers to automatically
>>>>>>>>> redirect
>>>>>>>>> to
>>>>>>>>> that URL when the ontology is added using the HTML form. But I've
>>>>>>>>> been
>>>>>>>>> thinking that perhaps returning a 201 CREATED would be more
>>>>>>>>> appropriate
>>>>>>>>> on
>>>>>>>>> the REST side.
>>>>>>>> I think 201 is the right way to go. The response of a POST just tells
>>>>>>>> you that the resource was created and optionally where it was created
>>>>>>>> using the Location header.
>>>>>>>>
>>>>>>>> You can also use 303 and hope that the client interprets it
>>>>>>>> correctly.
>>>>>>>> But this response may not be the right one for all clients. Another
>>>>>>>> client than a browser may not need the redirect and will perhaps be
>>>>>>>> confused.
>>>>>>>>
>>>>>>>> Therefore, the 201 is IMO the best solution and instead implement the
>>>>>>>> redirect separately.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> - Fabian
>>>>>> --
>>>>>> | Rupert Westenthalerrupert.westenthaler@gmail.com
>>>>>> | Bodenlehenstraße 11 ++43-699-11108907
>>>>>> | A-5500 Bischofshofen
>>>>>
>>
>
>
Re: POST status code
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Rupert,
for something general:
Is there a version online on a demo server with yours and Alessandro's
recent updates already integrated?
Because then I could try on that 'public' version and see whether e.g.
the CORS for the ontonet endpoint works.
(since the changes you made didn't have an effect on the results I get
for my tests, I just want to make sure this is not simply some silly bug
on my side)
Best
melanie
Am 09.07.2012 16:34, schrieb Rupert Westenthaler:
> Hi Melanie,
>
> now I am a little bit confused. I do no longer fully understand what
> you are trying to do.
>
> Are those assumptions true?
>
> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html
> ... does not exist on the Entityhub
>
> http://developer.yahoo.com/javascript/howto-proxy.html
> ... does exist on the Entityhub
>
> About the uploaded RDF data
>
> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html
> ... is the subject of at least one triple in the uploaded RDF data? YES/NO ?
>
> http://developer.yahoo.com/javascript/howto-proxy.html
> ... is the subject of at least one triple in the uploaded RDF data? YES/NO ?
>
>
> What do you expect happening when calling
>
>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
> update the Entity "howto-proxy-falseaddress.html"?
> update the Entity "howto-proxy.html"?
> something else?
>
> Can you also attach the file with the RDF data to the answer of this questions
>
> Thanks in advance
> best
> Rupert
>
> On Mon, Jul 9, 2012 at 4:15 PM, Melanie Reiplinger
> <me...@dfki.de> wrote:
>> Am 07.07.2012 08:03, schrieb Rupert Westenthaler:
>>
>>> Hi
>>>
>>> On Fri, Jul 6, 2012 at 9:51 AM, Melanie Reiplinger
>>> <me...@dfki.de> wrote:
>>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
>>>>
>>>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>
>>>> HTTP/1.1 100 Continue
>>>>
>>>> HTTP/1.1 304 Not Modified
>>>> Server: Jetty(6.1.x)
>>>>
>>> One question: does the RDF data "someEntity" contain triples for the
>>> URL"http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"?
>>> If not, than you should get the exact same response as I do.
>>
>> No, it contains triples about
>> "http://developer.yahoo.com/javascript/howto-proxy.html" (of which the
>> falseaddress.html is a non-existing variant). The entity itself (described
>> in the file) exists on my entityhub; I'm principally trying to update it
>> under a wrong id here.
>> However, if I put into the rdf file some other, non-existing entity (about
>> some completely different URL), and state:
>>
>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T anotherEntity.rdf
>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>
>> HTTP/1.1 100 Continue
>>
>> HTTP/1.1 304 Not Modified
>> Server: Jetty(6.1.x)
>>
>>> So I am unable to reproduce this. If you can give me access to the
>>> Stanbol Server you test against I could try to further look into this.
>>
>> sorry, I am not allowed to do so. Is there a version online on a demo server
>> with your updates already integrated? Then I could simply try on that
>> 'public' version and see whether it works there.
>>
>>>> (where I try to update a non-existing entity).
>>>>
>>>> Best
>>>>
>>>> melanie
>>>>
>>>> Am 03.07.2012 17:48, schrieb Rupert Westenthaler:
>>>>> On Tue, Jul 3, 2012 at 5:18 PM, Rupert Westenthaler
>>>>>
>>>>> <ru...@gmail.com> wrote:
>>>>>> Hi Melanie,
>>>>>>
>>>>>> I think this is because the parsed RDF data do not contain any
>>>>>> information (rdf triples) about the parsed id
>>>>>>
>>>>>>
>>>>>> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm
>>>>>>
>>>>>> I will add a check that ensures that a BAD_REQUEST is thrown in those
>>>>>> cases.
>>>>>>
>>>>> fixed withhttp://svn.apache.org/viewvc?rev=1356788&view=rev
>>>>>
>>>>>
>>>>>> best
>>>>>> Rupert
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger
>>>>>> <me...@dfki.de> wrote:
>>>>>>> Hi Alessandro and all.
>>>>>>>
>>>>>>> Today we found a strange behaviour in one of my tests that uses update
>>>>>>> functionality of the entityhub/entity. When trying to update a
>>>>>>> non-existing
>>>>>>> entity ( = erroneous or non-existing id), an error code 304 (Not
>>>>>>> Modified)
>>>>>>> is returned.
>>>>>>> This makes my test notify me of a success, although intuitively, one
>>>>>>> would
>>>>>>> think of this as a fail (since I tried to update something that does
>>>>>>> not
>>>>>>> exist).
>>>>>>>
>>>>>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
>>>>>>>
>>>>>>>
>>>>>>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>>>> HTTP/1.1 100 Continue
>>>>>>>
>>>>>>> HTTP/1.1 304 Not Modified
>>>>>>> Server: Jetty(6.1.x)
>>>>>>>
>>>>>>> Best,
>>>>>>> melanie
>>>>>>>
>>>>>>>
>>>>>>> Am 28.06.2012 08:13, schrieb Fabian Christ:
>>>>>>>
>>>>>>>> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>>>>>>>>> So far I've made these methods return 303 See Other with the created
>>>>>>>>> resource, basically because I wanted browsers to automatically
>>>>>>>>> redirect
>>>>>>>>> to
>>>>>>>>> that URL when the ontology is added using the HTML form. But I've
>>>>>>>>> been
>>>>>>>>> thinking that perhaps returning a 201 CREATED would be more
>>>>>>>>> appropriate
>>>>>>>>> on
>>>>>>>>> the REST side.
>>>>>>>> I think 201 is the right way to go. The response of a POST just tells
>>>>>>>> you that the resource was created and optionally where it was created
>>>>>>>> using the Location header.
>>>>>>>>
>>>>>>>> You can also use 303 and hope that the client interprets it
>>>>>>>> correctly.
>>>>>>>> But this response may not be the right one for all clients. Another
>>>>>>>> client than a browser may not need the redirect and will perhaps be
>>>>>>>> confused.
>>>>>>>>
>>>>>>>> Therefore, the 201 is IMO the best solution and instead implement the
>>>>>>>> redirect separately.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> - Fabian
>>>>>> --
>>>>>> | Rupert Westenthalerrupert.westenthaler@gmail.com
>>>>>> | Bodenlehenstraße 11 ++43-699-11108907
>>>>>> | A-5500 Bischofshofen
>>>>>
>>
>
>
Re: POST status code
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Melanie,
now I am a little bit confused. I do no longer fully understand what
you are trying to do.
Are those assumptions true?
http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html
... does not exist on the Entityhub
http://developer.yahoo.com/javascript/howto-proxy.html
... does exist on the Entityhub
About the uploaded RDF data
http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html
... is the subject of at least one triple in the uploaded RDF data? YES/NO ?
http://developer.yahoo.com/javascript/howto-proxy.html
... is the subject of at least one triple in the uploaded RDF data? YES/NO ?
What do you expect happening when calling
> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
update the Entity "howto-proxy-falseaddress.html"?
update the Entity "howto-proxy.html"?
something else?
Can you also attach the file with the RDF data to the answer of this questions
Thanks in advance
best
Rupert
On Mon, Jul 9, 2012 at 4:15 PM, Melanie Reiplinger
<me...@dfki.de> wrote:
> Am 07.07.2012 08:03, schrieb Rupert Westenthaler:
>
>> Hi
>>
>> On Fri, Jul 6, 2012 at 9:51 AM, Melanie Reiplinger
>> <me...@dfki.de> wrote:
>>>
>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
>>>
>>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>
>>> HTTP/1.1 100 Continue
>>>
>>> HTTP/1.1 304 Not Modified
>>> Server: Jetty(6.1.x)
>>>
>> One question: does the RDF data "someEntity" contain triples for the
>> URL"http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"?
>> If not, than you should get the exact same response as I do.
>
>
> No, it contains triples about
> "http://developer.yahoo.com/javascript/howto-proxy.html" (of which the
> falseaddress.html is a non-existing variant). The entity itself (described
> in the file) exists on my entityhub; I'm principally trying to update it
> under a wrong id here.
> However, if I put into the rdf file some other, non-existing entity (about
> some completely different URL), and state:
>
> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T anotherEntity.rdf
> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>
> HTTP/1.1 100 Continue
>
> HTTP/1.1 304 Not Modified
> Server: Jetty(6.1.x)
>
>> So I am unable to reproduce this. If you can give me access to the
>> Stanbol Server you test against I could try to further look into this.
>
>
> sorry, I am not allowed to do so. Is there a version online on a demo server
> with your updates already integrated? Then I could simply try on that
> 'public' version and see whether it works there.
>
>>> (where I try to update a non-existing entity).
>>>
>>> Best
>>>
>>> melanie
>>>
>>> Am 03.07.2012 17:48, schrieb Rupert Westenthaler:
>>>>
>>>> On Tue, Jul 3, 2012 at 5:18 PM, Rupert Westenthaler
>>>>
>>>> <ru...@gmail.com> wrote:
>>>>>
>>>>> Hi Melanie,
>>>>>
>>>>> I think this is because the parsed RDF data do not contain any
>>>>> information (rdf triples) about the parsed id
>>>>>
>>>>>
>>>>> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm
>>>>>
>>>>> I will add a check that ensures that a BAD_REQUEST is thrown in those
>>>>> cases.
>>>>>
>>>> fixed withhttp://svn.apache.org/viewvc?rev=1356788&view=rev
>>>>
>>>>
>>>>> best
>>>>> Rupert
>>>>>
>>>>>
>>>>> On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger
>>>>> <me...@dfki.de> wrote:
>>>>>>
>>>>>> Hi Alessandro and all.
>>>>>>
>>>>>> Today we found a strange behaviour in one of my tests that uses update
>>>>>> functionality of the entityhub/entity. When trying to update a
>>>>>> non-existing
>>>>>> entity ( = erroneous or non-existing id), an error code 304 (Not
>>>>>> Modified)
>>>>>> is returned.
>>>>>> This makes my test notify me of a success, although intuitively, one
>>>>>> would
>>>>>> think of this as a fail (since I tried to update something that does
>>>>>> not
>>>>>> exist).
>>>>>>
>>>>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
>>>>>>
>>>>>>
>>>>>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>>> HTTP/1.1 100 Continue
>>>>>>
>>>>>> HTTP/1.1 304 Not Modified
>>>>>> Server: Jetty(6.1.x)
>>>>>>
>>>>>> Best,
>>>>>> melanie
>>>>>>
>>>>>>
>>>>>> Am 28.06.2012 08:13, schrieb Fabian Christ:
>>>>>>
>>>>>>> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>>>>>>>>
>>>>>>>> So far I've made these methods return 303 See Other with the created
>>>>>>>> resource, basically because I wanted browsers to automatically
>>>>>>>> redirect
>>>>>>>> to
>>>>>>>> that URL when the ontology is added using the HTML form. But I've
>>>>>>>> been
>>>>>>>> thinking that perhaps returning a 201 CREATED would be more
>>>>>>>> appropriate
>>>>>>>> on
>>>>>>>> the REST side.
>>>>>>>
>>>>>>> I think 201 is the right way to go. The response of a POST just tells
>>>>>>> you that the resource was created and optionally where it was created
>>>>>>> using the Location header.
>>>>>>>
>>>>>>> You can also use 303 and hope that the client interprets it
>>>>>>> correctly.
>>>>>>> But this response may not be the right one for all clients. Another
>>>>>>> client than a browser may not need the redirect and will perhaps be
>>>>>>> confused.
>>>>>>>
>>>>>>> Therefore, the 201 is IMO the best solution and instead implement the
>>>>>>> redirect separately.
>>>>>>>
>>>>>>> Best,
>>>>>>> - Fabian
>>>>>
>>>>> --
>>>>> | Rupert Westenthalerrupert.westenthaler@gmail.com
>>>>> | Bodenlehenstraße 11 ++43-699-11108907
>>>>> | A-5500 Bischofshofen
>>>>
>>>>
>>
>
>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: POST status code
Posted by Melanie Reiplinger <me...@dfki.de>.
Am 07.07.2012 08:03, schrieb Rupert Westenthaler:
> Hi
>
> On Fri, Jul 6, 2012 at 9:51 AM, Melanie Reiplinger
> <me...@dfki.de> wrote:
>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
>> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>
>> HTTP/1.1 100 Continue
>>
>> HTTP/1.1 304 Not Modified
>> Server: Jetty(6.1.x)
>>
> One question: does the RDF data "someEntity" contain triples for the
> URL"http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"?
> If not, than you should get the exact same response as I do.
No, it contains triples about
"http://developer.yahoo.com/javascript/howto-proxy.html" (of which the
falseaddress.html is a non-existing variant). The entity itself
(described in the file) exists on my entityhub; I'm principally trying
to update it under a wrong id here.
However, if I put into the rdf file some other, non-existing entity
(about some completely different URL), and state:
curl -i -X PUT -H "Content-Type:application/rdf+xml" -T
anotherEntity.rdf
"http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
HTTP/1.1 100 Continue
HTTP/1.1 304 Not Modified
Server: Jetty(6.1.x)
> So I am unable to reproduce this. If you can give me access to the
> Stanbol Server you test against I could try to further look into this.
sorry, I am not allowed to do so. Is there a version online on a demo
server with your updates already integrated? Then I could simply try on
that 'public' version and see whether it works there.
>> (where I try to update a non-existing entity).
>>
>> Best
>>
>> melanie
>>
>> Am 03.07.2012 17:48, schrieb Rupert Westenthaler:
>>> On Tue, Jul 3, 2012 at 5:18 PM, Rupert Westenthaler
>>>
>>> <ru...@gmail.com> wrote:
>>>> Hi Melanie,
>>>>
>>>> I think this is because the parsed RDF data do not contain any
>>>> information (rdf triples) about the parsed id
>>>>
>>>> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm
>>>>
>>>> I will add a check that ensures that a BAD_REQUEST is thrown in those
>>>> cases.
>>>>
>>> fixed withhttp://svn.apache.org/viewvc?rev=1356788&view=rev
>>>
>>>> best
>>>> Rupert
>>>>
>>>>
>>>> On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger
>>>> <me...@dfki.de> wrote:
>>>>> Hi Alessandro and all.
>>>>>
>>>>> Today we found a strange behaviour in one of my tests that uses update
>>>>> functionality of the entityhub/entity. When trying to update a
>>>>> non-existing
>>>>> entity ( = erroneous or non-existing id), an error code 304 (Not
>>>>> Modified)
>>>>> is returned.
>>>>> This makes my test notify me of a success, although intuitively, one
>>>>> would
>>>>> think of this as a fail (since I tried to update something that does not
>>>>> exist).
>>>>>
>>>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
>>>>>
>>>>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>>> HTTP/1.1 100 Continue
>>>>>
>>>>> HTTP/1.1 304 Not Modified
>>>>> Server: Jetty(6.1.x)
>>>>>
>>>>> Best,
>>>>> melanie
>>>>>
>>>>>
>>>>> Am 28.06.2012 08:13, schrieb Fabian Christ:
>>>>>
>>>>>> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>>>>>>> So far I've made these methods return 303 See Other with the created
>>>>>>> resource, basically because I wanted browsers to automatically
>>>>>>> redirect
>>>>>>> to
>>>>>>> that URL when the ontology is added using the HTML form. But I've been
>>>>>>> thinking that perhaps returning a 201 CREATED would be more
>>>>>>> appropriate
>>>>>>> on
>>>>>>> the REST side.
>>>>>> I think 201 is the right way to go. The response of a POST just tells
>>>>>> you that the resource was created and optionally where it was created
>>>>>> using the Location header.
>>>>>>
>>>>>> You can also use 303 and hope that the client interprets it correctly.
>>>>>> But this response may not be the right one for all clients. Another
>>>>>> client than a browser may not need the redirect and will perhaps be
>>>>>> confused.
>>>>>>
>>>>>> Therefore, the 201 is IMO the best solution and instead implement the
>>>>>> redirect separately.
>>>>>>
>>>>>> Best,
>>>>>> - Fabian
>>>> --
>>>> | Rupert Westenthalerrupert.westenthaler@gmail.com
>>>> | Bodenlehenstraße 11 ++43-699-11108907
>>>> | A-5500 Bischofshofen
>>>
>
Re: POST status code
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi
On Fri, Jul 6, 2012 at 9:51 AM, Melanie Reiplinger
<me...@dfki.de> wrote:
> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
> "http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>
> HTTP/1.1 100 Continue
>
> HTTP/1.1 304 Not Modified
> Server: Jetty(6.1.x)
>
One question: does the RDF data "someEntity" contain triples for the
URL "http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html"?
If not, than you should get the exact same response as I do.
curl -i -X PUT -H "Content-Type:application/rdf+xml" -T
Valentino_Rossi.rdf
"http://localhost:8080/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
HTTP/1.1 100 Continue
HTTP/1.1 400 Bad Request
Accept: application/json
Content-Type: text/plain
Transfer-Encoding: chunked
Server: Jetty(6.1.x)
Parsed RDF data do not contain any Information about the parsed id
'http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html'
When repeating the request with an Entity where data are present in
the sent RDF file I do get the following result
curl -i -X PUT -H "Content-Type:application/rdf+xml" -T
Valentino_Rossi.rdf
"http://localhost:8080/entityhub/entity?id=http://dbpedia.org/resource/Valentino_Rossi&create=false"HTTP/1.1
100 Continue
HTTP/1.1 400 Bad Request
Accept: application/json
Content-Type: text/plain
Transfer-Encoding: chunked
Server: Jetty(6.1.x)
Unable to create an Entity http://dbpedia.org/resource/Valentino_Rossi
becuase it does not and creating new is deactivated. You might want
to set the 'does not exists' parameter to TRUE in your Request
So I am unable to reproduce this. If you can give me access to the
Stanbol Server you test against I could try to further look into this.
best
Rupert
> (where I try to update a non-existing entity).
>
> Best
>
> melanie
>
> Am 03.07.2012 17:48, schrieb Rupert Westenthaler:
>>
>> On Tue, Jul 3, 2012 at 5:18 PM, Rupert Westenthaler
>>
>> <ru...@gmail.com> wrote:
>>>
>>> Hi Melanie,
>>>
>>> I think this is because the parsed RDF data do not contain any
>>> information (rdf triples) about the parsed id
>>>
>>> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm
>>>
>>> I will add a check that ensures that a BAD_REQUEST is thrown in those
>>> cases.
>>>
>> fixed with http://svn.apache.org/viewvc?rev=1356788&view=rev
>>
>>> best
>>> Rupert
>>>
>>>
>>> On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger
>>> <me...@dfki.de> wrote:
>>>>
>>>> Hi Alessandro and all.
>>>>
>>>> Today we found a strange behaviour in one of my tests that uses update
>>>> functionality of the entityhub/entity. When trying to update a
>>>> non-existing
>>>> entity ( = erroneous or non-existing id), an error code 304 (Not
>>>> Modified)
>>>> is returned.
>>>> This makes my test notify me of a success, although intuitively, one
>>>> would
>>>> think of this as a fail (since I tried to update something that does not
>>>> exist).
>>>>
>>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
>>>>
>>>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>>> HTTP/1.1 100 Continue
>>>>
>>>> HTTP/1.1 304 Not Modified
>>>> Server: Jetty(6.1.x)
>>>>
>>>> Best,
>>>> melanie
>>>>
>>>>
>>>> Am 28.06.2012 08:13, schrieb Fabian Christ:
>>>>
>>>>> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>>>>>>
>>>>>> So far I've made these methods return 303 See Other with the created
>>>>>> resource, basically because I wanted browsers to automatically
>>>>>> redirect
>>>>>> to
>>>>>> that URL when the ontology is added using the HTML form. But I've been
>>>>>> thinking that perhaps returning a 201 CREATED would be more
>>>>>> appropriate
>>>>>> on
>>>>>> the REST side.
>>>>>
>>>>> I think 201 is the right way to go. The response of a POST just tells
>>>>> you that the resource was created and optionally where it was created
>>>>> using the Location header.
>>>>>
>>>>> You can also use 303 and hope that the client interprets it correctly.
>>>>> But this response may not be the right one for all clients. Another
>>>>> client than a browser may not need the redirect and will perhaps be
>>>>> confused.
>>>>>
>>>>> Therefore, the 201 is IMO the best solution and instead implement the
>>>>> redirect separately.
>>>>>
>>>>> Best,
>>>>> - Fabian
>>>>
>>>>
>>>
>>>
>>> --
>>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>>> | Bodenlehenstraße 11 ++43-699-11108907
>>> | A-5500 Bischofshofen
>>
>>
>>
>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: POST status code
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Rupert.
I updated twice since your mail, now at revision 1356930, but I still
get exactly the same response for that request.
curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity
"http://<stanbol>/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
HTTP/1.1 100 Continue
HTTP/1.1 304 Not Modified
Server: Jetty(6.1.x)
(where I try to update a non-existing entity).
Best
melanie
Am 03.07.2012 17:48, schrieb Rupert Westenthaler:
> On Tue, Jul 3, 2012 at 5:18 PM, Rupert Westenthaler
> <ru...@gmail.com> wrote:
>> Hi Melanie,
>>
>> I think this is because the parsed RDF data do not contain any
>> information (rdf triples) about the parsed id
>>
>> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm
>>
>> I will add a check that ensures that a BAD_REQUEST is thrown in those cases.
>>
> fixed with http://svn.apache.org/viewvc?rev=1356788&view=rev
>
>> best
>> Rupert
>>
>>
>> On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger
>> <me...@dfki.de> wrote:
>>> Hi Alessandro and all.
>>>
>>> Today we found a strange behaviour in one of my tests that uses update
>>> functionality of the entityhub/entity. When trying to update a non-existing
>>> entity ( = erroneous or non-existing id), an error code 304 (Not Modified)
>>> is returned.
>>> This makes my test notify me of a success, although intuitively, one would
>>> think of this as a fail (since I tried to update something that does not
>>> exist).
>>>
>>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
>>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>>> HTTP/1.1 100 Continue
>>>
>>> HTTP/1.1 304 Not Modified
>>> Server: Jetty(6.1.x)
>>>
>>> Best,
>>> melanie
>>>
>>>
>>> Am 28.06.2012 08:13, schrieb Fabian Christ:
>>>
>>>> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>>>>> So far I've made these methods return 303 See Other with the created
>>>>> resource, basically because I wanted browsers to automatically redirect
>>>>> to
>>>>> that URL when the ontology is added using the HTML form. But I've been
>>>>> thinking that perhaps returning a 201 CREATED would be more appropriate
>>>>> on
>>>>> the REST side.
>>>> I think 201 is the right way to go. The response of a POST just tells
>>>> you that the resource was created and optionally where it was created
>>>> using the Location header.
>>>>
>>>> You can also use 303 and hope that the client interprets it correctly.
>>>> But this response may not be the right one for all clients. Another
>>>> client than a browser may not need the redirect and will perhaps be
>>>> confused.
>>>>
>>>> Therefore, the 201 is IMO the best solution and instead implement the
>>>> redirect separately.
>>>>
>>>> Best,
>>>> - Fabian
>>>
>>
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
>
>
Re: POST status code
Posted by Rupert Westenthaler <ru...@gmail.com>.
On Tue, Jul 3, 2012 at 5:18 PM, Rupert Westenthaler
<ru...@gmail.com> wrote:
> Hi Melanie,
>
> I think this is because the parsed RDF data do not contain any
> information (rdf triples) about the parsed id
>
> http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm
>
> I will add a check that ensures that a BAD_REQUEST is thrown in those cases.
>
fixed with http://svn.apache.org/viewvc?rev=1356788&view=rev
> best
> Rupert
>
>
> On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger
> <me...@dfki.de> wrote:
>> Hi Alessandro and all.
>>
>> Today we found a strange behaviour in one of my tests that uses update
>> functionality of the entityhub/entity. When trying to update a non-existing
>> entity ( = erroneous or non-existing id), an error code 304 (Not Modified)
>> is returned.
>> This makes my test notify me of a success, although intuitively, one would
>> think of this as a fail (since I tried to update something that does not
>> exist).
>>
>> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
>> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
>> HTTP/1.1 100 Continue
>>
>> HTTP/1.1 304 Not Modified
>> Server: Jetty(6.1.x)
>>
>> Best,
>> melanie
>>
>>
>> Am 28.06.2012 08:13, schrieb Fabian Christ:
>>
>>> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>>>>
>>>> So far I've made these methods return 303 See Other with the created
>>>> resource, basically because I wanted browsers to automatically redirect
>>>> to
>>>> that URL when the ontology is added using the HTML form. But I've been
>>>> thinking that perhaps returning a 201 CREATED would be more appropriate
>>>> on
>>>> the REST side.
>>>
>>> I think 201 is the right way to go. The response of a POST just tells
>>> you that the resource was created and optionally where it was created
>>> using the Location header.
>>>
>>> You can also use 303 and hope that the client interprets it correctly.
>>> But this response may not be the right one for all clients. Another
>>> client than a browser may not need the redirect and will perhaps be
>>> confused.
>>>
>>> Therefore, the 201 is IMO the best solution and instead implement the
>>> redirect separately.
>>>
>>> Best,
>>> - Fabian
>>
>>
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: POST status code
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Melanie,
I think this is because the parsed RDF data do not contain any
information (rdf triples) about the parsed id
http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm
I will add a check that ensures that a BAD_REQUEST is thrown in those cases.
best
Rupert
On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger
<me...@dfki.de> wrote:
> Hi Alessandro and all.
>
> Today we found a strange behaviour in one of my tests that uses update
> functionality of the entityhub/entity. When trying to update a non-existing
> entity ( = erroneous or non-existing id), an error code 304 (Not Modified)
> is returned.
> This makes my test notify me of a success, although intuitively, one would
> think of this as a fail (since I tried to update something that does not
> exist).
>
> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf
> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"
> HTTP/1.1 100 Continue
>
> HTTP/1.1 304 Not Modified
> Server: Jetty(6.1.x)
>
> Best,
> melanie
>
>
> Am 28.06.2012 08:13, schrieb Fabian Christ:
>
>> 2012/6/27 Alessandro Adamou<ad...@cs.unibo.it>:
>>>
>>> So far I've made these methods return 303 See Other with the created
>>> resource, basically because I wanted browsers to automatically redirect
>>> to
>>> that URL when the ontology is added using the HTML form. But I've been
>>> thinking that perhaps returning a 201 CREATED would be more appropriate
>>> on
>>> the REST side.
>>
>> I think 201 is the right way to go. The response of a POST just tells
>> you that the resource was created and optionally where it was created
>> using the Location header.
>>
>> You can also use 303 and hope that the client interprets it correctly.
>> But this response may not be the right one for all clients. Another
>> client than a browser may not need the redirect and will perhaps be
>> confused.
>>
>> Therefore, the 201 is IMO the best solution and instead implement the
>> redirect separately.
>>
>> Best,
>> - Fabian
>
>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen