search

protegeproject / protege-server

An OWL ontology server for OWL API programs, e.g., Protege Desktop.
21 stars 16 forks source link

More Getting Started guidance on what client and server files are needed and what goes where #17

Closed lonniev closed 8 years ago

lonniev commented 8 years ago

Need a bit more guidance in the docs for tyros of Protege and Protege Server on where to obtain and install the client jars for a client Protege 5beta installation and where to execute the server run.sh.

For example, does the server require an installation of the protege client on its host? Apparently no. But this isn't easy to deduce from the guidance.

lonniev commented 8 years ago

Is this the proper repo for the client-side (Protege 5beta) plugin jars?

http://protege.stanford.edu/fileshare/p4server/

When these are in 5beta's plugins directory, the Open From Server UI additions appear (so that's promising). However, if I have 

➜  protege-server git:(master) ./target/server-distribution/server/run.sh
14:41:56 [main] INFO  - ********************************************************************************
14:41:56 [main] INFO  - **                                  Protégé                                   **
14:41:56 [main] INFO  - ********************************************************************************

running as hostname hostname on port 5100, then there is no apparent connectivity between the client on the local host and the server (above) on the localhost through the client UI.

It may be that those client jars are out of date and not the right ones for this later version of the server.

The client does throw this exception when the Connect button is clicked:

java.lang.NoSuchMethodError: org.protege.editor.core.ProtegeApplication.getErrorLog()Lorg/protege/editor/core/ui/error/ErrorLog;
    at org.protege.editor.owl.client.panel.OpenFromServerDialog$ConnectToServerActionListener.actionPerformed
rsgoncalves commented 8 years ago

@lonniev the current repositories for protege-server and protege-client are undergoing significant change in preparation for a client-server release for Protege 5. That said, the current state of the master branches of both repositories were successfully tested with Protege 5 beta 21. The steps to set up and run the server are:

lonniev commented 8 years ago

Ok, this should help quite a bit: I wasn't aware of the other protege-client project (which is very nicely named to suggest its purpose).

The odd bit is that the client's server proxy is over in the server project and not with the client project. Ok.

rsgoncalves commented 8 years ago

We're working on removing the dependency of the protege-client on the protege-server; it will get replaced with a common dependency between protege-client and protege-server, necessary for (at least) the RMI remote interfaces.

Just to wrap-up documentation, I made a wiki page with the above instructions: https://github.com/protegeproject/protege-server/wiki/Setting-up-and-running-Protege-client-server

lonniev commented 8 years ago

Ok.

This definitely makes some progress: I can interact client with server now. My first attempt isn't a self-contained ontology and so the imports of peer ontologies that use bogus IRIs caused the server to thrown an exception.

Will you offer some form of XML Catalog support for resolving against local and remote peer ontologies?

I'll try something more trivial to see what the capabilities are.

lonniev commented 8 years ago

I was able to jump through the chicken-and-egg hoops to allow the protege-server to upload one ontology that imports others (that are non-standard and not at well-known URL IRIs).

The tactic was to create a new lonniev/ontologies repository, to push versions of the ontology files there, to get their raw content URLs, to return to the source OWL files, to refactor those to use the github raw URLs as IRIs, and to upload each into the protege-server one by one.

This works.

rsgoncalves commented 8 years ago

Imports should work fine so long as imported ontologies are resolvable, that is, you can upload a single ontology that imports other ontologies, and so long as the imported ontologies' IRIs correspond to URLs that can be resolved, then everything works out well. If the IRIs are not resolvable, then what you mentioned is one way to go about it. An XML catalog (as Protege uses) would not work for ontologies stored server-side, they need to be uploaded.

lonniev commented 8 years ago

Right. Well understood.

What would be cool would be if the upload interface asked for an XML Catalog to resolve ontology imports if and only if the given IRIs are not resolvable URLs.

The upload algorithm would find the indirectly referenced missing ontologies and either use their actual URLs or would ask if the submitter would like to first upload the necessary local files into the server.

(The server should expose URLs for all stored ontologies anyway — see my other feature request — and so any ontology imported from local files would be resolvable from the server once uploaded.)

--  Lonnie VanZandt 303-900-3048

On 04 April 2016 at 17:44:07, Rafael Gonçalves (notifications@github.com) wrote:

Imports should work fine so long as imported ontologies are resolvable, that is, you can upload a single ontology that imports other ontologies, and so long as the imported ontologies' IRIs correspond to URLs that can be resolved, then everything works out well. If the IRIs are not resolvable, then what you mentioned is one way to go about it. An XML catalog (as Protege uses) would not work for ontologies stored server-side, they need to be uploaded.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub