Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-742

can't POST RDF to a graph using REST API

    Details

      Description

      I updated from SVN (1_2_0 branch) after the announcement about property paths. Since then I have not been able to add data from RDF files using POST to NanoSparqlServer.

      To replicate:
      1) svn co https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0
      2) ant war
      3) Expand war file into a folder called bigdata within Apache Tomcat webapps folder (I tested Tomcat 6.0.35 and 7.0.37)
      4) Check that quads are enabled in bigdata config
      5) Start Tomcat
      6) Try to add triples to a graph from the attached file using POST by means of curl, with the attached RDF file in your current directory:

      curl -X POST -d '@phenoscape-ext.rdf' --header "Content-Type:application/rdf+xml" 'http://localhost:8080/bigdata/sparql?context-uri=http://purl.obolibrary.org/obo/uberon/phenoscape-ext.owl'

      This command returns immediately and adds no triples to the database. I expected it to add the triples to a graph called "http://purl.obolibrary.org/obo/uberon/phenoscape-ext.owl". If you remove the context-uri parameter, triples are added to the database:

      curl -X POST -d '@phenoscape-ext.rdf' --header "Content-Type:application/rdf+xml" 'http://localhost:8080/bigdata/sparql'

      Returns <?xml version="1.0"?><data modified="44516" milliseconds="3511"/>

        Activity

        Hide
        balhoff balhoff added a comment -

        I am using Java 6 (1.6.0_43-b01-447-11M4203) on Mac OS X 10.8.2. I have also encountered this problem on Java 6 on CentOS Linux.

        Show
        balhoff balhoff added a comment - I am using Java 6 (1.6.0_43-b01-447-11M4203) on Mac OS X 10.8.2. I have also encountered this problem on Java 6 on CentOS Linux.
        Hide
        bryanthompson bryanthompson added a comment -

        Ok. I can replicate the error. It is hitting a problem in the following code block. The method that it is calling expects URIs to be surrounded by '<' and '>' and is not appropriate for this use. Also, obviously, we lack unit tests for this.

                /*
                 * Allow the caller to specify the default contexts.
                 */
                final Resource[] defaultContext;
                {
                    final String[] s = req.getParameterValues("context-uri");
                    if (s != null && s.length > 0) {
                        try {
                        	defaultContext = EncodeDecodeValue.decodeResources(s);
                        } catch (IllegalArgumentException ex) {
                            buildResponse(resp, HTTP_INTERNALERROR, MIME_TEXT_PLAIN,
                                    ex.getLocalizedMessage());
                            return;
                        }
                    } else {
                        defaultContext = new Resource[0];
                    }
                }
        
        Show
        bryanthompson bryanthompson added a comment - Ok. I can replicate the error. It is hitting a problem in the following code block. The method that it is calling expects URIs to be surrounded by '<' and '>' and is not appropriate for this use. Also, obviously, we lack unit tests for this. /* * Allow the caller to specify the default contexts. */ final Resource[] defaultContext; { final String[] s = req.getParameterValues("context-uri"); if (s != null && s.length > 0) { try { defaultContext = EncodeDecodeValue.decodeResources(s); } catch (IllegalArgumentException ex) { buildResponse(resp, HTTP_INTERNALERROR, MIME_TEXT_PLAIN, ex.getLocalizedMessage()); return; } } else { defaultContext = new Resource[0]; } }
        Hide
        bryanthompson bryanthompson added a comment -

        Also, the manner in which the exception was being trapped was preventing a useful exception from being logged. The exception handling should have been through launderThrowable().

        Here is a workaround: The change is to InsertServlet line 203.

        final Resource[] defaultContext;
                {
                    final String[] s = req.getParameterValues("context-uri");
                    if (s != null && s.length > 0) {
                        defaultContext = new Resource[s.length];
                        for(int i=0; i<s.length; i++) {
                            defaultContext[i] = new URIImpl(s[i]);
                        }
        //                try {
        //                	defaultContext = EncodeDecodeValue.decodeResources(s);
        //                } catch (IllegalArgumentException ex) {
        //                    buildResponse(resp, HTTP_INTERNALERROR, MIME_TEXT_PLAIN,
        //                            ex.getLocalizedMessage());
        //                    return;
        //                }
                    } else {
                        defaultContext = new Resource[0];
                    }
                }
        

        I am going to check all the other places where EncodeDecodeValue.decodeResources() was being called and add test suite coverage.

        Show
        bryanthompson bryanthompson added a comment - Also, the manner in which the exception was being trapped was preventing a useful exception from being logged. The exception handling should have been through launderThrowable(). Here is a workaround: The change is to InsertServlet line 203. final Resource[] defaultContext; { final String[] s = req.getParameterValues("context-uri"); if (s != null && s.length > 0) { defaultContext = new Resource[s.length]; for(int i=0; i<s.length; i++) { defaultContext[i] = new URIImpl(s[i]); } // try { // defaultContext = EncodeDecodeValue.decodeResources(s); // } catch (IllegalArgumentException ex) { // buildResponse(resp, HTTP_INTERNALERROR, MIME_TEXT_PLAIN, // ex.getLocalizedMessage()); // return; // } } else { defaultContext = new Resource[0]; } } I am going to check all the other places where EncodeDecodeValue.decodeResources() was being called and add test suite coverage.
        Hide
        bryanthompson bryanthompson added a comment -

        Ok. We do have tests for this. The tests are using EncodeDecodeValue consistently on the client and the server.

        EncodeDecodeValue was written to support REST API methods that need to allow any kind of RDF Value (i.e., either URIs and/or Literals). For example, the REST API method ESTCARD must support Literals as constraints on the access pattern as well as URIs.

        However, the context-uri parameter is just a URI and does not need to be wrapped up with angle brackets when presented as a REST API parameter. What "broke" is that the implementation was changed to always wrap URIs with angle brackets for these methods.

        I am going to reassign this ticket to Mike. Right now, the workaround would be to introduce the angle brackets around a URI. We need to talk this through before making further changes. As a related issue that needs to be addressed, I do not see a means for people to specify the defaultGraphUri, namedGraphUri, etc. query parameters in the bigdata RemoteRepository implementation (client side of the REST API). Those URL query parameters are defined by the SPARQL specification. They MUST NOT have the angle brackets.

        My initial position is that the ESTCARD URL query parameters MUST have the RDF Value serialization as supported by the EncodeDecodeValue class because both Literals and URIs may appear in those query parameters and we need to be able to interpret them correctly.

        I think that we should revert to the original URL query parameters (without the angle brackets) for the context-uri and similar query parameters in the REST API. If we do not, then we MUST NOT cause those angle brackets to appear for the URL query parameters that are specified by SPARQL.

        This is a blocking issue for a release.

        Show
        bryanthompson bryanthompson added a comment - Ok. We do have tests for this. The tests are using EncodeDecodeValue consistently on the client and the server. EncodeDecodeValue was written to support REST API methods that need to allow any kind of RDF Value (i.e., either URIs and/or Literals). For example, the REST API method ESTCARD must support Literals as constraints on the access pattern as well as URIs. However, the context-uri parameter is just a URI and does not need to be wrapped up with angle brackets when presented as a REST API parameter. What "broke" is that the implementation was changed to always wrap URIs with angle brackets for these methods. I am going to reassign this ticket to Mike. Right now, the workaround would be to introduce the angle brackets around a URI. We need to talk this through before making further changes. As a related issue that needs to be addressed, I do not see a means for people to specify the defaultGraphUri, namedGraphUri, etc. query parameters in the bigdata RemoteRepository implementation (client side of the REST API). Those URL query parameters are defined by the SPARQL specification. They MUST NOT have the angle brackets. My initial position is that the ESTCARD URL query parameters MUST have the RDF Value serialization as supported by the EncodeDecodeValue class because both Literals and URIs may appear in those query parameters and we need to be able to interpret them correctly. I think that we should revert to the original URL query parameters (without the angle brackets) for the context-uri and similar query parameters in the REST API. If we do not, then we MUST NOT cause those angle brackets to appear for the URL query parameters that are specified by SPARQL. This is a blocking issue for a release.
        Hide
        bryanthompson bryanthompson added a comment -

        This ticket was resolved in
        Revision: r7106
        http://bigdata.svn.sourceforge.net/bigdata/?rev=7106&view=rev

        Author:   mrpersonick
        Date:     2013-05-03 19:33:28 +0000 (Fri, 03 May 2013)
        Log Message:
        -----------
        fixed ticket 650 - removed EncodeDecodeValue references
        
        Modified Paths:
        --------------
            branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/BigdataRDFServlet.java
            branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/DeleteServlet.java
            branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/InsertServlet.java
            branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/UpdateServlet.java
            branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/client/RemoteRepository.java
        
        Show
        bryanthompson bryanthompson added a comment - This ticket was resolved in Revision: r7106 http://bigdata.svn.sourceforge.net/bigdata/?rev=7106&view=rev Author: mrpersonick Date: 2013-05-03 19:33:28 +0000 (Fri, 03 May 2013) Log Message: ----------- fixed ticket 650 - removed EncodeDecodeValue references Modified Paths: -------------- branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/BigdataRDFServlet.java branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/DeleteServlet.java branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/InsertServlet.java branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/UpdateServlet.java branches/BIGDATA_RELEASE_1_2_0/bigdata-sails/src/java/com/bigdata/rdf/sail/webapp/client/RemoteRepository.java

          People

          • Assignee:
            mikepersonick mikepersonick
            Reporter:
            balhoff balhoff
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: