GoogleCodeExporter
commented
8 years ago [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#isIsomo
rphicWith%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.
Original comment by caru...@gmail.com on 17 Aug 2010 at 12:02
Original issue reported on code.google.com by
caru...@gmail.comon 6 Aug 2010 at 11:51