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