The { at the end of the GRAPH line is of course in fact a }. Typo existed
in message only (queries correct, results same).On 13 February 2015 at 16:22, Richard Davenport < [email protected]> wrote: > Thanks guys I'd guessed that I probably made some naïve assumptions. Also > kind of assumed that after retrieving remote data the first time, it'd be > automatically cached! That'll teach me. > > So after downloading and installing the various triple sets (sdmx, rdfs), > the query still doesn't work. Likewise, simplifying it to: > > SELECT DISTINCT ?rp ?label > WHERE > { ?rp rdfs:label ?label > GRAPH tgt: > { ?s <http://opendatacommunities.org/def/ontology/time/refPeriod> > ?rp { > } > > Also returned zero results. Simplifying it further to: > > SELECT DISTINCT ?rp > WHERE > { > GRAPH tgt: > { ?s <http://opendatacommunities.org/def/ontology/time/refPeriod> > ?rp { > } > > Did give the expected results? > > When querying for all of the graphs (with xml->html+links enabled), each > ?g is listed with a link that queries it for triples. When clicking on the > link for the refPeriod ontology, triples are returned. When doing the same > for the ethnicity graph, nothing is returned. Is this significant? Am I > wrong to expect consistent behaviour? > > My overall goal was to identify the reference periods of the observations > for each graph and compare the relative timespans between them (ethnicity > and decisions, for example), allowing for accurate selection/retrieval of > observations inside a user-specified timeframe appropriate to both/all. > > Apologies for my relative ignorance/newness - I can assure you that my > knowledge gaps are even more frustrating for me! ;) I really appreciate the > help from people much more knowledgeable! > > On 13 February 2015 at 08:38, Bill Roberts <[email protected]> wrote: > >> Hi Richard >> >> >> >> >> That will be the reason then - your query will return no results because >> there is no triple that relates the property < >> http://opendatacommunities.org/def/ontology/time/refPeriod> to < >> http://purl.org/linked-data/sdmx/2009/dimension#refPeriod> >> >> >> >> >> within the data in your database. So 'no results' is the correct answer. >> >> >> >> >> I'm afraid there's no magic going on here - your SPARQL query just does >> pattern matching against the triples in the corresponding database. >> >> >> >> >> As Andy explained, there are performance reasons for keeping a local >> cache of frequently used data, though there are facilities in SPARQL via >> the SERVICE keyword for distributing a query across more than one data >> store. Fuseki provides good support for federated queries using SERVICE but >> you need to know something about the structure and location of different >> parts of the data to make that work. >> >> >> >> >> Your original post mentioned that you had experienced timeouts with the >> online http://opendatacommunities.org/sparql service. That is set up to >> apply timeouts reasonably aggressively, so that one expensive query does >> not affect the service too much for other users. SPARQL is very flexible >> but it's quite easy to create queries that are very slow to execute. >> >> >> >> >> Without knowing more about your objectives, I'm not sure what approach is >> best for you, but running queries on >> http://opendatacommunities.org/sparql would mean you don't have to worry >> about taking local copies of all the relevant things, as it is a more or >> less coherent and managed collection of data. >> >> >> >> >> Depending on what information you want, it is usually possible to >> generate (sufficiently) efficient queries to retrieve it, but that >> sometimes takes some thinking and experimentation. >> >> >> >> >> HTH >> >> >> >> >> Bill >> >> >> Bill Roberts, CEO, Swirrl IT Limited >> Mobile: +44 (0) 7717 160378 | Skype: billroberts1966 | @billroberts >> http://swirrl.com >> >> On Thu, Feb 12, 2015 at 9:21 PM, Richard Davenport >> <[email protected]> wrote: >> >> > 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 >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>> >> >> >>>>>>> >> >> >>>>>> >> >> >>>>> >> >> >>>> >> >> >>> >> >> >> >> >> >> > >
