ec-geolink / design

Design information about the EarthCube Geolink project.
8 stars 1 forks source link

http://schema.geolink.org/1.0/voc/nvs/C17 not accessible #87

Open krisnadhi opened 8 years ago

krisnadhi commented 8 years ago

C17.owl is not accessible via its ontology URI: http://schema.geolink.org/1.0/voc/nvs/C17

krisnadhi commented 8 years ago

@ashepherd, any idea how to make it accessible?

ashepherd commented 8 years ago

hey @krisnadhi ,

If you are calling the URI http://schema.geolink.org/1.0/voc/nvs/C17 from a browser it's going to try to build the HTML version of the OWL file. It looks like a big file, so that might be why it hangs. To get the OWL, you can add an accept header for application/xml+rdf or text/turtle or call it directly like:

http://schema.geolink.org/1.0/voc/nvs/C17.owl

krisnadhi commented 8 years ago

Ah indeed. The file is big. Even the LODE service at esseputanto stops loading when given this OWL file. Is there any way to play around with LODE installation to find a work around this?

ashepherd commented 8 years ago

been messing with LODE yesterday. ran it bypassing the proxy, but that failed to render. tried with no reasoning so it could skip using the owlapi Java code which should just apply the stylesheet to the OWL file, and that almost crashed the machine we run it on after running for 4 hours. Tried Parrot overnight, but that is still running too.

Any other tools or thoughts? otherwise, we may have to generate the HTML manually.

krisnadhi commented 8 years ago

Yes. I also tried in on my local machine, and it didn't always work. Also, the other concern is that when one wants to load main.owl on Protege remotely (retrieving it from schema.geolink.org directly), Protege would fail to load C17.owl because it is too big. I looked at this particular vocabulary again, which contains a catalog of platforms, and it seems that quite a lot of them are deprecated. If a platform name/code is deprecated, is it no longer used by any party?

Let me try if using turtle (instead of rdf/xml) would alleviate the problem.

Btw, your customization of LODE are done on the Java source?

ashepherd commented 8 years ago

no customizations needed yet. they had already setup query string parameters to dictate whether owlapi is used or not. but it seems that just applying the XSL stylesheet to the doc in Java was causing the memory issues. we could try applying a trimmed-down version of a XSL stylesheet manually as one option.

On Jan 26, 2016, at 11:23 AM, krisnadhi notifications@github.com wrote:

Yes. I also tried in on my local machine, and it didn't always work. Also, the other concern is that when one wants to load main.owl on Protege remotely (retrieving it from schema.geolink.org directly), Protege would fail to load C17.owl because it is too big. I looked at this particular vocabulary again, which contains a catalog of platforms, and it seems that quite a lot of them are deprecated. If a platform name/code is deprecated, is it no longer used by any party?

Let me try if using turtle (instead of rdf/xml) would alleviate the problem.

Btw, your customization of LODE are done on the Java source?

— Reply to this email directly or view it on GitHub https://github.com/ec-geolink/design/issues/87#issuecomment-175100713.