[Re: Re: existentials and the OWLThing built-in [Re: Re: SWRL doubt: using rules to add new individuals? (Samson Tu)] (Martin O'Connor)

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

[Re: Re: existentials and the OWLThing built-in [Re: Re: SWRL doubt: using rules to add new individuals? (Samson Tu)] (Martin O'Connor)

Nacho Mayorga-2
Hi, Martin,

thanks a lot for your answer. Is there any workaround that you know of? Should I add the instances calling the API and, then, the reasoner instead of using SWRL?

Thanks again,

                              Nacho

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: [Re: Re: existentials and the OWLThing built-in [Re:Re: SWRL doubt: using rules to add new individuals? (SamsonTu)] (Martin O'Connor)

Martin O'Connor

I don’t know what the context is here. Workaround for what?

 

Martin

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Nacho Mayorga
Sent: Friday, September 07, 2007 4:19 AM
To: [hidden email]
Subject: [protege-owl] [Re: Re: existentials and the OWLThing built-in [Re:Re: SWRL doubt: using rules to add new individuals? (SamsonTu)] (Martin O'Connor)

 

Hi, Martin,

thanks a lot for your answer. Is there any workaround that you know of? Should I add the instances calling the API and, then, the reasoner instead of using SWRL?

Thanks again,

                              Nacho

--
Nacho Mayorga


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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Load multiple files into one model sequentially

Tom Gitzinger
Hi everyone,

I have a set of similar files (let's call it S) that all import the same
two upper ontology files, and up to now I have been doing this:

 JenaOWLModel result = ProtegeOWL.createJenaOWLModel();
 // The importing file, represented by f (File)
 URI uri = URIUtilities.createURI(f.getAbsolutePath());
 // The imported files (all in one directory)
 File repositoryFolder = new File(pathToFolder);
 result.getRepositoryManager().addProjectRepository(
          new LocalFolderRepository(repositoryFolder));
               
 result.load(uri, Utils.langXMLAbbrev);

This works fine. However, what I would like is a model containing *all*
the data contained in S. Is there a way to iteratively add new contents
from a repository to a JenaOWLModel? It is my understanding that load()
"overwrites" the current model contents.

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Load multiple files into one model sequentially

Tania Tudorache
Tom,

I am not sure I understood exactly your question, but there is a way to
add imports at runtime using the API. This is described on this wiki page:

http://protege.cim3.net/cgi-bin/wiki.pl?HowToImport

The imports use the repository mechanism, so if some (or all) the
imported ontologies have a repository entry defined, they will be loaded
from the corresponding repository.

Cheers,
Tania



Tom Gitzinger wrote:

> Hi everyone,
>
> I have a set of similar files (let's call it S) that all import the same
> two upper ontology files, and up to now I have been doing this:
>
>  JenaOWLModel result = ProtegeOWL.createJenaOWLModel();
>  // The importing file, represented by f (File)
>  URI uri = URIUtilities.createURI(f.getAbsolutePath());
>  // The imported files (all in one directory)
>  File repositoryFolder = new File(pathToFolder);
>  result.getRepositoryManager().addProjectRepository(
>           new LocalFolderRepository(repositoryFolder));
>
>  result.load(uri, Utils.langXMLAbbrev);
>
> This works fine. However, what I would like is a model containing *all*
> the data contained in S. Is there a way to iteratively add new contents
> from a repository to a JenaOWLModel? It is my understanding that load()
> "overwrites" the current model contents.
>
> Thanks
> Tom
> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
>
>  

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Overriding automatic sorting in Protégé sibling classes

Alan March
Every time an owl ontology is loaded by Protégé, sibling classes are
automatically sorted in alphabetical order. While I am aware that this may
be an advantage in some cases, is there some way to override this behaviour?
The fact is that when building an ontology, I usually create extensive lists
of sibling classes in order to let the reasoner do the job of organizing
them into proper hierarchies. The problem here is that the order in which I
entered the classes is of value to me as a sort of visual hint for new
classes I might need to build, or simply for the sake of finding them
quickly within "logical groupings". Curiously, when using the DB backend,
this doesn't ocurr, but I have found it difficult to use the DB backend due
to its slow response when scrolling across extensive lists of sibling
classes.

Ideally, it would be great if automatic sorting where configurable for OWL
files, but I guess that maybe not be a priority for the Protégé team. So, if
someone could instruct me as to how to override this behaviour, I would be
most grateful.

Alan


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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Load multiple files into one model sequentially

Tom Gitzinger
In reply to this post by Tania Tudorache
Hi Tania,

I think this is what I need. Thanks a lot.
Tom

Tania Tudorache wrote:

> Tom,
>
> I am not sure I understood exactly your question, but there is a way to
> add imports at runtime using the API. This is described on this wiki page:
>
> http://protege.cim3.net/cgi-bin/wiki.pl?HowToImport
>
> The imports use the repository mechanism, so if some (or all) the
> imported ontologies have a repository entry defined, they will be loaded
> from the corresponding repository.
>
> Cheers,
> Tania
>
>
>
> Tom Gitzinger wrote:
>> Hi everyone,
>>
>> I have a set of similar files (let's call it S) that all import the same
>> two upper ontology files, and up to now I have been doing this:
>>
>>  JenaOWLModel result = ProtegeOWL.createJenaOWLModel();
>>  // The importing file, represented by f (File)
>>  URI uri = URIUtilities.createURI(f.getAbsolutePath());
>>  // The imported files (all in one directory)
>>  File repositoryFolder = new File(pathToFolder);
>>  result.getRepositoryManager().addProjectRepository(
>>           new LocalFolderRepository(repositoryFolder));
>>
>>  result.load(uri, Utils.langXMLAbbrev);
>>
>> This works fine. However, what I would like is a model containing *all*
>> the data contained in S. Is there a way to iteratively add new contents
>> from a repository to a JenaOWLModel? It is my understanding that load()
>> "overwrites" the current model contents.
>>
>> Thanks
>> Tom
>> _______________________________________________
>> protege-owl mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>
>> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
>>
>>  
>
> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Overriding automatic sorting in Protégé sibling classes

Tania Tudorache
In reply to this post by Alan March
Hi Alan,

I am not sure I understand exactly what it means to maintain the
creation order for class siblings. Does this mean that you would like to
preserve the order across different sessions, i.e. you create some
classes, save, close the project and reload, and then you would like to
see the same order for the siblings as the one in in the original session?

This case is very difficult. Because there are many processes involved
that do not have the notion of order in them: for instance, the parser
is a streaming parser and it creates all the entities on the fly and
does a lot post processing, which makes it impossible to preserver the
order. We also don't have control on the way the OWL file is written
out, because that is handled by Jena. The Protege-OWL to Jena conversion
does not have the notion of order, either.

There is indeed a sorting step after the parsing of the triples, and it
is easy to make that configurable, but even if the sorting will be
disabled, it won't help, beacuse there is no guarantee on the order of
classes that you will get.

I am wondering if you tried out the OWL database backend that is
available in the latest release (3.3.1). We have improved the
performance a lot compared to previous versions and this might help with
the scrolling problem. The database backend preserves the order of
creation because there is no parsing, transformation and saving
operations involved.

Cheers,
Tania


Alan March wrote:

> Every time an owl ontology is loaded by Protégé, sibling classes are
> automatically sorted in alphabetical order. While I am aware that this may
> be an advantage in some cases, is there some way to override this behaviour?
> The fact is that when building an ontology, I usually create extensive lists
> of sibling classes in order to let the reasoner do the job of organizing
> them into proper hierarchies. The problem here is that the order in which I
> entered the classes is of value to me as a sort of visual hint for new
> classes I might need to build, or simply for the sake of finding them
> quickly within "logical groupings". Curiously, when using the DB backend,
> this doesn't ocurr, but I have found it difficult to use the DB backend due
> to its slow response when scrolling across extensive lists of sibling
> classes.
>
> Ideally, it would be great if automatic sorting where configurable for OWL
> files, but I guess that maybe not be a priority for the Protégé team. So, if
> someone could instruct me as to how to override this behaviour, I would be
> most grateful.
>
> Alan
>
>
> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
>
>  

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Overriding automatic sorting in Protégé sibling classes

Thomas Russ

On Sep 12, 2007, at 9:26 AM, Tania Tudorache wrote:

> There is indeed a sorting step after the parsing of the triples,  
> and it
> is easy to make that configurable, but even if the sorting will be
> disabled, it won't help, beacuse there is no guarantee on the order of
> classes that you will get.

Wouldn't it be possible to use the creation date / time annotation
for sorting by order of creation?  Isn't there some support for
automatically recording that in Protege?  Or is that only for the
frames version?


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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Overriding automatic sorting in Protégé sibling classes

Alan March
In reply to this post by Tania Tudorache
> Hi Alan,
>
> I am not sure I understand exactly what it means to maintain
> the creation order for class siblings. Does this mean that
> you would like to preserve the order across different
> sessions, i.e. you create some classes, save, close the
> project and reload, and then you would like to see the same
> order for the siblings as the one in in the original session?

Right!

>
> This case is very difficult. Because there are many processes
> involved that do not have the notion of order in them: for
> instance, the parser is a streaming parser and it creates all
> the entities on the fly and does a lot post processing, which
> makes it impossible to preserver the order. We also don't
> have control on the way the OWL file is written out, because
> that is handled by Jena. The Protege-OWL to Jena conversion
> does not have the notion of order, either.
>
> There is indeed a sorting step after the parsing of the
> triples, and it is easy to make that configurable, but even
> if the sorting will be disabled, it won't help, beacuse there
> is no guarantee on the order of classes that you will get.

Yes..I guessed that. Could you please point me out the parts of the code
which do the sorting, in order I might try out what would happen if I anull
the sorting?

>
> I am wondering if you tried out the OWL database backend that
> is available in the latest release (3.3.1). We have improved
> the performance a lot compared to previous versions and this
> might help with the scrolling problem. The database backend
> preserves the order of creation because there is no parsing,
> transformation and saving operations involved.

I had noticed this property of the DB backend, but no..in fact I haven't
tried the new version but I will, given your comment (I had lost hopes with
previous versions of the DB backend, but this comment of yours is
stimulating...I'll report back). In that line of discussion: is there any
specific DB you would recommend as particularly efficient? Have you done any
benchmarking? I once tried to use SQLite (it's single user, which would
theoretically do away with the overhead of multiuser management), but could
not get the JDBC driver to work -apparently something related to BLOBs-.

> Cheers,
> Tania
>

Many thanks, Tania!

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Overriding automatic sorting in Protégé sibling classes

Tania Tudorache
In reply to this post by Thomas Russ
Hi Thomas,

Thomas Russ wrote:

> On Sep 12, 2007, at 9:26 AM, Tania Tudorache wrote:
>
>  
>> There is indeed a sorting step after the parsing of the triples,  
>> and it
>> is easy to make that configurable, but even if the sorting will be
>> disabled, it won't help, beacuse there is no guarantee on the order of
>> classes that you will get.
>>    
>
> Wouldn't it be possible to use the creation date / time annotation
> for sorting by order of creation?  Isn't there some support for
> automatically recording that in Protege?  Or is that only for the
> frames version?
>  

Unfortunately this works currently only in frames. We could make it work
in OWL, too, but this would mean that all OWL entities will have extra
annotation properties attached to them (e.g. timestamp, creator,
modifier, etc.) and they would be part of the ontology. And this might
be more or less desirable, because the size of the ontology would be
much larger due to the annotations.

However, there is another solution: If the ChangesTab plugin would be
activated, all the changes in the main ontology would be tracked and
saved as instances of a change&annotation ontology. When loading the
ontology, one could sort the classes according to the information stored
in the changes ontology.

Cheers,
Tania



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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Overriding automatic sorting in Protégé sibling classes

Tania Tudorache
In reply to this post by Alan March
Hi Alan,

The sorting takes place in the load methods of
edu.stanford.smi.protegex.owl.jena.JenaOWLModel. This is one of the load
methods:

public void load(URI uri, String language) throws Exception {
   ProtegeOWLParser parser = new ProtegeOWLParser(this, false);
   parser.run(uri);
   TripleStoreUtil.sortSubclasses(this);
   copyFacetValuesIntoNamedClses();
}


It is easy to write your own loading method that would be similar to the
above one, but it would leave out the call to
TripleStoreUtil.sortSubclasses(this).

Good luck!
Tania




Alan March wrote:

>> Hi Alan,
>>
>> I am not sure I understand exactly what it means to maintain
>> the creation order for class siblings. Does this mean that
>> you would like to preserve the order across different
>> sessions, i.e. you create some classes, save, close the
>> project and reload, and then you would like to see the same
>> order for the siblings as the one in in the original session?
>>    
>
> Right!
>
>  
>> This case is very difficult. Because there are many processes
>> involved that do not have the notion of order in them: for
>> instance, the parser is a streaming parser and it creates all
>> the entities on the fly and does a lot post processing, which
>> makes it impossible to preserver the order. We also don't
>> have control on the way the OWL file is written out, because
>> that is handled by Jena. The Protege-OWL to Jena conversion
>> does not have the notion of order, either.
>>
>> There is indeed a sorting step after the parsing of the
>> triples, and it is easy to make that configurable, but even
>> if the sorting will be disabled, it won't help, beacuse there
>> is no guarantee on the order of classes that you will get.
>>    
>
> Yes..I guessed that. Could you please point me out the parts of the code
> which do the sorting, in order I might try out what would happen if I anull
> the sorting?
>
>  
>> I am wondering if you tried out the OWL database backend that
>> is available in the latest release (3.3.1). We have improved
>> the performance a lot compared to previous versions and this
>> might help with the scrolling problem. The database backend
>> preserves the order of creation because there is no parsing,
>> transformation and saving operations involved.
>>    
>
> I had noticed this property of the DB backend, but no..in fact I haven't
> tried the new version but I will, given your comment (I had lost hopes with
> previous versions of the DB backend, but this comment of yours is
> stimulating...I'll report back). In that line of discussion: is there any
> specific DB you would recommend as particularly efficient? Have you done any
> benchmarking? I once tried to use SQLite (it's single user, which would
> theoretically do away with the overhead of multiuser management), but could
> not get the JDBC driver to work -apparently something related to BLOBs-.
>
>  
>> Cheers,
>> Tania
>>
>>    
>
> Many thanks, Tania!
>
>
>  

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Overriding automatic sorting in Protégé sibling classes

Wacek Kusnierczyk
Tania Tudorache wrote:

> Hi Alan,
>
> The sorting takes place in the load methods of
> edu.stanford.smi.protegex.owl.jena.JenaOWLModel. This is one of the load
> methods:
>
> public void load(URI uri, String language) throws Exception {
>    ProtegeOWLParser parser = new ProtegeOWLParser(this, false);
>    parser.run(uri);
>    TripleStoreUtil.sortSubclasses(this);
>    copyFacetValuesIntoNamedClses();
> }
>  
What's the purpose of the second parameter?

vQ

>
> It is easy to write your own loading method that would be similar to the
> above one, but it would leave out the call to
> TripleStoreUtil.sortSubclasses(this).
>
> Good luck!
> Tania
>
>
>
>
> Alan March wrote:
>  
>>> Hi Alan,
>>>
>>> I am not sure I understand exactly what it means to maintain
>>> the creation order for class siblings. Does this mean that
>>> you would like to preserve the order across different
>>> sessions, i.e. you create some classes, save, close the
>>> project and reload, and then you would like to see the same
>>> order for the siblings as the one in in the original session?
>>>    
>>>      
>> Right!
>>
>>  
>>    
>>> This case is very difficult. Because there are many processes
>>> involved that do not have the notion of order in them: for
>>> instance, the parser is a streaming parser and it creates all
>>> the entities on the fly and does a lot post processing, which
>>> makes it impossible to preserver the order. We also don't
>>> have control on the way the OWL file is written out, because
>>> that is handled by Jena. The Protege-OWL to Jena conversion
>>> does not have the notion of order, either.
>>>
>>> There is indeed a sorting step after the parsing of the
>>> triples, and it is easy to make that configurable, but even
>>> if the sorting will be disabled, it won't help, beacuse there
>>> is no guarantee on the order of classes that you will get.
>>>    
>>>      
>> Yes..I guessed that. Could you please point me out the parts of the code
>> which do the sorting, in order I might try out what would happen if I anull
>> the sorting?
>>
>>  
>>    
>>> I am wondering if you tried out the OWL database backend that
>>> is available in the latest release (3.3.1). We have improved
>>> the performance a lot compared to previous versions and this
>>> might help with the scrolling problem. The database backend
>>> preserves the order of creation because there is no parsing,
>>> transformation and saving operations involved.
>>>    
>>>      
>> I had noticed this property of the DB backend, but no..in fact I haven't
>> tried the new version but I will, given your comment (I had lost hopes with
>> previous versions of the DB backend, but this comment of yours is
>> stimulating...I'll report back). In that line of discussion: is there any
>> specific DB you would recommend as particularly efficient? Have you done any
>> benchmarking? I once tried to use SQLite (it's single user, which would
>> theoretically do away with the overhead of multiuser management), but could
>> not get the JDBC driver to work -apparently something related to BLOBs-.
>>
>>  
>>    
>>> Cheers,
>>> Tania
>>>
>>>    
>>>      
>> Many thanks, Tania!
>>
>>
>>  
>>    
>
> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
>  

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Overriding automatic sorting in Protégé sibling classes

Tania Tudorache
Hi Wacek,

Wacek Kusnierczyk wrote:

> Tania Tudorache wrote:
>> Hi Alan,
>>
>> The sorting takes place in the load methods of
>> edu.stanford.smi.protegex.owl.jena.JenaOWLModel. This is one of the
>> load methods:
>>
>> public void load(URI uri, String language) throws Exception {
>>    ProtegeOWLParser parser = new ProtegeOWLParser(this, false);
>>    parser.run(uri);
>>    TripleStoreUtil.sortSubclasses(this);
>>    copyFacetValuesIntoNamedClses();
>> }
>>  
> What's the purpose of the second parameter?
>

That is a flag that instructs the parser to populate a map of the
untyped resources, so that you can reference them from the ontology.
Normally, all entities in the ontology should have a type defined
(either in the current ontology or one of imported ontologies),
otherwise the parser does not know what type of Java object to create
for them. The support for external resources (referenced but untyped
entities) is not very good in Protege right now, but we plan to improve
it in future. So, I think for now,  it is better to set the second
argument to the ProtegeOWLParser constructor to false.

I have attached below the lines of code Alan could use to load an
ontology without sorting it:


URI uri = URIUtilities.createURI("file:///tmp/ont.owl");
JenaOWLModel owlModel = ProtegeOWL.createJenaOWLModel();
           
ProtegeOWLParser parser = new ProtegeOWLParser(owlModel, false);
parser.run(uri);
 owlModel.copyFacetValuesIntoNamedClses();


Cheers,
Tania

> vQ
>
>>
>> It is easy to write your own loading method that would be similar to
>> the above one, but it would leave out the call to
>> TripleStoreUtil.sortSubclasses(this).
>>
>> Good luck!
>> Tania
>>
>>
>>
>>
>> Alan March wrote:
>>  
>>>> Hi Alan,
>>>>
>>>> I am not sure I understand exactly what it means to maintain the
>>>> creation order for class siblings. Does this mean that you would
>>>> like to preserve the order across different sessions, i.e. you
>>>> create some classes, save, close the project and reload, and then
>>>> you would like to see the same order for the siblings as the one in
>>>> in the original session?
>>>>          
>>> Right!
>>>
>>>      
>>>> This case is very difficult. Because there are many processes
>>>> involved that do not have the notion of order in them: for
>>>> instance, the parser is a streaming parser and it creates all the
>>>> entities on the fly and does a lot post processing, which makes it
>>>> impossible to preserver the order. We also don't have control on
>>>> the way the OWL file is written out, because that is handled by
>>>> Jena. The Protege-OWL to Jena conversion does not have the notion
>>>> of order, either.
>>>>
>>>> There is indeed a sorting step after the parsing of the triples,
>>>> and it is easy to make that configurable, but even if the sorting
>>>> will be disabled, it won't help, beacuse there is no guarantee on
>>>> the order of classes that you will get.
>>>>          
>>> Yes..I guessed that. Could you please point me out the parts of the
>>> code
>>> which do the sorting, in order I might try out what would happen if
>>> I anull
>>> the sorting?
>>>      
>>>> I am wondering if you tried out the OWL database backend that is
>>>> available in the latest release (3.3.1). We have improved the
>>>> performance a lot compared to previous versions and this might help
>>>> with the scrolling problem. The database backend preserves the
>>>> order of creation because there is no parsing, transformation and
>>>> saving operations involved.
>>>>          
>>> I had noticed this property of the DB backend, but no..in fact I
>>> haven't
>>> tried the new version but I will, given your comment (I had lost
>>> hopes with
>>> previous versions of the DB backend, but this comment of yours is
>>> stimulating...I'll report back). In that line of discussion: is
>>> there any
>>> specific DB you would recommend as particularly efficient? Have you
>>> done any
>>> benchmarking? I once tried to use SQLite (it's single user, which would
>>> theoretically do away with the overhead of multiuser management),
>>> but could
>>> not get the JDBC driver to work -apparently something related to
>>> BLOBs-.
>>>
>>>      
>>>> Cheers,
>>>> Tania
>>>>
>>>>          
>>> Many thanks, Tania!
>>>
>>>
>>>      
>>
>> _______________________________________________
>> protege-owl mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>
>> Instructions for unsubscribing:
>> http://protege.stanford.edu/doc/faq.html#01a.03   
>
>

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Overriding automatic sorting in Protégé sibling classes

Wacek Kusnierczyk
Tania Tudorache wrote:

> Hi Wacek,
>
> Wacek Kusnierczyk wrote:
>  
>> Tania Tudorache wrote:
>>    
>>> Hi Alan,
>>>
>>> The sorting takes place in the load methods of
>>> edu.stanford.smi.protegex.owl.jena.JenaOWLModel. This is one of the
>>> load methods:
>>>
>>> public void load(URI uri, String language) throws Exception {
>>>    ProtegeOWLParser parser = new ProtegeOWLParser(this, false);
>>>    parser.run(uri);
>>>    TripleStoreUtil.sortSubclasses(this);
>>>    copyFacetValuesIntoNamedClses();
>>> }
>>>  
>>>      
>> What's the purpose of the second parameter?
>>
>>    
>
> That is a flag that instructs the parser to populate a map of the
>  
> untyped resources, so that you can reference them from the ontology.
> Normally, all entities in the ontology should have a type defined
> (either in the current ontology or one of imported ontologies),
> otherwise the parser does not know what type of Java object to create
> for them. The support for external resources (referenced but untyped
> entities) is not very good in Protege right now, but we plan to improve
> it in future. So, I think for now,  it is better to set the second
> argument to the ProtegeOWLParser constructor to false.
>  
so you mean the intention is that the language argument is passed
further to the parser, and you replace this by false now?
with the code as it is, language is useless.

vQ

> I have attached below the lines of code Alan could use to load an
> ontology without sorting it:
>
>
> URI uri = URIUtilities.createURI("file:///tmp/ont.owl");
> JenaOWLModel owlModel = ProtegeOWL.createJenaOWLModel();
>            
> ProtegeOWLParser parser = new ProtegeOWLParser(owlModel, false);
> parser.run(uri);
>  owlModel.copyFacetValuesIntoNamedClses();
>
>
> Cheers,
> Tania
>
>  
>> vQ
>>
>>    
>>> It is easy to write your own loading method that would be similar to
>>> the above one, but it would leave out the call to
>>> TripleStoreUtil.sortSubclasses(this).
>>>
>>> Good luck!
>>> Tania
>>>
>>>
>>>
>>>
>>> Alan March wrote:
>>>  
>>>      
>>>>> Hi Alan,
>>>>>
>>>>> I am not sure I understand exactly what it means to maintain the
>>>>> creation order for class siblings. Does this mean that you would
>>>>> like to preserve the order across different sessions, i.e. you
>>>>> create some classes, save, close the project and reload, and then
>>>>> you would like to see the same order for the siblings as the one in
>>>>> in the original session?
>>>>>          
>>>>>          
>>>> Right!
>>>>
>>>>      
>>>>        
>>>>> This case is very difficult. Because there are many processes
>>>>> involved that do not have the notion of order in them: for
>>>>> instance, the parser is a streaming parser and it creates all the
>>>>> entities on the fly and does a lot post processing, which makes it
>>>>> impossible to preserver the order. We also don't have control on
>>>>> the way the OWL file is written out, because that is handled by
>>>>> Jena. The Protege-OWL to Jena conversion does not have the notion
>>>>> of order, either.
>>>>>
>>>>> There is indeed a sorting step after the parsing of the triples,
>>>>> and it is easy to make that configurable, but even if the sorting
>>>>> will be disabled, it won't help, beacuse there is no guarantee on
>>>>> the order of classes that you will get.
>>>>>          
>>>>>          
>>>> Yes..I guessed that. Could you please point me out the parts of the
>>>> code
>>>> which do the sorting, in order I might try out what would happen if
>>>> I anull
>>>> the sorting?
>>>>      
>>>>        
>>>>> I am wondering if you tried out the OWL database backend that is
>>>>> available in the latest release (3.3.1). We have improved the
>>>>> performance a lot compared to previous versions and this might help
>>>>> with the scrolling problem. The database backend preserves the
>>>>> order of creation because there is no parsing, transformation and
>>>>> saving operations involved.
>>>>>          
>>>>>          
>>>> I had noticed this property of the DB backend, but no..in fact I
>>>> haven't
>>>> tried the new version but I will, given your comment (I had lost
>>>> hopes with
>>>> previous versions of the DB backend, but this comment of yours is
>>>> stimulating...I'll report back). In that line of discussion: is
>>>> there any
>>>> specific DB you would recommend as particularly efficient? Have you
>>>> done any
>>>> benchmarking? I once tried to use SQLite (it's single user, which would
>>>> theoretically do away with the overhead of multiuser management),
>>>> but could
>>>> not get the JDBC driver to work -apparently something related to
>>>> BLOBs-.
>>>>
>>>>      
>>>>        
>>>>> Cheers,
>>>>> Tania
>>>>>
>>>>>          
>>>>>          
>>>> Many thanks, Tania!
>>>>
>>>>
>>>>      
>>>>        
>>> _______________________________________________
>>> protege-owl mailing list
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>>
>>> Instructions for unsubscribing:
>>> http://protege.stanford.edu/doc/faq.html#01a.03   
>>>      
>>    
>
> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
>  

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Overriding automatic sorting in Protégé sibling classes

Tania Tudorache
The second argument from the ProtegeOWLParser constructor is for the
handling of external resources. It does not have anything to do with the
language.

The language argument of the load calls is unfortunately useless; it is
not passed to any other call further. I am not sure why the language
argument was present in the load method; probably in previous
implementations it was needed. I suppose the reason  that it is still
there is the backwards compatibility of the load utility methods.

Tania




Wacek Kusnierczyk wrote:

> Tania Tudorache wrote:
>> Hi Wacek,
>>
>> Wacek Kusnierczyk wrote:
>>  
>>> Tania Tudorache wrote:
>>>    
>>>> Hi Alan,
>>>>
>>>> The sorting takes place in the load methods of
>>>> edu.stanford.smi.protegex.owl.jena.JenaOWLModel. This is one of the
>>>> load methods:
>>>>
>>>> public void load(URI uri, String language) throws Exception {
>>>>    ProtegeOWLParser parser = new ProtegeOWLParser(this, false);
>>>>    parser.run(uri);
>>>>    TripleStoreUtil.sortSubclasses(this);
>>>>    copyFacetValuesIntoNamedClses();
>>>> }
>>>>        
>>> What's the purpose of the second parameter?
>>>
>>>    
>>
>> That is a flag that instructs the parser to populate a map of the
>>   untyped resources, so that you can reference them from the
>> ontology. Normally, all entities in the ontology should have a type
>> defined (either in the current ontology or one of imported
>> ontologies), otherwise the parser does not know what type of Java
>> object to create for them. The support for external resources
>> (referenced but untyped entities) is not very good in Protege right
>> now, but we plan to improve it in future. So, I think for now,  it is
>> better to set the second argument to the ProtegeOWLParser constructor
>> to false.
>>  
> so you mean the intention is that the language argument is passed
> further to the parser, and you replace this by false now?
> with the code as it is, language is useless.
>
> vQ
>
>> I have attached below the lines of code Alan could use to load an
>> ontology without sorting it:
>>
>>
>> URI uri = URIUtilities.createURI("file:///tmp/ont.owl");
>> JenaOWLModel owlModel = ProtegeOWL.createJenaOWLModel();
>>            ProtegeOWLParser parser = new ProtegeOWLParser(owlModel,
>> false);
>> parser.run(uri);
>>  owlModel.copyFacetValuesIntoNamedClses();
>>
>>
>> Cheers,
>> Tania
>>
>>  
>>> vQ
>>>
>>>    
>>>> It is easy to write your own loading method that would be similar
>>>> to the above one, but it would leave out the call to
>>>> TripleStoreUtil.sortSubclasses(this).
>>>>
>>>> Good luck!
>>>> Tania
>>>>
>>>>
>>>>
>>>>
>>>> Alan March wrote:
>>>>  
>>>>      
>>>>>> Hi Alan,
>>>>>>
>>>>>> I am not sure I understand exactly what it means to maintain the
>>>>>> creation order for class siblings. Does this mean that you would
>>>>>> like to preserve the order across different sessions, i.e. you
>>>>>> create some classes, save, close the project and reload, and then
>>>>>> you would like to see the same order for the siblings as the one
>>>>>> in in the original session?
>>>>>>                    
>>>>> Right!
>>>>>
>>>>>            
>>>>>> This case is very difficult. Because there are many processes
>>>>>> involved that do not have the notion of order in them: for
>>>>>> instance, the parser is a streaming parser and it creates all the
>>>>>> entities on the fly and does a lot post processing, which makes
>>>>>> it impossible to preserver the order. We also don't have control
>>>>>> on the way the OWL file is written out, because that is handled
>>>>>> by Jena. The Protege-OWL to Jena conversion does not have the
>>>>>> notion of order, either.
>>>>>>
>>>>>> There is indeed a sorting step after the parsing of the triples,
>>>>>> and it is easy to make that configurable, but even if the sorting
>>>>>> will be disabled, it won't help, beacuse there is no guarantee on
>>>>>> the order of classes that you will get.
>>>>>>                    
>>>>> Yes..I guessed that. Could you please point me out the parts of
>>>>> the code
>>>>> which do the sorting, in order I might try out what would happen
>>>>> if I anull
>>>>> the sorting?
>>>>>            
>>>>>> I am wondering if you tried out the OWL database backend that is
>>>>>> available in the latest release (3.3.1). We have improved the
>>>>>> performance a lot compared to previous versions and this might
>>>>>> help with the scrolling problem. The database backend preserves
>>>>>> the order of creation because there is no parsing, transformation
>>>>>> and saving operations involved.
>>>>>>                    
>>>>> I had noticed this property of the DB backend, but no..in fact I
>>>>> haven't
>>>>> tried the new version but I will, given your comment (I had lost
>>>>> hopes with
>>>>> previous versions of the DB backend, but this comment of yours is
>>>>> stimulating...I'll report back). In that line of discussion: is
>>>>> there any
>>>>> specific DB you would recommend as particularly efficient? Have
>>>>> you done any
>>>>> benchmarking? I once tried to use SQLite (it's single user, which
>>>>> would
>>>>> theoretically do away with the overhead of multiuser management),
>>>>> but could
>>>>> not get the JDBC driver to work -apparently something related to
>>>>> BLOBs-.
>>>>>
>>>>>            
>>>>>> Cheers,
>>>>>> Tania
>>>>>>
>>>>>>                    
>>>>> Many thanks, Tania!
>>>>>
>>>>>
>>>>>              
>>>> _______________________________________________
>>>> protege-owl mailing list
>>>> [hidden email]
>>>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>>>
>>>> Instructions for unsubscribing:
>>>> http://protege.stanford.edu/doc/faq.html#01a.03         
>>>    
>>
>> _______________________________________________
>> protege-owl mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>
>> Instructions for unsubscribing:
>> http://protege.stanford.edu/doc/faq.html#01a.03   
>
>

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Database backend still slow to refresh

Alan March
In reply to this post by Tania Tudorache
Hi Tania

I've tried the new database backend again and it still presents the problem
(of very slow response). My ontology has about 9000 classes and "lives" in a
SQLServer 2000 connected to Protégé via the jtds driver
(http://jtds.sourceforge.net/). I was wondering if maybe the problem relates
to the manner in which the class tree is managed. Does Protégé referesh the
whole tree every time a class is clicked? Were it so, this could be the
problem.

> I am wondering if you tried out the OWL database backend that
> is available in the latest release (3.3.1). We have improved
> the performance a lot compared to previous versions and this
> might help with the scrolling problem. The database backend
> preserves the order of creation because there is no parsing,
> transformation and saving operations involved.
>
> Cheers,
> Tania
>
>
> Alan March wrote:
> > Every time an owl ontology is loaded by Protégé, sibling
> classes are

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03