search

metadata-research / yamz

A crowd-sourced metadata dictionary
MIT License
9 stars 3 forks source link

Arks don't resolve #91

Closed cr625 closed 1 year ago

cr625 commented 1 year ago

https://yamz.net/term=h6295

jkunze commented 1 year ago

Suggested (untested) routes that should work: @term.route("/term=") @term.route("/ark:99152/") @term.route("/ark:/99152/") @term.route("/ark/")

cr625 commented 1 year ago

@term.route("/ark:/99152/") @term.route("/ark:99152/") @term.route("/ark/")

We now have these 3 in dev. The "/term=" route might deserve additional consideration. Blueprints in Flask came after og yamz. They let url routing enforce separation of concerns (so that there doesn't have to be one monolithic views/models module) for the application. For this syntax, it has the side effect that /term= is a different route than /term. We would have to add a new blueprint "term=" unless someone knows a better way. If we can change the rewrite rule on n2t, it would be great. If not we'll have to do the hack. We could also conditionally apply the blueprint after parsing the URL of the main route, but that is likewise a hack.

?term= would also work

the /ark redirect is another blueprint I will add.

jkunze commented 1 year ago

That's probably fine. It may be cleaner just to forget about the old /term= route altogether. I put in the changes so that the N2T resolver should get updated by the end of Monday to select ARKs matching regex ark:/?99152/h.* and redirect them to yamz.net/.

I didn't know how to test it locally. For example, https://yamz-dev.yamz.link/ark:/99152/h6295 didn't work.

I couldn't get anything from yamz-dev.yamz.net. Does someone need to ask John McNamara to register it?

cr625 commented 1 year ago

the route is always /term/* for the term model

so https://yamz-dev.yamz.link/ark:/99152/h6295 won't work yet (https://yamz-dev.yamz.link/term/ark:/99152/h6295 will)

/ark is a different route that I still have to make a blueprint for. /ark: is also a separate route but there it doesn't matter so much if we have both since nothing's hanging off of /ark yet (unlike) /term

I can point the dev server to yamz-dev.yamz.net. I only hesitate because I always manage to screw up the nginx config. I will get it done though.

Another option is to rewrite the urls with Nginx, but that adds an additional configuration requirement.

jkunze commented 1 year ago

Could https://yamz-dev.yamz.link/ark:/99152/h6295 be made to work (for whatever yamz instance/hostname)? That would be ideal.

If there's another URL path needed, let me know and I can have the yamz rule at N2T adjusted.

cr625 commented 1 year ago

ok, I'll make that a route

cr625 commented 1 year ago

Ok, https://yamz-dev.yamz.link/ark:/99152/h6295 should work.

You can add routes derived from ark (eg. /ark/something) https://github.com/metadata-research/yamz/blob/development/app/ark/views.py or let me know what they should be.

jkunze commented 1 year ago

Awesome! Thank you!

Could you also make that work with no slash after the colon? That is, "/ark:/foo" should work the same as "/ark:foo". This will future-proof Yamz for the newer form ARKs.

cr625 commented 1 year ago

FMI https://werkzeug.palletsprojects.com/en/2.2.x/routing/ https://flask.palletsprojects.com/en/2.2.x/api/#flask.request

cr625 commented 1 year ago

Closing this and opening a separate one for no slash after the colon ("/ark:/foo" should work the same as "/ark:foo") because this is outside of normal url routing and has to be handled as a special case.