Simple SPARQL Query, different results?

[vector vision]

Greetings,

I'm a newbie to SPARQL as well as easyRDF, so apologies for what is probably a silly mistake.

Querying the http://opendatacommunities.org/sparql endpoint with the following, returns the expected results (title and description of the graph):

PREFIX tgt: <http://opendatacommunities.org/data/homelessness/homelessness-decisions/decisions>
PREFIX dcterms: <http://purl.org/dc/terms/>
SELECT ?title ?description
WHERE
  { tgt: dcterms:title ?title .
    tgt: dcterms:description ?description }

However, when trying to execute the same query from my own environment (PHP5.3, easyRDF0.90), using the otherwise-correctly-configured sparql_queryform.php from the examples, I get three blank nodes (_:genid).

I'd really appreciate any advice and thanks in advance. :)

[Alexey Zakhlestin]

The endpoint doesn’t return correct content-type, which leads to parse-errors.

So, we have several issues here:

1. Our parser code is too optimistic. It should fail explicitly as soon as something goes wrong
2. Our result-type detector is sub-optimal. It could initiate heuristical analysis of data when default parser failed

I’ll post github issues for these later today.

And while (1) might be fixed for both 0.9 and 0.10/master, (2) will probably be 0.10+ as it is a change of behaviour


thanks for this usecase!

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc

[vector vision]

Thanks Alexey. So how can I mitigate this issue? Do I need to use a different library that allows me to override the content type to what is actually returned?

A project requirement is to use this endpoint/these graphs. So I'm grateful for any advice!

[Alexey Zakhlestin]

> On 14 Jan 2015, at 13:25, vector vision <ece0...@myport.ac.uk> wrote:
>
> Thanks Alexey. So how can I mitigate this issue? Do I need to use a different library that allows me to override the content type to what is actually returned?
>
> A project requirement is to use this endpoint/these graphs. So I'm grateful for any advice!

is switching to dev-branch ok for you?
if yes, I'll be able to implement some code changes which will allow you to build a custom solution using lower level primitives of EasyRdf, until proper solution is implemented

[vector vision]

That's a really kind offer, thank you :) please let me know when/what I have to do .

[Alexey Zakhlestin]

> On 14 Jan 2015, at 15:12, vector vision <ece0...@myport.ac.uk> wrote:
>
> That's a really kind offer, thank you :) please let me know when/what I have to do .

1. change composer.json to use “dev-master” version of easyrdf and run “composer update"

2. if you use any custom code — change it to use new namespace-based class-names

all of the official examples are updated here: https://github.com/njh/easyrdf/tree/master/examples

3. check https://github.com/njh/easyrdf/issues/228 for updates.

I’ll try to finish this in the next 24h. The task is not huge, but I have short time-slots today

[Alexey Zakhlestin]

> On 14 Jan 2015, at 16:16, Alexey Zakhlestin <inde...@gmail.com> wrote:
>
>
>> On 14 Jan 2015, at 15:12, vector vision <ece0...@myport.ac.uk> wrote:
>>
>> That's a really kind offer, thank you :) please let me know when/what I have to do .
>
> 1. change composer.json to use “dev-master” version of easyrdf and run “composer update"
>
> 2. if you use any custom code — change it to use new namespace-based class-names
>
> all of the official examples are updated here: https://github.com/njh/easyrdf/tree/master/examples
>
> 3. check https://github.com/njh/easyrdf/issues/228 for updates.
>
> I’ll try to finish this in the next 24h. The task is not huge, but I have short time-slots today

so, it is done.

you have to do a simple thing:

<?php
use EasyRdf\Sparql\Client;
use EasyRdf\Sparql\Result;

class CustomClient extends Client
{
protected function parseResponseToQuery($response)
{
return new Result($response->getBody(), 'application/sparql-results+json');
}
}

now, just use this CustomClient instead of the base one.
But it will work only for SELECT queries (CONSTRUCT queries use different mime-types).

If you need to handle construct-queries too, you will need a bit more complex solution:

1. detect type of the query
2. depending on (1) chose either this parsing code or parsing via Graph class with mime-type corresponding to the data this endpoint gives.

[vector vision]

The server admin updated the library with the latest updates, but now this error:
"Fatal error: Class 'EasyRdf\RdfNamespace' not found in /usr/share/php/EasyRdf/

Literal.php on line 146"

Do I need to replace 'EasyRdf\RdfNamespace' with 'EasyRdf_Namespace' everywhere it occurs, or something?

[Alexey Zakhlestin]

> On 15 Jan 2015, at 14:53, vector vision <ece0...@myport.ac.uk> wrote:
>
> The server admin updated the library with the latest updates, but now this error:
> "Fatal error: Class 'EasyRdf\RdfNamespace' not found in /usr/share/php/EasyRdf/
> Literal.php on line 146"
>
> Do I need to replace 'EasyRdf\RdfNamespace' with 'EasyRdf_Namespace' everywhere it occurs, or something?

You need to install EasyRDF either via composer or, at least, via PSR-4 compatible autoloader.
Just putting it in pear-folder wouldn’t work. You need an autoloader which knows that "/usr/share/php/EasyRdf” is a path for loading classes from EasyRdf namespace

Composer is preferred, still.

