Not working with the current release 2.2.3 of ldf-server

[cKlee]

Not working with the current release 2.2.3 of ldf-server https://github.com/LinkedDataFragments/Server.js/releases/tag/v2.2.3

[kjetilk]

OK, do you get any error messages?

[cKlee]

No. Not an error.

With a local LDF server (version 2.2.3) running and the script

use RDF::LDF;
my $client = RDF::LDF->new(url => 'http://b-app104.sbb.spk-berlin.de/ldf/isil');
my $iterator = $client->get_statements();
while (my $statement = $iterator->()) {
}

I get: Can't use an undefined value as a subroutine reference at statements.pl line 4.

And with further investigation:

use RDF::LDF;
use DDP;
my $client = RDF::LDF->new(url => 'http://b-app104.sbb.spk-berlin.de/ldf/isil');
my $iterator = $client->get_statements();
p $iterator;

I get: undef

With

use RDF::LDF;
use DDP;
my $client = RDF::LDF->new(url => 'http://fragments.dbpedia.org/2014/en');
my $iterator = $client->get_statements();
p $iterator;

everything works as expected.

When I run the script using a previous version (2.2.2), everything works well:

use RDF::LDF;
use DDP;
my $client = RDF::LDF->new(url => 'http://b-app104.sbb.spk-berlin.de/ldf/isil');
my $iterator = $client->get_statements();
while (my $statement = $iterator->()) {
p $statement;
}

gives me:

RDF::Trine::Statement  {
    public methods (19) : as_string, bind_variables, clone, construct_args, definite_variables, from_redland, from_sse, has_blanks, new, node_names, nodes, object, predicate, rdf_compatible, referenced_variables, sse, subject, subsumes, type
    private methods (0)
    internals: [
        [0] RDF::Trine::Node::Resource,
        [1] RDF::Trine::Node::Resource,
        [2] RDF::Trine::Node::Resource
    ]
}

Cheers!

[kjetilk]

OK, thanks! I don't have time to look at it now, but I'll try to see if I can find time soonish.

[phochste]

@cKlee do you have a public server available by any chance? The provided URL is behind a firewall

[phochste]

In the new 2.2.3 versions the void:uriLookupEndpoint isn't provided anymore and this information is now stored as hydra:template. I'll provide a patch.

[phochste]

https://github.com/phochste/RDF-LDF/pull/22

[kjetilk]

Had a bit of time to look at this problem, and it doesn't seem to me like this patch would fix the problem unless they did something I wouldn't :-) So, did you check it against some running code on the other end?

In our tests, we have the following Turtle:

<http://example.org/2014/en?test=1#dataset>
    void:subset <http://example.org/2014/en?test=1> ;
    void:uriLookupEndpoint "http://example.org/2014/en?test=1{&subject,predicate,object}" ;
    a void:Dataset, hydra:Collection ;
    hydra:search [
        hydra:mapping [
            hydra:property rdf:object ;
            hydra:variable "object"
        ], [
            hydra:property rdf:predicate ;
            hydra:variable "predicate"
        ], [
            hydra:property rdf:subject ;
            hydra:variable "subject"
        ] ;
        hydra:template "http://example.org/2014/en?test=1{&subject,predicate,object}"
    ] .

So, we already have the hydra:template, but the subject of that triple isn't the same is for void:uriLookupEndpoint, and unless they change the semantics of of the former, which I can't see that they did... So, we'd have to go through hydra:search to obtain the template, right?

[phochste]

I did a test against the latest Node LDF server and the live LDF server I found online.

What happens in our code : https://github.com/phochste/RDF-LDF/blob/master/lib/RDF/LDF.pm#L562 is that we don't search for the subject hydra:seach to find all information related how to query the LDF service. Instead, and the hydra_variable , hydra_property, hydra_mapping and other void predicates are searched. This is a feature of processing, maybe not exact.

I think it is indeed better to include support for both hydra:template and void:uriLookupEndpoint predicates to lookup the pattern

[phochste]

What I see is that the void:uriLookupEndpoint seems to be deprecated in the latest releases of the Node LDF version.

[kjetilk]

Right! I saw the tests passing, but didn't understand why :-)

So, VoID seems rather unmaintained now, and since it didn't offer a way to specify the template, I can see why.

But, I can't really see a reason to just remove void:uriLookupEndpoint, but with this, I don't have any strong opinions either way.

Do what you think is best!

Do you want me to roll the release, or would you like to do it yourself?

Kjetil

[phochste]

I feel we are safe. I tested it now again on local and remote servers of different installations and get the required results. Could you roll the release? This way @cKlee has something to present in time at the ELAG conference next week :)

[kjetilk]

Sounds good!

However, I haven't used your distribution builder, and my attempt to install Dist::Milla failed. You could you please roll it?

I have updated changelog and bumped the version (thinking it is a good idea to roll a dev release first).

[phochste]

Pushed 0.23_01 to cpan

[kjetilk]

All tests passing on CPANtesters, so I suppose you can roll 0.24?

[phochste]

done