mmisw
commented
9 years ago From caru...@gmail.com on August 16, 2010 17:02:02
[from 8/9 and 8/10 emails to vocab-devel list]
(1) I wrote code to automatically register all the 177 SWEET ontologies (as listed in the owl:import statements in http://sweet.jpl.nasa.gov/2.0/sweetAll.owl ), basically by using the programmatic interface developed during the OOI CI Semantic prototype work (which I've incorporated in the "watchdog" module for conversion/registration of external key vocabularies.)
(2) Registration is successful for 163 of the ontologies (in the other cases registration failed because of UTF-8 related problems, which seems an ORR bug -- but this should be OK for the most immediate purposes at hand.
(3) I set up unit tests to verify each registered ontology is isomorphic [1] to the original source ontology, modulo metadata properties (see (5)). These tests are successful.
(4) Registration is done in re-hosted mode, meaning the original ontology URI and namespace are preserved, eg., http://sweet.jpl.nasa.gov/2.0/top.owl# (note the hash fragment separator, which is used in all SWEET ontologies).
(5) In re-hosted mode, however, the current approach is still that ORR performs some manipulation of the file to add desired MMI metadata; so the actual file registered is NOT an exact copy of the original. As you may remember this is because ORR still wants to include additional metadata to the registered ontology (even if in re-hosted mode).
(6) Some users have expressed that they wouldn't like their submitted ontologies be altered in any way. (We have had that observation in the past, but I cannot find the email at this point.) Currently, the is no mechanism to store the submission with no alteration at all (this was part of the motivation for the "only-indexed" mode of registration--never implemented).
(7) The SWEET people may have that objection, "Please don't change my ontology in any way in the version hosted at ORR!"
(8) Mike B. said in his reply to Rob R.: "... we need the individual terms to be directly resolvable through http URLs."
(8a) We have "directly resolvable" URIs in the case of fully-hosted ontologies (those with URIs starting with http://mmisw.org/ont ) for both ontologies and individual terms, in the latter case because we use slash (/) as fragment separator (and not hash (#)).
(8b) For re-hosted ontologies (SWEET case), resolvability through the ORR system is indirect via the "uri" parameter, eg., http://mmisw.org/ont/?form=owl&uri=http://sweet.jpl.nasa.gov/2.0/top.owl (8c) The ORR Portal should be able to resolve terms for re-hosted ontologies with hash (#) separator, eg.: http://mmisw.org/orr/#http://sweet.jpl.nasa.gov/2.0/top.owl#Phenomena but this is dispatched for user interaction purposes, that is, it's not very suitable for programmatic and fast access, something that perhaps Mike B. would also like to see. (actually, I just noticed that there is a bug: such address (well for localhost, my deployment) results is the error: " http://sweet.jpl.nasa.gov/2.0/top.owl#Phenomena : URI not found in the registry.")
-- more about (8c) below --
(9) (non-critical, it's about the UI). Once registered, the SWEET ontologies (~177) would take most of the ontology list in the ORR main page (showing at the beginning because the ordering is by time of registration, most recent first), which is not bad, but it would be nice to, yes, continue showing the most recent submissions at the beginning, but no more than, say one or two entries per submitting organization...
[1] http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/rdf/model/Model.html#isIsomorphicWith%28com.hp.hpl.jena.rdf.model.Model%29 (8c) is basically about the following. Normally, HTTP servers will not see the fragment of a requested URL; eg., if the requested URL is http://sweet.jpl.nasa.gov/2.0/top.owl#Phenomena then the HTTP server will only get http://sweet.jpl.nasa.gov/2.0/top.owl just because the fragment is not technically part of the URL. The fragment is actually to be handled by the client application once the resource is retrieved. Now, the ORR Portal is not a "typical" HTTP server in the above sense: http://mmisw.org/orr/ actually launches a javascript application on the web browser; this app, among other things, is able to "see" the whole request that still appears in the location field of the browser, including the fragment, and automatically perform some appropriate action, perhaps doing a further (asynchronous) request to the back-end server. For example, upon the request http://mmisw.org/orr/#http://sweet.jpl.nasa.gov/2.0/top.owl , ORR will try to resolve the fragment (which happens to be a complete URI) against the back-end. Even more, upon the request http://mmisw.org/orr/#http://sweet.jpl.nasa.gov/2.0/top.owl#Phenomena , ORR will see the fragment " http://sweet.jpl.nasa.gov/2.0/top.owl#Phenomena, " which in turn happens to have a fragment as well. Now, I say "for user interaction purposes" just because ORR is basically about the portal (user-oriented) interface. For more programmatic purposes, direct access to the desired resource via the "ont" service would be more appropriate. But in this case, the hash would need to be "URL-encoded" (%23), so the whole thing (including the fragment) is sent to the server. The request would look like this: http://localhost:8080/ont/?uri=http://sweet.jpl.nasa.gov/2.0/top.owl%23Phenomena And this requirement should be OK in general as it's pretty customary to ask HTTP client applications to do URL-encoding as appropriate.
carueda
From caru...@gmail.com on August 06, 2010 16:51:28
This entry can be closed when this basic testing with a few selected ontologies (there are about 178 SWEET ontologies [1]) is completed and reported.
[1] As imported by http://sweet.jpl.nasa.gov/2.0/sweetAll.owl
Original issue: http://code.google.com/p/mmisw/issues/detail?id=272