New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sweetontology.net html resolution #70

Closed
carueda opened this Issue Nov 24, 2017 · 12 comments

Comments

Projects
None yet
4 participants
@carueda
Copy link
Member

carueda commented Nov 24, 2017

#51 follow-up:

Any specific HTML dispatch from http://sweetontology.net/* for the ontologies and terms? Perhaps redirect to corresponding dispatch in the COR portal?

What about http://sweetontology.net/ itself? Redirect?

@graybeal

This comment has been minimized.

Copy link
Collaborator

graybeal commented Nov 29, 2017

can we use content resolution for this? (I believe it's been mentioned in the emails.)

In particular, if a user (browser) goes to anything under sweetontology.net, it always redirects to the corresponding ORR page (and if none exists, the user is left at the relevant SWEET ontology home page on ORR, ideally). If a user (browser) goes to the home page of sweetontology.net, they are redirected to the GitHub documentation page.

If a system tries to access sweetontology.net, or any ontology under it, the specific ontology is downloaded. If a system tries to access a specific term in a SWEET ontology, I think the HTML practice would be to return the whole ontology containing the term.

Hmm, I'm not 100% sure I like this, but maybe y'all have a cooler answer.

@bethhuffer

This comment has been minimized.

Copy link

bethhuffer commented Nov 29, 2017

I'd like to know more about the use cases in which a user or system tries to access sweetontology.net, or a a specific term. I would think that what should happen would depend a lot on what we think the user or system might expect to happen.

@carueda

This comment has been minimized.

Copy link
Member Author

carueda commented Nov 29, 2017

@bethhuffer @graybeal Thanks for chiming in.

The previous #51 entry pointed to https://github.com/ESIPFed/sweet/wiki/sweetontology.net and I actually should have copied the "html" section from there to make this new entry more self-contained. Here it is:


If HTML dispatch is also desired, that is, when the sweetontology.net-based URL is entered in a typical browser (and in general, when the client application explicitly requests HTML via content negotiation or format parameter), the options include:

The redirection option should be rather straightforward to enable. However, the proxy dispatch might be significantly more involved due to the nature of the COR front-end implementation (which relies on several resources that should also be mapped appropriately).


So, again, this is a #51 follow-up. As indicated there, "semantic resolution" per se has already been implemented (at least to some extent). It seems this functionality is what John is referring to when he says "access from a system."

A concrete "semantic resolution" use case is loading any of the SWEEET ontologies in your semantic application (e.g., Protége -- BTW, see #57) by just entering the corresponding IRI, for example, http://sweetontology.net/sweetAll (which BTW will trigger the load of all other ontologies via imports). Per common content negotiation practices, the semantic application will make the request with preference for some semantic serialization format, not HTML. Of course, some other system (client application) can also request HTML if that's its preference.

John:

If a user (browser) goes to the home page of sweetontology.net, they are redirected to the GitHub documentation page.

OK, let's make that one of the options (btw, what Github documentation page?) and let's hear from others about any other possible suggestions.

@lewismc

This comment has been minimized.

Copy link
Member

lewismc commented Dec 10, 2017

Hi Folks, I just had Brooks Hanson and Shelley Stall from AGU ask me this exact thing. For the time being, i would be tempted to have sweetontology.net resolve to https://github.com/esipfed/sweet (or even the base README.md document), we should then update the README to reflect the fact that SWEET is available as linked data via the COR.
wdyt @carueda

@carueda

This comment has been minimized.

Copy link
Member Author

carueda commented Dec 10, 2017

@lewismc

Redirecting to https://github.com/esipfed/sweet would be better but the contents of the README (as dispatched by github) get positioned a bit too far down in the page due to the large number of turtle files located at first level in the project.

(As a proposal moving forward, we should probably move the ontology files to the src/ directory.)

For now, I just enabled redirection to the README directly.

@lewismc

This comment has been minimized.

Copy link
Member

lewismc commented Dec 11, 2017

Excellent @carueda
I've also made some updates to the README to cover more documentation suspect people will be interested in.
I think this is looking good.
I did notice however that http://sweetontology.org is not resolving/redirecting. It is being served by GoDaddy but the resolution appears not to have been updated. Can you have a look at that please?

@carueda

This comment has been minimized.

Copy link
Member Author

carueda commented Dec 11, 2017

@lewismc Ok, I can add a similar redirection for .org, but you will need to ask Erin or Annie about the name resolution. (btw, I believe other suffixes were also purchased, .info ... ).

@graybeal

This comment has been minimized.

Copy link
Collaborator

graybeal commented Dec 11, 2017

I like where the .net redirect goes, good choice for where SWEET is.

Do I understand correctly from the COR-enabled dispatch section of https://github.com/ESIPFed/sweet/wiki/sweetontology.net that we are currently using proxy dispatch for http requests? (Wow, dream come true! Thank you Carlos.) And if a semantic application makes the request with preference for a semantic serialization format, how does that get handled?

Sorry @carueda not sure what you mean by "the name resolution" in your last comment, can you clarify?

you will need to ask Erin or Annie about the name resolution

@carueda

This comment has been minimized.

Copy link
Member Author

carueda commented Dec 11, 2017

.. not sure what you mean by "the name resolution" in your last comment, can you clarify?

Simply that whoever is managing the Godaddy account needs to set the IP for those other names in a similar way as with the .net one. Let me tag here @erinmr and @abburgess ...


... that we are currently using proxy dispatch for http requests?

Yes and for non-HTML requests as indicated in that wiki, that is, for semantic serializations.

And if a semantic application makes the request with preference for a semantic serialization format, how does that get handled?

Well, again, as said in the wiki, the dispatch was implemented mainly with a focus on semantic access. (The fact that the whole set of SWEET ontologies can be loaded in Protégé by simply indicating the master entry http://sweetontology.net/sweetAll was a good verification of this mechanism.) Then I entered this issue specifically regarding any desired HTML dispatch.

@lewismc lewismc modified the milestones: 3.2.0, 3.3.0 Mar 7, 2018

@lewismc

This comment has been minimized.

Copy link
Member

lewismc commented Jan 18, 2019

Hi @carueda do you know where in the COR code would serve HTML for browser clients? This came up last week and people do not want to be downloading TTL files when they hit a SWEET URI in the browser... they want an HTML page... basically they want the COR page e.g. http://cor.esipfed.org/ont?iri=http://sweetontology.net/stateVisibility.
Alternatively we could render and serve a LODE page for them...

@carueda

This comment has been minimized.

Copy link
Member Author

carueda commented Jan 19, 2019

Hi @lewismc ... before looking in the ORR code itself, I'm trying to see if there's an "easy" way to handle this via apache redirect. (I'm assuming the redirect option per this comment)

@carueda

This comment has been minimized.

Copy link
Member Author

carueda commented Jan 19, 2019

I ended up implementing this in the ORR backend. (The apache redirect approach proved tricky and time consuming.)

COR updated, now 3.8.2.

You can now try clicking in your browser, for example:

Or, explicitly indicating query parameter format=html or header Accept: text/html with your preferred command line tool, program or library. More details: mmisw/orr-ont#69

@carueda carueda closed this Jan 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment