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
<[email protected]> 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
