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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
