search

buda-base / lds-pdi

http://purl.bdrc.io BDRC Linked Data Server
Apache License 2.0
2 stars 0 forks source link

refining html redirect configuration #157

Closed eroux closed 4 years ago

eroux commented 5 years ago

Here's what DILA will currently want to do (maybe that will change in the future):

this is currently not possible with our system for two reasons:

Here are some ideas to fix that:

First we should differentiate the redirect from /resource/{res} and /admindata/{res} so that we don't need to attach the prefix, we would for instance have for our config:

endpoint.resource.htmlredirect=https://library.bdrc.io/show/bdr:
endpoint.admindata.htmlredirect=https://library.bdrc.io/show/bda:

that fixes the first issue. The second problem is a bit more difficult to tackle, we need to specify in the configuration a default html and some exceptions based on either regexp or just the first letter of the local name of the resource. So DILA could use something like:

endpoint.resource.htmlredirect=http://authority.dila.edu.tw/person/?fromInner=
endpoint.resource.htmlredirect.exceptions=exceptionP
endpoint.resource.htmlredirect.exceptions.exceptionP.localNameFormat=P.*
endpoint.resource.htmlredirect.exceptions.exceptionP.redirect=http://authority.dila.edu.tw/place/?fromInner=

this requires a little bit of code to understand the config file but it's not too conceptually difficult... This is quite high priority

MarcAgate commented 5 years ago

for the second issue, why don't we use instead a type parameter in the query string ? So for /resource/{resId}?type=type_value,

if type not present-> default url else URL = http://authority.dila.edu.tw/ +type_value + ?fromInner={resId}

That would avoid obscure configuration, especially if the number of format increase with time (P, A, W, X T, etc...)

WDYT?

MarcAgate commented 5 years ago

Diving into this a little bit deeper, I don't think Ldspdi should implement specifics of any organization using it. I think an organization should adapt to BUDA generic features and not the opposite. If we don't follow that pattern, then we will end up updating our software on a regular basis according to the variation of many organizations use cases. In other words, in that very case, the logic that parse an organization resourceID and decides which endpoint the request should be redirected to shouldn't be part of ldspdi implementation.

DILA should have a http://authority.dila.edu.tw/redirect/{resourceId} endpoint (for instance) that takes the resourceId and redirect the request to the right endpoint.

Ldspdi should therefore offer the generic possibility of having a redirect URL (as it is for us) pointing to a service implemented by the organization (for instance, since DILA implements http://authority.dila.edu.tw/person/?fromInner=A000001 the DILA can implements the logic mentioned above in a "redirect endpoint").

As a matter of fact, we could even think that requiring the resource type at a /resource endpoint is somewhat a data model design flaw (i.e we should be able to access any resource with its unique IRI without mentioning its type)

I am going to implement your proposal since this feature is needed rapidly, but it's worth thinking about generic vs. specific features implementation in BUDA in general.

eroux commented 5 years ago

Sigh... fine, I'll do it when I'll come back

MarcAgate commented 5 years ago

Well, it's not really straightforward, since we also have to modify the QueryProcessor that takes a prefixed resource... And when /resource/A000001 is called with Accept:text/turtle, what do we do ?

eroux commented 5 years ago

I don't understand, what do you mean?

MarcAgate commented 5 years ago

In order to do a sparql request, you must have the full URI or at least the prefixed URI. So what do we do when /resource/A000001 is called with Accept:text/turtle ? Not mentionning that this QueryProcessor.getCoreResourceGraph method is used elsewhere in other endpoints.

MarcAgate commented 5 years ago

Will the prefix (for ANY resource) be always the same ? (if so, then it is already set in properties we just created:

endpoints.resource.shortprefix = bdr:
endpoints.resource.fullprefix = http://purl.bdrc.io/resource/

In that case there's no need to use:

endpoint.resource.htmlredirect=https://library.bdrc.io/show/bdr:
endpoint.admindata.htmlredirect=https://library.bdrc.io/show/bda:

as we already set this recently in properties:

endpoints.admindata.shortprefix = bda:
endpoints.admindata.fullprefix = http://purl.bdrc.io/admindata/

so at that point, without changing anything we can differentiate the redirect from /resource/{res} and /admindata/{res} and generate showUrl+prefix in these endpoints implementation.

At the same time, prefixed resources are still valid for the query processor in case we don't have a redirection (i.e when Accept is not text/html).

Now, we still have to create the "typed" redirect url : 3 ways at first sight:

1) via properties (as you described it) 2) via a type param in the query string (along with optional and existing "graph" and "describe" parameters (as I suggested it) 3) via temporary code inside PublicDataResource (as below)

private String getDilaResourceType(String res) {
        String type = "";
        if (res.startsWith("A")) {
            return "person";
        }
        if (res.startsWith("P")) {
            return "place";
        }
        return type;
    }

Conclusion: if the prefix for the /resource endpoint is always the same (as it should be defined in endpoints.resource.shortprefix property), then the implementation (let's call it a customization) is possible without changing anything to the properties file, using one of the 3 ways of handling the resource type.

eroux commented 5 years ago

I don't really understand what's going on... what I need is a system where an ID which local name is starting with A is redirected in html to

http://authority.dila.edu.tw/person/?fromInner=AXXX

And an ID which local name is starting with starting with P is redirected in html to

http://authority.dila.edu.tw/place/?fromInner=PXXX

There's no need to change the ttl, no need for types, no need for sparql request, no notion of prefixes, etc.

MarcAgate commented 5 years ago

This has been done (see commit 3ec4373), but:

1) it's not like you think it is because the redirection is a tiny little part of what the endpoint actually does. 2) this endpoint (and the whole system) must work for both DILA and BDRC requirements using a single endpoint and config structure. I am sure that it is fully functional for BDRC settings and dataset while I doubt seriously it is with DILA settings and dataset.

I think it will be more efficient to actually talk about this.

MarcAgate commented 4 years ago

Done. Should we close this ?