/e-link/explore endpoint

[jnehring]

Create an endpoint /e-link/explore that fetches all triples related to a resource. It has three parameters

• resource - the resource URI
• endpoint - the endpoint URL
• endpoint-type- the type of the endpoint, ldf, or sparql. Default value is sparql

[m1ci]

requests sent as POST, right?

[jnehring]

requests sent as POST, right?

right.

[m1ci]

the SPARQL endpoint based description has been implemented

curl -v -X POST "http://api-dev.freme-project.eu/current/e-link/explore?resource=http%3A%2F%2Fdbpedia.org%2Fresource%2FBerlin&endpoint=http%3A%2F%2Fdbpedia.org%2Fsparql&endpoint-type=sparql"

The Linked Data Fragments based exploration of a resource is waiting for https://github.com/freme-project/technical-discussion/issues/74 - hosting LDF artifact in our maven repo.

[m1ci]

works also for LDF endpoints. Try

curl -v -X POST "http://api-dev.freme-project.eu/current/e-link/explore?resource=http%3A%2F%2Fdbpedia.org%2Fresource%2FBerlin&endpoint=http%3A%2F%2Ffragments.dbpedia.org%2F2014%2Fen&endpoint-type=ldf"

resource=http://dbpedia.org/resource/Berlin endpoint=http://fragments.dbpedia.org/2014/en endpoint-type=ldf

Note that the resource and the endpoint URIs should be properly encoded.

[jnehring]

Nice! When I try your example for sparql I get the output attached to this post. There is a lot of "undefined" strings in the output. E.g.

        undefined<http://dbpedia.org/property/rulingParty>undefined<http://dbpedia.org/resource/Christian_Democratic_Union_of_Germany> , undefined<http://dbpedia.org/resource/Social_Democratic_Party_of_Germany> ;
        undefined<http://dbpedia.org/property/sepHighC>
                18.800000000000000711 ;
        undefined<http://dbpedia.org/property/sepLowC>
                10.599999999999999645 ;
        undefined<http://dbpedia.org/property/sepMeanC>
                14.699999999999999289 ;
        undefined<http://dbpedia.org/property/sepRainDays>
                7.7999999999999998224 ;
        undefined<http://dbpedia.org/property/sepRainMm>
                45.100000000000001421 ;
        undefined<http://dbpedia.org/property/sepRecordHighC>
                34.200000000000002842 ;
        undefined<http://dbpedia.org/property/sepRecordLowC>
                -0.5 ;
        undefined<http://dbpedia.org/property/sepSun>
                156 ;
        undefined<http://dbpedia.org/property/singleLine>
                "yes"@en ;
        undefined<http://dbpedia.org/property/source>
                "World Meteorological Organization , HKO"@en ;

Is this a bug? In the LDF version there is no "undefined" in the response.

elink-explore-output.txt

[m1ci]

Do you run curl -v -X POST "http://api-dev.freme-project.eu/current/e-link/explore?resource=http%3A%2F%2Fdbpedia.org%2Fresource%2FBerlin&endpoint=http%3A%2F%2Fdbpedia.org%2Fsparql&endpoint-type=sparql"

for that request I dont get undefined strings

[jnehring]

Sorry. I found out that the problem originated from my client software and not from your code. So everything works fine!

I created two follow up tasks:

• https://github.com/freme-project/Documentation/issues/90
• https://github.com/freme-project/Broker/issues/117

[josauder]

Is it intended that if I try your LDF endpoint but choose sparql for the endpoint-type parameter, I get a bunch of seemingly random outputs?

curl -X POST --header "Content-Type: application/json" --header "Accept: text/turtle" "http://api-dev.freme-project.eu/current/e-link/explore?resource=http%3A%2F%2Fdbpedia.org%2Fresource%2FBerlin&endpoint=http%3A%2F%2Ffragments.dbpedia.org%2F2014%2Fen&endpoint-type=sparql"

[m1ci]

Is it intended that if I try your LDF endpoint but choose sparql for the endpoint-type parameter, I get a bunch of seemingly random outputs?

The output is not "random" but proper turtle. The thing is that if you choose sparql but the URL is pointing to LDF endpoint then the normal Jena client is used to query the endpoint as it was SPARQL. Yes, it is possible to query LDF endpoint using normal Jena client, but it is not recommended.

If you choose ldf but the URL is pointing to LDF endpoint then a proper LDF Java client is used and the output is as expected.

[josauder]

It is valid turtle, however the entities seem entirely random. I'm guessing we leave this enabled, but I think i should include a message in the documentation that this works but is not recommended.

[m1ci]

this works because we are not able (or difficult to do) detect the type of the endpoint. I suggest you highlight in the doc that the clients should double-check the endpoint-type and the actual endpoint URL whether they have chosen the right type.