AtomGraph / LinkedDataHub

The low-code Knowledge Graph application platform. Apache license.
https://atomgraph.github.io/LinkedDataHub/
Apache License 2.0
493 stars 124 forks source link

url format question #5

Closed ghost closed 2 years ago

ghost commented 6 years ago

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?

namedgraph commented 6 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?

ghost commented 6 years ago

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?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/AtomGraph/LinkedDataHub/issues/5#issuecomment-401841106, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAauFX6ZN2OzO_-sLnjPqiPTckv5v8gQks5uCjp7gaJpZM4U_AGj. Kind Regards, Paul Hermans

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/

ghost commented 6 years ago

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.

namedgraph commented 6 years ago

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.