Loading large file in RDF/XML versus Functional Syntax format

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Loading large file in RDF/XML versus Functional Syntax format

samsontu
Hi,

Recently some University of Nebraska people contacted me with their SNOMED CT loading problem. SNOMED CT is a large medical ontology (192 MB file in functional syntax format). After they exported an inferred+asserted ontology (239 MB in functional syntax), they had problem reloading the inferred+asserted ontology in Protege

It turned out that saving the inferred+asserted ontology in RDF/XML format resulted in quick load in Protege (~2 minutes), even though RDF/XML is much more verbose.

I don’t know whether this difference has anything to do with Protege, or is a result of OWL API implementation (Protege uses OWL API to load and save ontologies). Just thought this is a useful tip for anyone working with large ontologies.

With best regards,
Samson
p.s. I do not encourage people to contact me directly with their problems. It just happened that I have a special relationship with a U. of Nebraska faculty.

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Loading large file in RDF/XML versus Functional Syntax format

Lorenz Buehmann

This is clearly an OWL API issue then. Not sure if Matthew, Ignazio or the other devs ever did some performance benchmarks for the parsers, but I can imagine that for RDF/XML they could at least benefit from existing XML parser stuff while for functional syntax they had to do it from scratch. Or via JavaCC.

Also, does it mean it never loaded with functional syntax or just much slower?

You could open a Github issue or maybe ask on the mailing list first.

On 26.02.20 00:27, Samson Tu wrote:
Hi,

Recently some University of Nebraska people contacted me with their SNOMED CT loading problem. SNOMED CT is a large medical ontology (192 MB file in functional syntax format). After they exported an inferred+asserted ontology (239 MB in functional syntax), they had problem reloading the inferred+asserted ontology in Protege

It turned out that saving the inferred+asserted ontology in RDF/XML format resulted in quick load in Protege (~2 minutes), even though RDF/XML is much more verbose.

I don’t know whether this difference has anything to do with Protege, or is a result of OWL API implementation (Protege uses OWL API to load and save ontologies). Just thought this is a useful tip for anyone working with large ontologies.

With best regards,
Samson
p.s. I do not encourage people to contact me directly with their problems. It just happened that I have a special relationship with a U. of Nebraska faculty.

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Loading large file in RDF/XML versus Functional Syntax format

Wynne, Robert (NIH/NLM/LHC) [C]

Which options were selected to export the inferred axioms?

Both syntax work for me if only Subclasses and Equivalent classes options are checked.

 

If other options are selected, a NumberFormatException occurs on save.

 

[owlapi.unsupportedMethod]OWL API reasoner method is not implemented: getSuperObjectProperties(OWLObjectPropertyExpression, boolean).

java.lang.NumberFormatException: For input string: "2016-01-11T13:41:15Z"

        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)

        at java.lang.Integer.parseInt(Integer.java:580)

        at java.lang.Integer.parseInt(Integer.java:615)

        at org.semanticweb.elk.owlapi.ElkReasoner.getReasonerVersion(ElkReasoner.java:638)

        at org.semanticweb.owlapi.util.InferredOntologyGenerator.fillOntology(InferredOntologyGenerator.java:139)

        at org.protege.editor.owl.ui.frame.InferredAxiomsFrameSection.refillInferred(InferredAxiomsFrameSection.java:67)

 

There are some constructs Elk doesn’t fully support.

 

Rob

 

From: Lorenz Buehmann <[hidden email]>
Sent: Wednesday, February 26, 2020 2:02 AM
To: [hidden email]
Subject: Re: [protege-user] Loading large file in RDF/XML versus Functional Syntax format

 

This is clearly an OWL API issue then. Not sure if Matthew, Ignazio or the other devs ever did some performance benchmarks for the parsers, but I can imagine that for RDF/XML they could at least benefit from existing XML parser stuff while for functional syntax they had to do it from scratch. Or via JavaCC.

Also, does it mean it never loaded with functional syntax or just much slower?

You could open a Github issue or maybe ask on the mailing list first.

On 26.02.20 00:27, Samson Tu wrote:

Hi,

 

Recently some University of Nebraska people contacted me with their SNOMED CT loading problem. SNOMED CT is a large medical ontology (192 MB file in functional syntax format). After they exported an inferred+asserted ontology (239 MB in functional syntax), they had problem reloading the inferred+asserted ontology in Protege

 

It turned out that saving the inferred+asserted ontology in RDF/XML format resulted in quick load in Protege (~2 minutes), even though RDF/XML is much more verbose.

 

