dispatch portal functionality through ont-based URL directly

[carueda]

And not as a redirection to the general portal web application.

That is, when the Ont service determines that the resolution is not for the semantic content itself (RDF), then, instead of redirecting to the portal application, display the corresponding Javascript-enabled functionality directly.

This has been envisioned for a long time, but it's becoming higher priority now that we are noting ontologies out there pointing to the portal-based URL for semantic terms!

[carueda]

A possible approach:

• "ont" service: when dispatching a particular ontology or term with the "html" output format, instead of doing the redirection to orrportal, serve the main orrportal's main html application page directly. This html contents will have the <base> element specified pointing to the orrportal URL.
• "orrportal": instead of (or besides) the history token, it examines the host page URL to determine what specific ontology or term to dispatch.

A generalization of the above is that the bare URL of the Ont service itself http:/.../ont can also dispatch the ORR Portal.

[carueda]

The general desired behavior is already implemented (but disabled by default; the interim OntServlet._364 flag on the Ont module can be set to true to enable it):

This general behavior is:

• http:/.../ont dispatches the main ORR Portal page
• http:/.../ont/some/ontology dispatches the particular ontology in the ORR Portal
• http:/.../ont?uri=http://any/registered/ontology dispatches the particular ontology in the ORR Portal
• The ORR Portal uses the original "ont" based URLs (or "ont" with the "uri" parameter) for any links to registered ontologies (instead of the history tokens based on "orr")

This makes the general navigation from main list to individual ontologies and back to the main list consistently expose only "ont" based URLs.

However, here are some observations that make the completion of this task not as straightforward.

Login session

• While it would be great to re-use any login session from "orr" in "ont" (so the user doesn't have to login again), this is not possible as neither app is a sub-path of the other.
• As it is right now, once logged in under some "ont" based URL, the user would have to login again for any other "ont" based URL. A solution to this is to make the "login" action go to a common route at the "ont" root so, once the user logs in, the session can be inherited for any other sub-path. Currently the login action opens a dialog on any "ont" based path, so the session is associated to that specific path and sub-paths, not parent paths.
• So far, not too bad. The above would require some additional effort but can be implemented.

GWT errors

• However, during local testing I've seen an occasional GWT error that seems to happen, in some cases, when trying to navigate to another page while ontology information is being loaded. Unfortunately there's no additional information anywhere when this happens! Not sure how serious this issue could be.

orr -> ont redirection

Other pending aspect is that, for any "bookmarks" out there, it would be good to redirect from the traditional "orr" to the "ont" service, for example:

From	To
http://mmisw.org/orr/#http://mmisw.org/ont/cf/parameter	http://mmisw.org/ont/cf/parameter
http://mmisw.org/orr/#http://purl.oclc.org/NET/ssnx/ssn	http://mmisw.org/ont?uri=http://purl.oclc.org/NET/ssnx/ssn

The idea here would be to define a new application --of course deployed as "orr"-- only for the purposes of the redirection; while deploying the actual Portal application with some other name for purposes of the new dispatch from "ont".

[carueda]

Fixed in v3.