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








Reply via email to