I don’t know whether this difference has anything to do with Protege, or is a result of OWL API implementation (Protege uses OWL API to load and save ontologies). Just thought this is a useful tip for anyone working with large ontologies.

 

With best regards,

Samson

p.s. I do not encourage people to contact me directly with their problems. It just happened that I have a special relationship with a U. of Nebraska faculty.



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Loading large file in RDF/XML versus Functional Syntax format

samsontu
The inferred ontology was exported with the option to include subclass/equivalence class axioms, plus existing asserted logical axioms and annotations.

What is curious is that the source ontology, which is almost as big as the exported inferred ontology, is also in functional syntax, but Protege loads it without any problem.

I’ll post a query on the OWL mailing list if I get the permission to forward these files.

With best regards,
Samson


On Feb 26, 2020, at 11:33 AM, Wynne, Robert (NIH/NLM/LHC) [C] <[hidden email]> wrote:

Which options were selected to export the inferred axioms?
Both syntax work for me if only Subclasses and Equivalent classes options are checked.
 
If other options are selected, a NumberFormatException occurs on save.
 
[owlapi.unsupportedMethod]OWL API reasoner method is not implemented: getSuperObjectProperties(OWLObjectPropertyExpression, boolean).
java.lang.NumberFormatException: For input string: "2016-01-11T13:41:15Z"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:580)
        at java.lang.Integer.parseInt(Integer.java:615)
        at org.semanticweb.elk.owlapi.ElkReasoner.getReasonerVersion(ElkReasoner.java:638)
        at org.semanticweb.owlapi.util.InferredOntologyGenerator.fillOntology(InferredOntologyGenerator.java:139)
        at org.protege.editor.owl.ui.frame.InferredAxiomsFrameSection.refillInferred(InferredAxiomsFrameSection.java:67)
 
There are some constructs Elk doesn’t fully support.
 
Rob
 
From: Lorenz Buehmann <[hidden email]> 
Sent: Wednesday, February 26, 2020 2:02 AM
To: [hidden email]
Subject: Re: [protege-user] Loading large file in RDF/XML versus Functional Syntax format
 

This is clearly an OWL API issue then. Not sure if Matthew, Ignazio or the other devs ever did some performance benchmarks for the parsers, but I can imagine that for RDF/XML they could at least benefit from existing XML parser stuff while for functional syntax they had to do it from scratch. Or via JavaCC.

Also, does it mean it never loaded with functional syntax or just much slower?

You could open a Github issue or maybe ask on the mailing list first.

On 26.02.20 00:27, Samson Tu wrote:
Hi, 
 
Recently some University of Nebraska people contacted me with their SNOMED CT loading problem. SNOMED CT is a large medical ontology (192 MB file in functional syntax format). After they exported an inferred+asserted ontology (239 MB in functional syntax), they had problem reloading the inferred+asserted ontology in Protege
 
It turned out that saving the inferred+asserted ontology in RDF/XML format resulted in quick load in Protege (~2 minutes), even though RDF/XML is much more verbose.
 
I don’t know whether this difference has anything to do with Protege, or is a result of OWL API implementation (Protege uses OWL API to load and save ontologies). Just thought this is a useful tip for anyone working with large ontologies.
 
With best regards,
Samson
p.s. I do not encourage people to contact me directly with their problems. It just happened that I have a special relationship with a U. of Nebraska faculty.


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Loading large file in RDF/XML versus Functional Syntax format

Lorenz Buehmann

You could also check without Protege by just using some small OWL API Java code. This would at least make sure if Protege itself is not involved in this issue.

Also, with functional syntax it never finishes?

On 27.02.20 06:23, Samson Tu wrote:
The inferred ontology was exported with the option to include subclass/equivalence class axioms, plus existing asserted logical axioms and annotations.

What is curious is that the source ontology, which is almost as big as the exported inferred ontology, is also in functional syntax, but Protege loads it without any problem.

I’ll post a query on the OWL mailing list if I get the permission to forward these files.

With best regards,
Samson


On Feb 26, 2020, at 11:33 AM, Wynne, Robert (NIH/NLM/LHC) [C] <[hidden email]> wrote:

Which options were selected to export the inferred axioms?
Both syntax work for me if only Subclasses and Equivalent classes options are checked.
 
If other options are selected, a NumberFormatException occurs on save.
 
[owlapi.unsupportedMethod]OWL API reasoner method is not implemented: getSuperObjectProperties(OWLObjectPropertyExpression, boolean).
java.lang.NumberFormatException: For input string: "2016-01-11T13:41:15Z"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:580)
        at java.lang.Integer.parseInt(Integer.java:615)
        at org.semanticweb.elk.owlapi.ElkReasoner.getReasonerVersion(ElkReasoner.java:638)
        at org.semanticweb.owlapi.util.InferredOntologyGenerator.fillOntology(InferredOntologyGenerator.java:139)
        at org.protege.editor.owl.ui.frame.InferredAxiomsFrameSection.refillInferred(InferredAxiomsFrameSection.java:67)
 
There are some constructs Elk doesn’t fully support.
 
Rob
 
From: Lorenz Buehmann <[hidden email]> 
Sent: Wednesday, February 26, 2020 2:02 AM
To: [hidden email]
Subject: Re: [protege-user] Loading large file in RDF/XML versus Functional Syntax format
 

This is clearly an OWL API issue then. Not sure if Matthew, Ignazio or the other devs ever did some performance benchmarks for the parsers, but I can imagine that for RDF/XML they could at least benefit from existing XML parser stuff while for functional syntax they had to do it from scratch. Or via JavaCC.

Also, does it mean it never loaded with functional syntax or just much slower?

You could open a Github issue or maybe ask on the mailing list first.

On 26.02.20 00:27, Samson Tu wrote:
Hi, 
 
Recently some University of Nebraska people contacted me with their SNOMED CT loading problem. SNOMED CT is a large medical ontology (192 MB file in functional syntax format). After they exported an inferred+asserted ontology (239 MB in functional syntax), they had problem reloading the inferred+asserted ontology in Protege
 
It turned out that saving the inferred+asserted ontology in RDF/XML format resulted in quick load in Protege (~2 minutes), even though RDF/XML is much more verbose.
 
I don’t know whether this difference has anything to do with Protege, or is a result of OWL API implementation (Protege uses OWL API to load and save ontologies). Just thought this is a useful tip for anyone working with large ontologies.
 
With best regards,
Samson
p.s. I do not encourage people to contact me directly with their problems. It just happened that I have a special relationship with a U. of Nebraska faculty.


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Loading large file in RDF/XML versus Functional Syntax format

Lorenz Buehmann
In reply to this post by Wynne, Robert (NIH/NLM/LHC) [C]

That's an odd exception but it looks like you're using an older version, because in the Github code this already addressed [1] and fixed 2 years ago [2]. You should update the ELK reasoner.


And yes, ELK reasoner doesn't implement all OWL API methods, e.g. object property domains/ranges and others aren't implemented, see [3]


[1] https://github.com/liveontologies/elk-reasoner/blob/master/elk-owlapi-parent/elk-owlapi4/src/main/java/org/semanticweb/elk/owlapi/ElkReasoner.java#L694-L718
[2] https://github.com/liveontologies/elk-reasoner/issues/49
[3] https://github.com/liveontologies/elk-reasoner/blob/master/elk-owlapi-parent/elk-owlapi4/src/main/java/org/semanticweb/elk/owlapi/ElkReasoner.java

On 26.02.20 20:33, Wynne, Robert (NIH/NLM/LHC) [C] wrote:

Which options were selected to export the inferred axioms?

Both syntax work for me if only Subclasses and Equivalent classes options are checked.

 

If other options are selected, a NumberFormatException occurs on save.

 

[owlapi.unsupportedMethod]OWL API reasoner method is not implemented: getSuperObjectProperties(OWLObjectPropertyExpression, boolean).

java.lang.NumberFormatException: For input string: "2016-01-11T13:41:15Z"

        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)

        at java.lang.Integer.parseInt(Integer.java:580)

        at java.lang.Integer.parseInt(Integer.java:615)

        at org.semanticweb.elk.owlapi.ElkReasoner.getReasonerVersion(ElkReasoner.java:638)

        at org.semanticweb.owlapi.util.InferredOntologyGenerator.fillOntology(InferredOntologyGenerator.java:139)

        at org.protege.editor.owl.ui.frame.InferredAxiomsFrameSection.refillInferred(InferredAxiomsFrameSection.java:67)

 

There are some constructs Elk doesn’t fully support.

 

Rob

 

From: Lorenz Buehmann [hidden email]
Sent: Wednesday, February 26, 2020 2:02 AM
To: [hidden email]
Subject: Re: [protege-user] Loading large file in RDF/XML versus Functional Syntax format

 

This is clearly an OWL API issue then. Not sure if Matthew, Ignazio or the other devs ever did some performance benchmarks for the parsers, but I can imagine that for RDF/XML they could at least benefit from existing XML parser stuff while for functional syntax they had to do it from scratch. Or via JavaCC.

