sparqlsesameopenrdfsparqlwrapper

All SPARQL queries to my Sesame data store fail (returning nothing). What do I have configured incorrectly?


I've installed openrdf-sesame and openrdf-workbench (2.8.6) under tomcat7 on ubuntu Linux. I loaded the following data:

@prefix mur: <http://madeup.com/recipe#>.
@prefix branda: <http://madeup.com/branda#>.
@prefix brandb: <http://madeup.com/brandb#>.
@prefix brandc: <http://madeup.com/brandc#>.

mur:sausage a mur:sausage;
    mur:label "sausage".

branda:sausage a mur:sausage;
    branda:label "Brand A extra spicy sausage";
    branda:href "http://www.google.com/";
    branda:image "http://lorempixel.com/600/300/food/4/Brand%20A%20extra%20spicy%20sausage";
    mur:upc "01234".

brandb:sausage a mur:sausage;
    brandb:label "Brand B mild sausage";
    brandb:href "http://www.bing.com/";
    brandb:image "http://lorempixel.com/600/300/food/3/Brand%20B%20mild%20sausage";
    mur:upc "56789".

brandc:stockpot a mur:stockpot.

mur:spaghetti_recipe a mur:Recipe;
    mur:label "World famous sausage and spaghetti";
    mur:has_ingredient mur:sausage,
        [ a mur:sausage;
          mur:quantity "2";
          mur:units "lbs";
          mur:note "2 lbs sausage casings removed";
          branda:note "2 lbs Brand A extra spicy sausage (caseless)";
          brandb:note "2 lbs (1 package) of Brand B mild sausage with the casings removed"
        ];
    mur:has_ingredient mur:onion,
        [ a mur:onion;
          mur:quantity "1";
          mur:size "small";
          mur:label "1 small onion, chopped (optional)"
        ];
    mur:has_ingredient mur:garlic,
        [ a mur:garlic;
          mur:quantity "3";
          mur:label "3 garlic cloves, minced"
        ];
    mur:has_ingredient mur:tomato,
        [ a mur:tomato;
          mur:quantity "28";
          mur:units "ounces";
          mur:label "28 ounces of diced tomatoes"
        ];
    mur:has_ingredient mur:tomato_paste,
        [ a mur:tomato_paste;
          mur:quantity "12";
          mur:units "ounces";
          mur:label "12 ounces of tomato paste"
        ];
    mur:has_ingredient mur:water,
        [ a mur:water;
          mur:quantity "2";
          mur:units "cups";
          mur:label "If you want to simmer it as less, add less)"
        ];
   mur:has_ingredient mur:basil,
        [ a mur:basil;
          mur:quantity "3";
          mur:units "teaspoons";
          mur:label "3 teaspoons basil"
        ];
    mur:has_ingredient mur:spaghetti,
        [ a mur:spaghetti;
          mur:subtype "thin";
          mur:quantity "1";
          mur:units "lb";
          mur:label "1 lb thin spaghetti"
        ];
    mur:has_direction
        [ mur:step 1;
          mur:uses mur:sausage;
          mur:uses mur:stockpot;
          mur:label "In large, heavy stockpot, brown sausage, breaking up as you stir";
          branda:label "In large, heavy stockpot, brown Brand A extra spicy sausage, breaking up as you stir";
          brandb:label "In large, heavy stockpot, brown Brand B mild sausage breaking up as you stir"
        ].

I cannot seem to execute any sparql query against it. I've tried:

select distinct ?property
where { 
    ?s ?property ?o .
}

I get no results from that query. When I try from workbench I get a page in my browser that says: This XML file does not appear to have any style information associated with it. The document tree is shown below. Then there's nothing below it. When I try the same query using SPARQLWrapper in python I also get an empty XML document back as my results. In workbench if I click on contexts I can see my context, if I click on Namespaces I can see my nsamspaces, however if I click on Types the server throws a 500 error. With "java.lang.NoClassDefFoundError: java/util/Objects" being at the top of the stack trace.

Any ideas?


Solution

  • It turns out that some Java 7 features accidentally got into the Sesame 2.8 codebase. Despite the fact that the documentation says that Sesame 2.8 is compatible with Java 6, release 2.8.6 in reality requires a Java 7 runtime.

    This is a bug (see SES-2325), and will be fixed in the next Sesame patch release. In the meantime, a workaround is to upgrade to Java 7 or 8 (which is really a very good idea anyway).