Thanks guys I'd guessed that I probably made some naïve assumptions. Also
kind of assumed that after retrieving remote data the first time, it'd be
automatically cached! That'll teach me.
So after downloading and installing the various triple sets (sdmx, rdfs),
the query still doesn't work. Likewise, simplifying it to:
SELECT DISTINCT ?rp ?label
WHERE
{ ?rp rdfs:label ?label
GRAPH tgt:
{ ?s <http://opendatacommunities.org/def/ontology/time/refPeriod> ?rp
{
}
Also returned zero results. Simplifying it further to:
SELECT DISTINCT ?rp
WHERE
{
GRAPH tgt:
{ ?s <http://opendatacommunities.org/def/ontology/time/refPeriod> ?rp
{
}
Did give the expected results?
When querying for all of the graphs (with xml->html+links enabled), each ?g
is listed with a link that queries it for triples. When clicking on the
link for the refPeriod ontology, triples are returned. When doing the same
for the ethnicity graph, nothing is returned. Is this significant? Am I
wrong to expect consistent behaviour?
My overall goal was to identify the reference periods of the observations
for each graph and compare the relative timespans between them (ethnicity
and decisions, for example), allowing for accurate selection/retrieval of
observations inside a user-specified timeframe appropriate to both/all.
Apologies for my relative ignorance/newness - I can assure you that my
knowledge gaps are even more frustrating for me! ;) I really appreciate the
help from people much more knowledgeable!
On 13 February 2015 at 08:38, Bill Roberts <[email protected]> wrote:
> Hi Richard
>
>
>
>
> That will be the reason then - your query will return no results because
> there is no triple that relates the property <
> http://opendatacommunities.org/def/ontology/time/refPeriod> to <
> http://purl.org/linked-data/sdmx/2009/dimension#refPeriod>
>
>
>
>
> within the data in your database. So 'no results' is the correct answer.
>
>
>
>
> I'm afraid there's no magic going on here - your SPARQL query just does
> pattern matching against the triples in the corresponding database.
>
>
>
>
> As Andy explained, there are performance reasons for keeping a local cache
> of frequently used data, though there are facilities in SPARQL via the
> SERVICE keyword for distributing a query across more than one data store.
> Fuseki provides good support for federated queries using SERVICE but you
> need to know something about the structure and location of different parts
> of the data to make that work.
>
>
>
>
> Your original post mentioned that you had experienced timeouts with the
> online http://opendatacommunities.org/sparql service. That is set up to
> apply timeouts reasonably aggressively, so that one expensive query does
> not affect the service too much for other users. SPARQL is very flexible
> but it's quite easy to create queries that are very slow to execute.
>
>
>
>
> Without knowing more about your objectives, I'm not sure what approach is
> best for you, but running queries on http://opendatacommunities.org/sparql
> would mean you don't have to worry about taking local copies of all the
> relevant things, as it is a more or less coherent and managed collection of
> data.
>
>
>
>
> Depending on what information you want, it is usually possible to generate
> (sufficiently) efficient queries to retrieve it, but that sometimes takes
> some thinking and experimentation.
>
>
>
>
> HTH
>
>
>
>
> Bill
>
>
> Bill Roberts, CEO, Swirrl IT Limited
> Mobile: +44 (0) 7717 160378 | Skype: billroberts1966 | @billroberts
> http://swirrl.com
>
> On Thu, Feb 12, 2015 at 9:21 PM, Richard Davenport
> <[email protected]> wrote:
>
> > Hi Bill, you have everything correct. I haven't copied the sdmx or other
> > ontologies because I assumed that the ontology would be retrieved
> directly
> > from it's URI (pointing to the purl.org server).
> > I'm guessing that I should try downloading that ontology, re-up it to my
> > own Fuseki, adjust the prefix URI in the query to match and see what
> > happens? If it works then great. But unless I have fundamentally
> > misunderstood linked/semantic data, doesn't having to host all of the
> > definitions and ontologies defeat the purpose?
> > On 12 February 2015 at 20:26, Bill Roberts <[email protected]> wrote:
> >> Hi Richard
> >>
> >>
> >> Sorry, haven't followed everything in this thread so apologies if I have
> >> missed something you have already explained.
> >>
> >>
> >>
> >>
> >> My understanding: you have downloaded a dump of one of the datasets from
> >> ODC and loaded it into a local Fuseki. The query you mentioned yesterday
> >> returns no results.
> >>
> >>
> >>
> >>
> >> Your query looks for properties that are subproperties of the sdmx
> >> refPeriod property from the data cube ontology.
> >>
> >>
> >>
> >>
> >> In ODC, the definitions of the ontologies used are in separate graphs.
> >> Have you taken a copy of the relevant ontology too?
> >>
> >>
> >>
> >>
> >> Cheers
> >>
> >>
> >>
> >>
> >> Bill
> >>
> >>
> >> Bill Roberts, CEO, Swirrl IT Limited
> >> Mobile: +44 (0) 7717 160378 | Skype: billroberts1966 | @billroberts
> >> http://swirrl.com
> >>
> >> On Thu, Feb 12, 2015 at 7:54 PM, Richard Davenport
> >> <[email protected]> wrote:
> >>
> >> > 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
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
>
