• Run Protege (platform independent version),
• Open the pizza ontology,
• go to the class hierarchy
• iterate over subclasses of Pizza using the cursor

For me Protege jumps to the next subclass after a significant delay (about half a second). Previously it was almost instant.

I did some investigation. It turns out the problem happens with the recent version of java (1.8.0_144 and 1.8.0_152 from today). It works swiftly with java 1.8.0_77 and before:

    1.8.0_152, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home
    1.8.0_144, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home
    1.8.0_77, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
    1.8.0_60, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home
    1.7.0_51, x86_64:	"Java SE 7"	/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home
    1.7.0_40, x86_64:	"Java SE 7"	/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home
    1.6.0_65-b14-462, x86_64:	"Java SE 6"	/Library/Java/JavaVirtualMachines/1.6.0_65-b14-462.jdk/Contents/Home
    1.6.0_65-b14-462, i386:	"Java SE 6"	/Library/Java/JavaVirtualMachines/1.6.0_65-b14-462.jdk/Contents/Home

Here is what I see in the profiler (VisualVM, Hot Spots, sorted by CPU time) for java 1.8.0_152:

As you can see, over 90% of CPU time is spent on getting the mouse position.

In comparison, here is the same picture for java 1.8.0_77:

Possibly a java bug?

Running on macOS 10.13 (17A405)

Protege 5 beta16 seems to use owlapi3.5.0, which means that obo saves are messed up.

I load this ontology:

ontology: t

[Term]
id: X:1
name: x1
is_a: X:2

[Term]
id: X:2
name: x2

I edited the name/label, then saved.

I get this:

format-version: 1.2
date: 12:03:2015 17:36
saved-by: cjm
auto-generated-by: The OWL API (version 3.5.1)
id_space: t http://purl.obolibrary.org/obo/t.owl#
id_space: rdfs http://www.w3.org/2000/01/rdf-schema#
id_space: obo http://purl.obolibrary.org/obo/
id_space: owl http://www.w3.org/2002/07/owl#
id_space: oboInOwl http://www.geneontology.org/formats/oboInOwl#
id_space: xsd http://www.w3.org/2001/XMLSchema#
id_space: rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#


! ----------------------  CLASSES  -------------------------

[Term]
id: X_1
name: x1
namespace: obo
is_a: X_2
id: X:1

[Term]
id: X_2
name: x2 zzz
namespace: obo
is_a: Thing
id: X:2


! ----------------------  PROPERTIES  -------------------------


! ----------------------  INSTANCES  -------------------------

this looks like the ancient obo writer. The header says generated by owlapi 3.5.1, which I believe should have the real oboformat writer, so this is puzzling.

cc @sesuncedu @dosumis

Upgrading to OWL API 4.5.5 is problematic due class loading problems that occur with the combination of OSGi and the custom OWL API Dependency Injection Mechanism.

More comments here: https://github.com/protegeproject/protege/pull/798

While we can workaround this in Protege by using manual DI (or some other framework) it's causing problems with any plugins (e.g. reasoners) that instantiate their own OWLOntologyManager using OWLManager.create..... This is exhibited in HermiT for example.

Copying in @ignazio1977, @cmungall, @jamesaoverton

protege 5.1.0 hangs during file operation in Mac OS X 10.12.

Step to reproduce:

1. Open protege.
2. Save the current ontology; or, open a saved ontology file.

The crash log can be found here.

The plant trait ontology editors would like to keep their source file in obo (for diffs) and edit in Protege. Unfortunately Protege hangs whenever they try and save.

The ontology can be parsed and saved using the OWLAPI so it seems likely there is something in Protege causing this. I have been unable to reduce this to a small test example (since it requires opening up Protege, making a change, saving, which is time consuming). There are no obvious culprits, and I have not seen this behavior in any ontology.

To reproduce:

1. clone the following repo: https://github.com/Planteome/plant-trait-ontology
2. use commit 11bb1305eabecd3c02e8f7d25e6c55a108c7c4ba (not necessarily important but just to be sure our environments are identical)
3. Open the file plant-trait-ontology.obo in Protege
4. Edit anything in the main ontology (not an important). Try carbon sensitivity, modify the textual definition
5. Save

Protege will hang.

We are using the latest Protege -- About shows "Protege 5.0.0. (Build )"

cc @marieALaporte @austinmeier @cooperl09

/Applications/Protege_5.0_beta/run.command ; exit; Exception in thread "main" java.lang.UnsupportedClassVersionError: org/protege/osgi/framework/Launcher : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) logout

[Opération terminée]

When saving the active ontology, sometime the save progress bar freezes. No information is printed to the terminal after "Saved workspace" to give detail on the error.