Also, does it mean it never loaded with functional syntax or just much slower?

You could open a Github issue or maybe ask on the mailing list first.

On 26.02.20 00:27, Samson Tu wrote:

Hi,

 

Recently some University of Nebraska people contacted me with their SNOMED CT loading problem. SNOMED CT is a large medical ontology (192 MB file in functional syntax format). After they exported an inferred+asserted ontology (239 MB in functional syntax), they had problem reloading the inferred+asserted ontology in Protege

 

It turned out that saving the inferred+asserted ontology in RDF/XML format resulted in quick load in Protege (~2 minutes), even though RDF/XML is much more verbose.

 

I don’t know whether this difference has anything to do with Protege, or is a result of OWL API implementation (Protege uses OWL API to load and save ontologies). Just thought this is a useful tip for anyone working with large ontologies.

 

With best regards,

Samson

p.s. I do not encourage people to contact me directly with their problems. It just happened that I have a special relationship with a U. of Nebraska faculty.



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Loading large file in RDF/XML versus Functional Syntax format

Campbell, James R
In reply to this post by samsontu

Samson

I don’t mind sharing the files but they do contain SNOMED CT which is copyright and should probably only be made accessible to those with a UMLS license.  Can we verify that will be the case?  If not, I don’t think we should

Jim

 

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Wednesday, February 26, 2020 11:26 PM
To: [hidden email]
Subject: Re: [protege-user] Loading large file in RDF/XML versus Functional Syntax format

 

Non-UNMC email

The inferred ontology was exported with the option to include subclass/equivalence class axioms, plus existing asserted logical axioms and annotations.

 

What is curious is that the source ontology, which is almost as big as the exported inferred ontology, is also in functional syntax, but Protege loads it without any problem.

 

I’ll post a query on the OWL mailing list if I get the permission to forward these files.

 

With best regards,

Samson

 



On Feb 26, 2020, at 11:33 AM, Wynne, Robert (NIH/NLM/LHC) [C] <[hidden email]> wrote:

 

Which options were selected to export the inferred axioms?

Both syntax work for me if only Subclasses and Equivalent classes options are checked.

 

If other options are selected, a NumberFormatException occurs on save.

 

[owlapi.unsupportedMethod]OWL API reasoner method is not implemented: getSuperObjectProperties(OWLObjectPropertyExpression, boolean).

java.lang.NumberFormatException: For input string: "2016-01-11T13:41:15Z"

        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)

        at java.lang.Integer.parseInt(Integer.java:580)

        at java.lang.Integer.parseInt(Integer.java:615)

        at org.semanticweb.elk.owlapi.ElkReasoner.getReasonerVersion(ElkReasoner.java:638)

        at org.semanticweb.owlapi.util.InferredOntologyGenerator.fillOntology(InferredOntologyGenerator.java:139)

        at org.protege.editor.owl.ui.frame.InferredAxiomsFrameSection.refillInferred(InferredAxiomsFrameSection.java:67)

 

There are some constructs Elk doesn’t fully support.

 

Rob

 

From: Lorenz Buehmann <[hidden email]> 
Sent: Wednesday, February 26, 2020 2:02 AM
To: [hidden email]
Subject: Re: [protege-user] Loading large file in RDF/XML versus Functional Syntax format

 

This is clearly an OWL API issue then. Not sure if Matthew, Ignazio or the other devs ever did some performance benchmarks for the parsers, but I can imagine that for RDF/XML they could at least benefit from existing XML parser stuff while for functional syntax they had to do it from scratch. Or via JavaCC.

Also, does it mean it never loaded with functional syntax or just much slower?

You could open a Github issue or maybe ask on the mailing list first.

On 26.02.20 00:27, Samson Tu wrote:

Hi, 

 

Recently some University of Nebraska people contacted me with their SNOMED CT loading problem. SNOMED CT is a large medical ontology (192 MB file in functional syntax format). After they exported an inferred+asserted ontology (239 MB in functional syntax), they had problem reloading the inferred+asserted ontology in Protege

 

It turned out that saving the inferred+asserted ontology in RDF/XML format resulted in quick load in Protege (~2 minutes), even though RDF/XML is much more verbose.

 

I don’t know whether this difference has anything to do with Protege, or is a result of OWL API implementation (Protege uses OWL API to load and save ontologies). Just thought this is a useful tip for anyone working with large ontologies.

 

With best regards,

Samson

p.s. I do not encourage people to contact me directly with their problems. It just happened that I have a special relationship with a U. of Nebraska faculty.




