-
Notifications
You must be signed in to change notification settings - Fork 34
sweetontology.net
The Apache settings to dispatch requests against http://sweetontology.net are described below.
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:
-
redirect to corresponding dispatch at the COR. For example, if the user enters http://sweetontology.net/reprDataProduct in a browser, then it gets redirected to http://cor.esipfed.org/ont?iri=http://sweetontology.net/reprDataProduct.
-
proxy dispatch, so http://sweetontology.net/reprDataProduct is transparently handled as with http://cor.esipfed.org/ont?iri=http://sweetontology.net/reprDataProduct (i.e., with no change in the originally requested URL).
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
orhttp://sweetontology.net/ont/*
(/ont
is where COR is deployed oncor.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>
viahttp://cor.esipfed.org/ont/api/v0/ont?iri=http://sweetontology.net/<NAME>
. The flags here mean:-
P
: Proxy resolution. -
QSA
: Allows to append any query string to theiri=...
indicated for the resolution. This allows to resolve a particular desired format via theformat
parameter (eg., http://sweetontology.net/stateEnergyFlux?format=rdf, or, similarly, a particular version (eg., http://sweetontology.net/stateEnergyFlux?version=YYYYMMDDTHHMMSS`. -
NE
: No escape of characters like?
,&
. -
L
: Last rule to be applied.
-