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