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











Reply via email to