We made some instructions on how to setup Protege in Eclipse using the Plug-in Development Environment (PDE). I think, they could be useful to other Protege (plug-in) developers. Is it OK to move them to the Protege wiki here? (It seems that anyone can edit that?)

Protege-5.5.0-beta-7 cannot display the class names Chinese-named in Windows 10 Pro and Ubuntu!

我下载的 Protege-5.5.0-beta-7-win.zip在Windows10 Pro中无法显示中文命名的类名！ 换了多台电脑测试以及在虚拟机中安装全新Win10环境，都无法正常显示 中文命名的类名。

Detail： OS：Windows 10 Pro OS Version：10.0.17134 Build 17134（1803） OS Language：Simplified Chinese Software Package：Protege-5.5.0-beta-7-win.zip

OS：Ubuntu OS Descributor：Ubuntu 18.04.1 LTS OS Language：Simplified Chinese Software Package：Protege-5.5.0-beta-7-linux.tar.gz

Since the Protege5 I downloaded does not support chinese-named class names, this test ontology file is created with Protege4.3 after replacing "bin\felix. jar" Download the test Ontology：Test Ontology.zip

Other(Protege-5.2.0-win.zip)：

Reported from the mailing list.

"After using Mac version 5.0.0-beta-17 successfully for a couple of days, I am now getting a graphics error on the Class hierarchy view that I have been unable to resolve. I have attached a screen shot of what this looks like. Using Mac OSX 10.7.5. "

Debug logs are available at: https://www.dropbox.com/s/pr5csjnanzpuccu/console%20output.txt?dl=0 Seven log files from log folder: https://www.dropbox.com/s/0ujoemz7zbhz4rv/protege-343.log?dl=0 https://www.dropbox.com/s/xncv6q2t3woeyvz/protege-344.log?dl=0 https://www.dropbox.com/s/jpj3eqxmkz4vw9t/protege-345.log?dl=0 https://www.dropbox.com/s/947jr7u2mn1pvsk/protege-346.log?dl=0 https://www.dropbox.com/s/xjjn0gf6y9v5zsy/protege-347.log?dl=0 https://www.dropbox.com/s/k3orxl7xja8xbr8/protege-348.log?dl=0 https://www.dropbox.com/s/hn3gqgt3fjlirlz/protege-349.log?dl=0

The ArrayIndexOutOfBoundsException is not properly logged, unfortunately. There is no red triangle shown.

This problem affect also others on Mac OSX and P5.0.0-b17.

Protege 4.3 works fine.

Sample Log:

Last login: Tue May 26 14:41:17 on ttys001
xxx:~ xxx$ /Users/xxx/protege\ 5.0\ beta-17/Protege-5.0.0-beta-17/run.command ; exit;
org.eclipse.equinox.common registering service org.eclipse.osgi.service.urlconversion.URLConverter
org.eclipse.equinox.common registering service org.eclipse.core.runtime.IAdapterManager
org.eclipse.equinox.common registering service org.osgi.service.url.URLStreamHandlerService
org.eclipse.equinox.registry registering service org.eclipse.core.runtime.IExtensionRegistry
Starting Protege Desktop (Version 5.0.0, Build = beta-17)
Platform:
    Java: JVM 1.8.0_40-b27 Memory: 7635M
    Language: en, Country: US
    Framework: Apache Software Foundation (1.7)
    OS: macos (10.7.5)
    Processor: x86-64
Plugin: Cajun Visualization Library (1.0.2)
Plugin: Guava: Google Core Libraries for Java (18.0.0)
Plugin: DL Query (2.0.2)
Plugin: OWLViz (4.1.4)
Plugin: OBOactions (0.1.0)
Plugin: OWL Code Generation Plug-in (1.0.2)
Plugin: OWL Difference (5.0.0)
Plugin: Protege Editor OWL (5.0.0.beta-17)
Plugin: Protege SPARQL Plugin (1.0.0)
Plugin: Explanation Workbench (2.0.0)
Plugin: Protege HermiT Integration (1.0.0)
Plugin: Protege OBO plugin (1.1.2)
Plugin: OntoGraf (1.0.3)
Plugin: OWL Difference Engine (2.0.0)
Plugin: OWLAPI RDF Library (1.0.2)
Plugin: ELK Reasoner Protege Plug-in (0.4.2)
Plugin: owlapi-osgidistribution (3.5.1)
    Cajun Visualization Library Plugin has no plugin.xml resource
    Guava: Google Core Libraries for Java Plugin has no plugin.xml resource
    OWL Difference Engine Plugin has no plugin.xml resource
    OWLAPI RDF Library Plugin has no plugin.xml resource
    owlapi-osgidistribution Plugin has no plugin.xml resource
Using OWL API version 3.5.1
Rebuilding entity indices...
... rebuilt in 4 ms
org.protege.editor.owl registering service org.protege.editor.core.editorkit.EditorKit
Reselection event..... verifying selections.
Setting active ontology to OntologyID(OntologyIRI(<http://www.semanticweb.org/csmith/ontologies/2015/4/untitled-ontology-339>))
Rebuilding entity indices...
... rebuilt in 2 ms
Reselection event..... verifying selections.
... active ontology changed
...
---------------Logging equivalences---------------
---------------Equivalences Logged---------------
Rebuilding search metadata cache...
    ...rebuilt search metadata cache in 669 ms
Starting search 2 (pattern: \Qmammary\E)
    finished search 2 in 255 ms (759 results)
Error logged
java.lang.ArrayIndexOutOfBoundsException
Uncaught Exception in thread AWT-EventQueue-0
java.lang.ArrayIndexOutOfBoundsException
Error logged
java.lang.ArrayIndexOutOfBoundsException
Uncaught Exception in thread AWT-EventQueue-0
java.lang.ArrayIndexOutOfBoundsException
Error logged

(enhancement request)

OBO-Edit has a tool for merging two classes. This is described here:

http://oboedit.org/docs/html/Merging.htm

(this doesn't describe the effects of merging other axioms types, like equivalence axioms or disjoint axioms)

This is one of the features missed by OE users when I turn them to Protege; the steps must be performed manually.

A Protege merge tool would be more generic than the OE one - for example, Protege does not make any assumptions about specific annotation properties. I think OE users would be more than happy with a generic merge, i.e. essentially the same thing as using the EntityRenamer in the OWLAPI (with the source URI preserved somehow)

This functionality may belong in a plugin, e.g. https://github.com/balhoff/obo-actions

(which performs the related 'obsoletion' operation) cc: @dosumis

It's a common experience when using opaque IRIs, such as those used with OBO, combined with omission of imports that opaque IRIs will be displayed in the hierarchy and axioms, causing confusion.

I propose that Protege keep a database mapping IRIs to labels, updated each time it opens an ontology that provides those labels. Then, subject to a preference, if a label is not available, the last known label could be used for display, perhaps with an indication of its status. This database would be constructed on the fly as the user opens different ontologies.

Extra credit for going beyond rdfs:label and recording associations to all common label properties as well as an property that is seen at some point as a subproperty of rdfs:label. That way there's also the possibility of respecting the priority order for label display preference.

I am building a protege plugin and am struggling with making the jar so that Protege will load the project correctly. I made a stack post about it.

This is the error I'm encountering:

[FelixStartLevel] ERROR FrameworkSlf4jLogger    Error starting file:<someName>-1.0.jar
org.osgi.framework.BundleException: Unable to resolve <someName>[28](R 28.0): missing requirement [<someName>[28](R 28.0)] osgi.wiring.package; (osgi.wiring.package=org.neo4j.cypherdsl.core) Unresolved requirements: [[<someName>[28](R 28.0)] osgi.wiring.package; (osgi.wiring.package=org.neo4j.cypherdsl.core)]
    at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111) ~[org.apache.felix.main.jar:na]
    at org.apache.felix.framework.Felix.startBundle(Felix.java:2117) ~[org.apache.felix.main.jar:na]
    at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371) ~[org.apache.felix.main.jar:na]
    at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) [org.apache.felix.main.jar:na]
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]

In the last days I switched from a Windows 10 Pro to a (more powerful) Windows 11 Pro notebook.

On Windows 10 Pro, the startup time of the latest Protege version was slow but not too slow: I have never felt the need to time its startup.

On the new Windows 11 Pro notebook, with the latest Java VM java version "1.8.0_351", Protege (5.5 or 5.2) takes about 1 minute and 40 seconds to startup.

Windows 11 Pro is version 22H2 with Windows Feature Experience Pack 1000.22638.1000.0.

Both the platform-specific Windows distribution and the platform-independent versions are that slow.

Do you have any suggestion on what to look at?

The new notebook as a high DPI display: could the startup time be related to that?

This is just to keep a record for future work.

Using the terminal

open ontology.owl

Or double clicking on a file in Finder used to work with Protege 5.5.0, but now does not. Here is a summary of @gouttegd analysis about the issue, leaving out some of the ranting :P

@gouttegd says:

Since approximately the times of Brian Kernighan and Dennis Ritchie, the standard way of passing arguments (say, filenames) to a program was to pass them as arguments to the main function of said program. That is, if you call myprog myfile, the main function of myprog would be called with an array containing myfile (along with the name under which the program was called, but that’s irrelevant). That standard approach has since then been used by all operating systems (even Windows!) and almost all languages. But of course, that is too standard for Apple. [...censored rant...].

So, on macOS, when you call open ecto-edit.owl, [...censored..] finds an appropriate application for .owl file, and then does not call that application with ecto-edit.owl as an argument! Instead, it calls the application with an empty command line, and then sends the application an Apple-specific event that the application is supposed to react to (by using the Apple-specific Cocoa API). Now, Protégé contains some code specifically intended to deal with this kind of Apple [..censored..], but this is one of the area that has required some changes with the migration to Java11, and apparently the new code is not working…

Bottom line: this is not, contrary to what I thought, a problem with the new launcher. This is a Java11/macOS problem.

Nico: Maybe I can somehow write my own launcher and stick it into bash profile or zshrc

Damien: if you want your own launcher, you can make something like that:

 #!/bin/sh
 
 /Applications/Protégé-560-beta.app/Contents/run.sh "$PWD/$1"

That is, bypass Apple’s open completely.

(Nico has confirmed, this works, but opens Protege in the foreground rather than detached mode, which is great for him (better access to logs) but may not be ideal for normal users.)

@gouttegd says:

Damien: To be clear: ranting aside, and while the problem would not exist if not for Apple’s idiosyncrasies, this is still a bug in Protégé. The fact that you could open file.owl with Protégé 5.5.0 means that Protégé 5.5.0 reacted correctly to Apple desktop events; the fact that Protégé 5.6.0 does not is undoubtedly a regression. Well, that’s very unlikely to be fixed anytime soon. As far as I understand, Protégé is doing The Right Thing by using the standard java.awt.Desktop API, instead of the (non-standard, deprecated, and simply not usable on Java >= 9) com.apple.eawt.Application class that we used before. Except that the setFileOpenHandler of that API simply does not seem to work. I tried building a very minimal Java application that basically does nothing except setting this handler, following exactly the API’s documentation… and the application never receives any “open file” event! The event handler is never called. On the net people seem to have complained about various problems with that API for several years…

So, I give up. I am now convinced that whatever the problem is, it is not in Protégé’s code. It’s either another Apple idiosyncrasy or a bug in the JRE, or maybe even both.

For the record: It seems that a possible solution would be to start, at the same time as the Protégé application itself, another program in parallel, that would run in the background for as long as Protégé is running. That helper daemon would solely be tasked with listening to Apple events (and so would have to be written in something else than Java, since apparently we can’t get those events from a Java program; most likely it would have to be written in ObjC or in Swift), and upon receiving a “open file” event it would have to somehow communicate that to the main Protégé process.

If anyone is willing to test that “solution”, be my guest. As for me, no way I am ever going to even consider that even further.

Saving as RDF/XML automatically appends the .rdf extension, but this is unfortunate for us.

When an extension is provided by the user (.xyz), Protege should not add additional extensions to the end.

@gouttegd can you create a milestone and add this issue to it?

I noticed that the Contens/Info.plist file looks quite a bit different from the old to the new. Did anyone try to do https://oboacademy.github.io/obook/howto/set-up-protege/#increase-memory-in-protege?

In particular, this stuff seems entirely missing:

<string>org.protege.osgi.framework.Launcher</string>
        <key>JVMClassPaths</key>
        <array>
            <string>bundles/guava.jar</string>
            <string>bundles/logback-classic.jar</string>
            <string>bundles/logback-core.jar</string>
            <string>bundles/slf4j-api.jar</string>
            <string>bin/org.apache.felix.main.jar</string>
            <string>bin/protege-launcher.jar</string>
            <string>bin/maven-artifact.jar</string>
        </array>
        <key>JVMVersion</key>
        <string>1.8+</string>
        <key>JVMOptions</key>
        <array>
            <string>-Dapple.laf.useScreenMenuBar=true</string>
            <string>-Xss16M</string>
            <string>-Xmx24G</string>
            <string>-Xdock:name=Protégé</string>
            <string>-DentityExpansionLimit=100000000</string>
            <string>-Dlogback.configurationFile=conf/logback.xml</string>
            <string>-Dfile.encoding=UTF-8</string>
            <string>-XX:CompileCommand=exclude,javax/swing/text/GlyphView,getBreakSpot</string>
        </array>
        <key>JVMArguments</key>
        <array/>
        <key>LauncherWorkingDirectory</key>
        <string>$APP_ROOT/Contents/Java</string>

Is this intended? Can we safely insert this stuff into Info.plist if we want to increase memory?

cc @gouttegd @hkir-dev