Skip to content

sweetontology.net

Carlos A. Rueda-Velásquez edited this page Dec 10, 2017 · 12 revisions

The Apache settings to dispatch requests against http://sweetontology.net are described below.

Status

Note, only non-HTML formats are handled at the moment. This should in general be appropriate for requests from typical semantic tools and applications, e.g., Protégé, TopBraid Composer.

HTML dispatch?

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).

In summary, input is welcome regarding the desired HTML dispatch, and in general about any issues or enhancements.


COR-enabled dispatch of requests against http://sweetontology.net

The Apache settings for purposes of resolving requests against sweetontology.net via the COR, are captured in /etc/httpd/conf.d/sweetontology.conf on the same GMU/ECITE server where the COR is deployed:

<VirtualHost *:80>
    ServerName sweetontology.net
    DocumentRoot "/var/www/html/sweetontology.net"
    AliasMatch "/?" "/var/www/html/sweetontology.net/index.html"

    RewriteEngine  On
    RewriteRule    ^/ont ^/ont/.* [L,R=404]
    RewriteRule    /(.+) http://cor.esipfed.org/ont/api/v0/ont?iri=http://sweetontology.net/$1 [P,QSA,NE,L]
</VirtualHost>

Explanation

  • As a placeholder, I created /var/www/html/sweetontology.net/index.html and set a corresponding alias for resolution of the domain name itself, http://sweetontology.net.

    Such base name request could be used to provide general information about SWEET, etc. Or a simple redirect can also be indicated.

  • Because of the subsequent rule, to avoid confusion in case of requests to http://sweetontology.net/ont or http://sweetontology.net/ont/* (/ont is where COR is deployed on cor.esipfed.org), I set a rule to simply respond with 404. Without this rule, this /ont/* request would be processed by the subsequent rule, resulting in some unintended partial dispatch by the COR, which should simply be avoided.

  • Then comes the key rule for the transparent resolution of http://sweetontology.net/<NAME> via http://cor.esipfed.org/ont/api/v0/ont?iri=http://sweetontology.net/<NAME>. The flags here mean:

Clone this wiki locally