On 7/6/12 12:05 PM, Melanie Reiplinger wrote:
[...]
But when I do
curl -i -X DELETE http://<stanbol>/ontonet/session/<mySession>/<someScope>
HTTP/1.1 500 Internal Server Error
Content-Length: 0
Server: Jetty(6.1.x)
the scope (which i appended to the session before) is not removed.
Is that a desired restriction, so that I cannot undock a scope from a
session unless I delete the session completely?
No, more simply scope detachment is not implemented in the RESTful API
yet, only in the Java API.
It's just a matter of choosing what the method should look like.
Resources such as
http://<stanbol>/ontonet/session/<mySession>/<someScope> are not created
at all afaik. It throws that error because it cannot find an ontology
named <someScope> (I'll make it return 404 instead)
What would you like the session-scope relation to look like in the
RESTful API? Would you like it to be something like
DELETE http://<stanbol>/ontonet/session/<mySession>/<someScope> (thereby
creating the resources too)
or
DELETE http://<stanbol>/ontonet/session/<mySession>?scopeid=<someScope>
Also, when clicking in the Browser view on the link of the loaded
scope, I'm redirected to
http://<stanbol>/ontonet/ontology/<someScope>
<http://lnv-89012.dfki.uni-sb.de:9001/ontonet/ontology/pizzaScope>.
That's normal, scopes are managed as they are. But like I said, if you
want I can make it create resources like
http://<stanbol>/ontonet/session/<mySession>/<someScope>
Alessandro
Am 06.07.2012 11:37, schrieb Melanie Reiplinger:
Sorry, I meant I was on revision 1356930 for the complete stanbol. I
alway updated and rebuilt the whole thing. But Most probably it's
much faster if I just rebuild the respective endpoint.
Am 06.07.2012 10:50, schrieb Alessandro Adamou:
On 7/6/12 10:36 AM, Melanie Reiplinger wrote:
Thanks for your efforts in helping me :-)
well I'm the guy behind that code, so I'm listening for reports and
wishes over there.
I can create session now and add scopes to them, but the version
where the session ID should be created automatically does not work
for me (see below).
To create a session:
- If you want to decide which ID to give it, just do a PUT
[stanbol-host]/ontonet/session/[ID]
- If you want Stanbol to decide the ID, do a POST
[stanbol-host]/ontonet/session
The first works fine, but for the second option, I get:
curl -i -X POST http://<stanbol>/ontonet/session
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: 1398
Server: Jetty(6.1.x)
(I'm presently at revision 1356930)
could you please update and rebuild ontologymanager? I'm on 1357301
here
Furthermore, at this endpoint as well as for the ontonet/ontology,
PUT and DELETE are not allowed for CORS yet, so the Http requests
will fail.
When doing a preflight request for PUT to
http://<stanbol>/ontonet/session/pizzaSession
I get in the response
Access-Control-Allow-Methods:
GET, POST, OPTIONS
I'm afraid I'm going to need help from other Stanbolers, as like I
said I don't really dig CORS very much :(
In the revision I mentioned, I had this preflight method in the
Session resource:
@OPTIONS
public Response handleCorsPreflight(@Context HttpHeaders headers) {
ResponseBuilder rb = Response.ok();
enableCORS(servletContext, rb, headers, GET, POST, PUT,
DELETE, OPTIONS);
return rb.build();
}
I thought that manually adding supported methods in the OPTIONS
request was enough.
Maybe I should do that in the addCORSOrigin() call for the PUT and
DELETE methods as well?
Regards,
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