_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user [mailman.stanford.edu]

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user [mailman.stanford.edu]

 

 


The information in this e-mail may be privileged and confidential, intended only for the use of the addressee(s) above. Any unauthorized use or disclosure of this information is prohibited. If you have received this e-mail by mistake, please delete it and immediately contact the sender.
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Loading large file in RDF/XML versus Functional Syntax format

Wynne, Robert (NIH/NLM/LHC) [C]
In reply to this post by Lorenz Buehmann

I’m using the official Elk 0.4.3 [1] release with Protégé 5.5.0 on Windows with a max heap of 15g.

Is there another version of Elk would I replace the jar with that will work with Protégé?

 

Samson from your previous response, yes I had the first two options checked, as well as the following two you mention.

Both syntax saved and did not exhibit a round-trip issue.

 

[1] https://github.com/liveontologies/elk-reasoner/wiki

 

Rob

 

From: Lorenz Buehmann <[hidden email]>
Sent: Thursday, February 27, 2020 2:08 AM
To: [hidden email]
Subject: Re: [protege-user] Loading large file in RDF/XML versus Functional Syntax format

 

That's an odd exception but it looks like you're using an older version, because in the Github code this already addressed [1] and fixed 2 years ago [2]. You should update the ELK reasoner.

 

And yes, ELK reasoner doesn't implement all OWL API methods, e.g. object property domains/ranges and others aren't implemented, see [3]

 

[1] https://github.com/liveontologies/elk-reasoner/blob/master/elk-owlapi-parent/elk-owlapi4/src/main/java/org/semanticweb/elk/owlapi/ElkReasoner.java#L694-L718
[2] https://github.com/liveontologies/elk-reasoner/issues/49
[3] https://github.com/liveontologies/elk-reasoner/blob/master/elk-owlapi-parent/elk-owlapi4/src/main/java/org/semanticweb/elk/owlapi/ElkReasoner.java

On 26.02.20 20:33, Wynne, Robert (NIH/NLM/LHC) [C] wrote:

Which options were selected to export the inferred axioms?

Both syntax work for me if only Subclasses and Equivalent classes options are checked.

 

If other options are selected, a NumberFormatException occurs on save.

 

[owlapi.unsupportedMethod]OWL API reasoner method is not implemented: getSuperObjectProperties(OWLObjectPropertyExpression, boolean).

java.lang.NumberFormatException: For input string: "2016-01-11T13:41:15Z"

        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)

        at java.lang.Integer.parseInt(Integer.java:580)

        at java.lang.Integer.parseInt(Integer.java:615)

        at org.semanticweb.elk.owlapi.ElkReasoner.getReasonerVersion(ElkReasoner.java:638)

        at org.semanticweb.owlapi.util.InferredOntologyGenerator.fillOntology(InferredOntologyGenerator.java:139)

        at org.protege.editor.owl.ui.frame.InferredAxiomsFrameSection.refillInferred(InferredAxiomsFrameSection.java:67)

 

There are some constructs Elk doesn’t fully support.

 

Rob

 

From: Lorenz Buehmann [hidden email]
Sent: Wednesday, February 26, 2020 2:02 AM
To: [hidden email]
Subject: Re: [protege-user] Loading large file in RDF/XML versus Functional Syntax format

 

This is clearly an OWL API issue then. Not sure if Matthew, Ignazio or the other devs ever did some performance benchmarks for the parsers, but I can imagine that for RDF/XML they could at least benefit from existing XML parser stuff while for functional syntax they had to do it from scratch. Or via JavaCC.

Also, does it mean it never loaded with functional syntax or just much slower?

You could open a Github issue or maybe ask on the mailing list first.

On 26.02.20 00:27, Samson Tu wrote:

Hi,

 

Recently some University of Nebraska people contacted me with their SNOMED CT loading problem. SNOMED CT is a large medical ontology (192 MB file in functional syntax format). After they exported an inferred+asserted ontology (239 MB in functional syntax), they had problem reloading the inferred+asserted ontology in Protege

 

It turned out that saving the inferred+asserted ontology in RDF/XML format resulted in quick load in Protege (~2 minutes), even though RDF/XML is much more verbose.

 

I don’t know whether this difference has anything to do with Protege, or is a result of OWL API implementation (Protege uses OWL API to load and save ontologies). Just thought this is a useful tip for anyone working with large ontologies.

 

With best regards,

Samson

p.s. I do not encourage people to contact me directly with their problems. It just happened that I have a special relationship with a U. of Nebraska faculty.




_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user