[Alexey Zakhlestin]

> On 15 Jan 2015, at 16:41, Alexey Zakhlestin <inde...@gmail.com> wrote:
> On 15 Jan 2015, at 14:53, vector vision <ece0...@myport.ac.uk> wrote:
>>
>> The server admin updated the library with the latest updates, but now this error:
>> "Fatal error: Class 'EasyRdf\RdfNamespace' not found in /usr/share/php/EasyRdf/
>> Literal.php on line 146"
>>
>> Do I need to replace 'EasyRdf\RdfNamespace' with 'EasyRdf_Namespace' everywhere it occurs, or something?
>
> You need to install EasyRDF either via composer or, at least, via PSR-4 compatible autoloader.
> Just putting it in pear-folder wouldn’t work. You need an autoloader which knows that "/usr/share/php/EasyRdf” is a path for loading classes from EasyRdf namespace
>
> Composer is preferred, still.

In case you never used Composer…

1. install composer https://getcomposer.org/download/
2. in a folder, where your project is (preferrably not htdocs, but a higher level) run:

php composer.phar require easyrdf/easyrdf “dev-master”
php composer.phar install

3. the file vendor/autoload.php would be created. “require” it from your code

[vector vision]

Thank you very much indeed for this assistance. Queries work as expected now. However....

This is probably a different question, not absolutely related to easyRDF but maybe you can advise:

I'm running queries like this against the same SPARQL endpoint (http://opendatacommunities.org/sparql), both from easyRDF and the HTTP form on the endpoint server itself:

PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX dim: <http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX tgt: <http://opendatacommunities.org/graph/homelessness/homelessness-acceptances/ethnicity>
SELECT DISTINCT ?period ?label
WHERE {
  ?property rdfs:subPropertyOf* dim:refPeriod .
  ?period rdfs:label ?label .
GRAPH tgt: {
  ?subject ?property ?period .
}
} ORDER BY ?period LIMIT 1

Unfortunately I just get 403/timeouts - even when as in this case limiting the search. The endpoint consistently behaves like this, except for few occasions where I am able to retrieve some data (but even then it is slow to return).

Is my query constructed in a way that makes it very inefficient? Otherwise is the remote endpoint just lacking in capacity? The former should be relatively easy to resolve in comparison with the latter!

If it is something beyond my control, then I guess I'll have no choice but to periodically download a complete dump of the data and rehost it myself? Thus defeating the principle of linked data?

Thanks again for your kind help :)

[Alexey Zakhlestin]

On 28 Jan 2015, at 18:25, vector vision <ece0...@myport.ac.uk> wrote:
>
> Unfortunately I just get 403/timeouts - even when as in this case limiting the search. The endpoint consistently behaves like this, except for few occasions where I am able to retrieve some data (but even then it is slow to return).
>
> Is my query constructed in a way that makes it very inefficient? Otherwise is the remote endpoint just lacking in capacity? The former should be relatively easy to resolve in comparison with the latter!
>
> If it is something beyond my control, then I guess I'll have no choice but to periodically download a complete dump of the data and rehost it myself? Thus defeating the principle of linked data?

That is a common problem with public SPARQL endpoints, unfortunately :-(
The only “inefficient” part of your query is the property-path. You can try to query endpoint iteratively for each single level.

That’s kind of a growth issue, I believe. Number of consumers is already large, but interest of data-providers is much less so.

Downloading and re-hosting might be the most reliable plan. Especially if you intend this as a long-term project (enpoints come and go, but you still need their data)

[Osma Suominen]

On 29/01/15 11:36, Alexey Zakhlestin wrote:

> That is a common problem with public SPARQL endpoints, unfortunately :-(
> The only “inefficient” part of your query is the property-path. You can try to query endpoint iteratively for each single level.
>
> That’s kind of a growth issue, I believe. Number of consumers is already large, but interest of data-providers is much less so.
>
> Downloading and re-hosting might be the most reliable plan. Especially if you intend this as a long-term project (enpoints come and go, but you still need their data)

Linked Data Fragments (http://linkeddatafragments.org/) is an attempt at
tackling this problem, i.e. making RDF sources easier to query without
the performance/scalability/reliability issues of public SPARQL
endpoints. But of course the data provider has to have an interest in
providing the data in this Triple Pattern form.

-Osma

--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Teollisuuskatu 23)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.s...@helsinki.fi
http://www.nationallibrary.fi

[fflvv]

Hello,

I've just created an account for this group, in order to report a problem which I began to explain on StacKOverflow. Let me know if I should create a new discussion.

I installed as suggested in the "getting started" doc : composer -> 0.9.1 version. My problem is that I can't get EasyRdf_Graph object with a construct query against Virtuoso (especially http://data.bnf.fr/sparql) whereas it works with Fuseki. I solved this by installing dev-master version, but TallTed (who is Virtuoso specialist) says there's still a problem with the request headers. According to him, the parameter "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0" should be changed so that the endpoint response can be the appropriate content-type (the current content-type returned by dev-master version is text/html).

One more question : I'd like to understand how EasyRDF dev-master can return EasyRdf_Graph whereas the headers don't ask for the appropriate content-type.

Here is the link for StackOverflow question : https://stackoverflow.com/questions/52221250 .

Thanks in advance

VV