Hi Bill, you have everything correct. I haven't copied the sdmx or other ontologies because I assumed that the ontology would be retrieved directly from it's URI (pointing to the purl.org server).
I'm guessing that I should try downloading that ontology, re-up it to my own Fuseki, adjust the prefix URI in the query to match and see what happens? If it works then great. But unless I have fundamentally misunderstood linked/semantic data, doesn't having to host all of the definitions and ontologies defeat the purpose? On 12 February 2015 at 20:26, Bill Roberts <[email protected]> wrote: > Hi Richard > > > Sorry, haven't followed everything in this thread so apologies if I have > missed something you have already explained. > > > > > My understanding: you have downloaded a dump of one of the datasets from > ODC and loaded it into a local Fuseki. The query you mentioned yesterday > returns no results. > > > > > Your query looks for properties that are subproperties of the sdmx > refPeriod property from the data cube ontology. > > > > > In ODC, the definitions of the ontologies used are in separate graphs. > Have you taken a copy of the relevant ontology too? > > > > > Cheers > > > > > Bill > > > Bill Roberts, CEO, Swirrl IT Limited > Mobile: +44 (0) 7717 160378 | Skype: billroberts1966 | @billroberts > http://swirrl.com > > On Thu, Feb 12, 2015 at 7:54 PM, Richard Davenport > <[email protected]> wrote: > > > OK so for curiosity's sake I spun up a new Fuseki server on a personal > > machine completely outside of the private network and am facing the same > > issue. So it is definitely not a network issue and probably/hopefully has > > something to do with how I am importing the data dump to the server. If > > anyone could give a step-by-step with a little explanation, I'd really > > appreciate it? > > On 12 February 2015 at 15:26, Richard Davenport < > > [email protected]> wrote: > >> I uploaded that data using the Fuseki control panel, to a new named > graph > >> with the URI: > >> http:// > <ip>/<datasetname>/homelessness/homelessness-acceptances/ethnicity > >> So the triples from the .nt dump were now stored inside a new named > graph > >> on my Fuseki server? All of the queries are being performed > >> manually/directly using the Fuseki control panel. > >> > >> The result of the following query is a list of the graphs stored; > >> including the URI above - SELECT * { GRAPH ?g {} } > >> > >> As for the query that failed (Wrong results? Query processor crashed?), > >> there was no error or crash just zero results. > >> > >> Finally, the last query you gave me returns a list of graphs (like the > one > >> above) with the total number of triples for each, as expected? > >> > >> On 12 February 2015 at 14:15, Andy Seaborne <[email protected]> wrote: > >> > >>> On 12/02/15 11:24, Richard Davenport wrote: > >>> > >>>> I didn't change anything from the data downloaded here - > >>>> http://opendatacommunities.org/data/homelessness/ > >>>> homelessness-acceptances/ethnicity/dump > >>>> > >>> > >>> which has no named graphs that I can find. > >>> > >>> How did you load the data? If yu loa > >>> What is the result of > >>> > >>> SELECT * { GRAPH ?g {} } > >>> > >>> You do not need to change the query unless you made a named graph to > >>> match that name. The data above is not a named graph. > >>> > >>> Graph ?G does work correctly like so: > >>>> SELECT DISTINCT ?G ?o > >>>> WHERE > >>>> { > >>>> GRAPH ?G > >>>> { ?s ?p ?o} > >>>> } > >>>> > >>>> But the WHERE in the second query you gave me (here > >>>> http://markmail.org/message/427lyslfsworvnet) also included the > >>>> following, > >>>> which broke it: > >>>> ?property (rdfs:subPropertyOf)* dim:refPeriod . > >>>> ?rp rdfs:label ?label > >>>> > >>> > >>> Wrong results? Query processor crashed? > >>> > >>> I'm afraid the details so far might make sense to you but I don't know > >>> your system/workflow as well. > >>> > >>> Named graphs definitely exist on the server and I am able to return > some > >>>> data. As I said, the problem only seems to come when other > >>>> prefixes/ontologies are used inside the query? > >>>> > >>>> The query you gave me in your last post (suggest numbering them from > now > >>>> on > >>>> for simplicity?) has broken syntax. > >>>> > >>> > >>> I can't test all queries ... add an extra "}" to the UNION line. > >>> > >>> SELECT ?g (count(*) AS ?C) > >>> { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } } } > >>> GROUP BY ?g > >>> > >>> What are the results of that query? > >>> > >>> > >>> > >>>> On 11 February 2015 at 22:23, Andy Seaborne <[email protected]> wrote: > >>>> > >>>> On 11/02/15 22:00, Richard Davenport wrote: > >>>>> > >>>>> Regarding my previous queries/posts - http://###/ was replaced with > >>>>>> the > >>>>>> correct URL of my server in previous queries. The data exists on my > >>>>>> server > >>>>>> at an IRI different to the original (opendatacommuni.....), so I > >>>>>> changed > >>>>>> the GRAPH prefix to select that. Your reply seems to suggest I > should > >>>>>> be > >>>>>> doing something else? > >>>>>> > >>>>>> > >>>>> Did you change the data you loaded into the database at all? Is > there a > >>>>> link to the data you loaded? > >>>>> > >>>>> Your first query returns results (though just rp as each distinct > >>>>> subject, > >>>>> > >>>>>> rather than objects that are a subPropertyOf refPeriod). > >>>>>> > >>>>>> The second doesn't return any? > >>>>>> > >>>>>> > >>>>> If GRAPH ?G does not return anything, maybe there are no named graphs > >>>>> despite datacommunities having them. > >>>>> > >>>>> Try this (slow) query: > >>>>> > >>>>> SELECT ?g (count(*) AS ?C) > >>>>> { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } } > >>>>> GROUP BY ?g > >>>>> > >>>>> Andy > >>>>> > >>>>> > >>>>> > >>>>> Listing graphs in the usual way (removing the first two > lines/filters > >>>>>> inside WHERE from your second query) works just fine? > >>>>>> > >>>>>> On 11 February 2015 at 21:19, Andy Seaborne <[email protected]> > wrote: > >>>>>> > >>>>>> On 11/02/15 20:48, Richard Davenport wrote: > >>>>>> > >>>>>>> > >>>>>>> Sincere apologies - that is messed up and not how I drafted it! > >.< > >>>>>>> > >>>>>>>> > >>>>>>>> Anyway, my point was that queries return sane results - except for > >>>>>>>> when > >>>>>>>> involving rdfs: to define what a label is (or any other IRI > >>>>>>>> originating > >>>>>>>> from a different/remote server). Therefore could there be an issue > >>>>>>>> with > >>>>>>>> my > >>>>>>>> Fuseki server retrieving ontologies and such from sources outside > of > >>>>>>>> its > >>>>>>>> own network? How might I positively identify that? It seems > strange > >>>>>>>> that I > >>>>>>>> get no warnings or errors? > >>>>>>>> > >>>>>>>> > >>>>>>>> The log file will have errors. If you have a OntModel, it may > look > >>>>>>> up > >>>>>>> owl:imports. > >>>>>>> > >>>>>>> But if you have a restored copy of the opendatacommunities > database, > >>>>>>> into > >>>>>>> TDB, no special processing wrapper, then nothing is being looked up > >>>>>>> outside > >>>>>>> the server. and for a query, then ontologies are not looked up, the > >>>>>>> names > >>>>>>> are just used. > >>>>>>> > >>>>>>> If you change PREFIX tgt: <http://###/whatever> > >>>>>>> then > >>>>>>> > >>>>>>> GRAPH tgt: > >>>>>>> { ?subject ?property ?rp} > >>>>>>> > >>>>>>> is the same as > >>>>>>> > >>>>>>> GRAPH <http://###/whatever> > >>>>>>> { ?subject ?property ?rp} > >>>>>>> > >>>>>>> If the original data was in graph > >>>>>>> > >>>>>>> <http://opendatacommunities.org/graph/homelessness/ > >>>>>>> homelessness-acceptances/ethnicity> > >>>>>>> > >>>>>>> then it is still a graph of that name in the copied database. > >>>>>>> > >>>>>>> GRAPH <http://###/whatever> will fail. > >>>>>>> GRAPH <<http://opendatacommunities.org/...> will work. > >>>>>>> > >>>>>>> GRAPH is just setting the fourth field in all lookups for the quads > >>>>>>> table > >>>>>>> inside the {}. > >>>>>>> > >>>>>>> Does > >>>>>>> > >>>>>>> SELECT DISTINCT ?rp ?label > >>>>>>> WHERE > >>>>>>> { ?property (rdfs:subPropertyOf)* dim:refPeriod . > >>>>>>> ?rp rdfs:label ?label} > >>>>>>> > >>>>>>> work? > >>>>>>> > >>>>>>> Try also: > >>>>>>> > >>>>>>> SELECT DISTINCT ?G ?rp ?label > >>>>>>> WHERE > >>>>>>> { ?property (rdfs:subPropertyOf)* dim:refPeriod . > >>>>>>> ?rp rdfs:label ?label > >>>>>>> GRAPH ?G > >>>>>>> { ?subject ?property ?rp} > >>>>>>> } > >>>>>>> > >>>>>>> Andy > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 11 February 2015 at 17:27, Andy Seaborne <[email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> On 11/02/15 15:48, Richard Davenport wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> *PREFIX tgt: > >>>>>>>>> > >>>>>>>>> <http://###/odc/homelessness/homelessness-acceptances/ > >>>>>>>>> > >>>>>>>>>> ethnicity>SELECT > >>>>>>>>>> DISTINCT ?rp ?labelWHERE { ?rp rdfs:label ?label GRAPH tgt: > >>>>>>>>>> { > >>>>>>>>>> ?subject <http://opendatacommunities.org/def/ontology/time/ > >>>>>>>>>> refPeriod > >>>>>>>>>> <http://opendatacommunities.org/def/ontology/time/refPeriod>> > ?rp} > >>>>>>>>>> }ORDER > >>>>>>>>>> BY ?rpLIMIT 1Simplifying the query as suggested above still > >>>>>>>>>> yields > >>>>>>>>>> no > >>>>>>>>>> results (or errors!). Yet, the following query works fine. The > >>>>>>>>>> inconsistent > >>>>>>>>>> behaviour is very confusing!SELECT DISTINCT ?rpWHERE { GRAPH > tgt: > >>>>>>>>>> { > >>>>>>>>>> ?s <http://opendatacommunities.org/def/ontology/time/refPeriod > >>>>>>>>>> <http://opendatacommunities.org/def/ontology/time/refPeriod>> > ?rp} > >>>>>>>>>> }ORDER > >>>>>>>>>> BY ?rpLIMIT 1This and a few other test queries indicate that > the > >>>>>>>>>> server > >>>>>>>>>> is unable to get or otherwise process prefix's outside of it's > own > >>>>>>>>>> network > >>>>>>>>>> (despite having otherwise normal internet access!)? How can I > get > >>>>>>>>>> Fuseki > >>>>>>>>>> to > >>>>>>>>>> tell me whether this is the case? Are there any specific > connection > >>>>>>>>>> protocol/variables required by Fuseki? I'll speak to the network > >>>>>>>>>> people > >>>>>>>>>> this side but if anyone has an idea please shout.Thanks also > Bill > >>>>>>>>>> for > >>>>>>>>>> the > >>>>>>>>>> explanation of the cube dimension API. It's something that'll > >>>>>>>>>> certainly > >>>>>>>>>> be > >>>>>>>>>> useful.Cheers,Richard.* > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Unreadable! > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> What's ### ? > >>>>>>>>> > >>>>>>>>> Fuseki does not resolve prefixes. If you have a copy of the data > >>>>>>>>> unchanged, use the same prefixes as the original query. A > prefix is > >>>>>>>>> just > >>>>>>>>> added to the local part to make an IRI. > >>>>>>>>> > >>>>>>>>> Andy > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> >
