Closed ghost closed 2 years ago
This is due to hash URIs. The Kennedys dataset URIs are not well-fitted for Linked Data publishing.
?uri
helps LDH make an indirect request when the dataset base URI is not relative to https://linkeddatahub.com
.
So with uri=http://topbraid.org/examples/kennedys#AlfredTucker
as the request URI, the server will only see http://topbraid.org/examples/kennedys
as URI fragments are not passed to it. As a result, this is the only URI accessible as Linked Data in the Kennedys dataset.
Now, what data is returned for this request, is up to the user. With the ct:Describe query you will get a result of DESCRIBE <http://topbraid.org/examples/kennedys> { ... }
, which is the ontology resource itself, if I remember correctly.
Note: this is due to ?this
query variable being mapped to the request URI <http://topbraid.org/examples/kennedys>
as per LDT processing model.
But if you want to get all the dataset data for this request, you need to choose a query that returns all the data from the default graph and does not depend on the request URI (?this
), for example:
DESCRIBE ?s WHERE { ?s ?p ?o }
The ISWC dataset does not use has URIs and therefore does not have this problem.
Does this help?
Clear.
On 2 July 2018 at 17:21:37, Martynas Jusevičius (notifications@github.commailto:notifications@github.com) wrote:
This is due to hash URIs. The Kennedys dataset URIs are not well-fitter for Linked Data publishing.
?uri helps LDH make an indirect request when the dataset base URI is not relative to https://linkeddatahub.com. So with uri=http://topbraid.org/examples/kennedys#AlfredTucker as the request URI, the server will only see http://topbraid.org/examples/kennedys as URI fragments are not passed to it. As a result, this is the only URI accessible as Linked Data in the Kennedys dataset.
Now, what data is returned for this request, is up to the user. With the ct:Describehttps://github.com/AtomGraph/Processor/blob/master/src/main/resources/com/atomgraph/processor/ct.ttl#L88 query you will get a result of DESCRIBE http://topbraid.org/examples/kennedys { ... }, which is the ontology resource itself, if I remember correctly. Note: this is due to ?this query variable being mapped to the request URIhttps://linkeddatahub.com/docs/administration/sitemap/using-ldt-templates http://topbraid.org/examples/kennedys as per LDT processing model.
But if you want to get all the dataset data for this request, you need to choose a query that returns all the data from the default graph and does not depend on the request URI (?this), for example:
DESCRIBE ?s WHERE { ?s ?p ?o }
The ISWC dataset does not use has URIs and therefore does not have this problem.
Does this help?
ProXML bvba Linked Data services KBO: http://data.kbodata.be/organisation/0476_068_080#id (w) www.proxml.behttp://www.proxml.be/ (e) paul@proxml.bemailto:paul@proxml.be (tw) @PaulZH (t) +32 15 23 00 76tel://+32%2015%2023%2000%2076 (m) +32 473 66 03 20tel://+32%20473%2066%2003%2020 Narcisweg 17 3140 Keerbergen Belgium
ODEdu – Innovative Open Data Education and Training based on PBL and Learning Analytics - http://odedu-project.eu/ OpenGovIntelligence – Public Administration Modernization by exploiting Linked Open Statistical Data - http://www.opengovintelligence.euhttp://www.opengovintelligence.eu/ OpenCube – Linked Open Statistical Data - http://opencube-project.eu/
I have been thinking further on this, because I thought to have seen this otherwise. It is correct that in a pure LOD context a url containing a hash when being dereferenced will be truncated and that the complete page will be returned. But if the url containing hashes is just passed as a query parameter to another service, the part after the # can be kept. Over here I have another system running. Using a structural similar url https://localhost:50443/resource/?uri=http%3A%2F%2Ftopbraid.org%2Fexamples%2Fkennedys%23AlinaMojica&repository=default just returns the triples related to AlinaLojica from the Kennedys.ttl file, nothing else.
Right, I saw this coming :)
As you know, #
fragments only make sense to the client, not the server. Lets put the indirection aside for a moment - if you would control the TopBraid's domain/server, http://topbraid.org/examples/kennedys
would be the only URI the server would see when the Kennedys dataset is served.
So the long explanation is that your other system could be considered a web-based RDF client but not really a Linked Data system. It bypasses the HTTP request URI (which presumably stays https://localhost:50443/resource/
) by using a proprietary URL parameter, which value is then injected into a SPARQL query, I assume. That way the #
fragments can be passed as well.
LDH indirection works differently in the sense that the uri=
URL parameter overrides the real request URI. I.e. when uri=http%3A%2F%2Ftopbraid.org%2Fexamples%2Fkennedys%23AlinaMojica
is passed, the LDH "thinks" that is serving http://topbraid.org/examples/kennedys
(the #AlinaMojica
is again stripped) as if it was the TopBraid server. This is required because LDT app base URIs are matched against request URIs.
But I guess the above does not matter to you in practice. Luckily I think there is a solution using LDT: you simply need to define a template parameter which maps a URL param x=http%3A%2F%2Ftopbraid.org%2Fexamples%2Fkennedys%23AlinaMojica
(can't use uri
, and probably this
) and then use it as ?x
in the SPARQL command, e.g. DESCRIBE ?x { ... }
.
I will try to set it up for the Test app and will let you know.
Using https://linkeddatahub.com/proxml/test/?filterRegex=label&uri=http://topbraid.org/examples/kennedys#AlfredTucker I get the full kennedys dataset as result. Using https://linkeddatahub.com/demo/iswc-2017/?filterRegex=label&uri=https%3A%2F%2Fw3id.org%2Fscholarlydata%2Fperson%2Fmartin-voigt I get only info on martin-voight. Is this different behaviour due to the difference in # versus / url's. Or are different templates triggered? If yes, how can I find this out in the most efficient way?