config for handling big ontologies

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

config for handling big ontologies

Olivier Dameron
Dear protégéans,
   Our team is in the process of defining the specs for a new server.
This one should be able to run protégé and some classifier on
potentially big ontologies (ncit, maybe fma,...)
   I would like to invite you to share with me any experience and advice
about what works and what does not work, with which configuration.

Thank you
olivier
_______________________________________________
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: config for handling big ontologies

Brad Cox, Ph.D.
For our U.S. DOD work, plain REST APIs (port 80 and 443) would be nice. RMI
is just impossible to deal with in a strict firewalled environment.

JSON is nice for marshaling arguments. But the ultimate be-nice-to DOD
choice is SOAP. If you don't do it we'll probably be forced by our customer
to add it.


On 9/4/09 1:42 PM, "Olivier Dameron" <[hidden email]>
wrote:

> Dear protégéans,
>    Our team is in the process of defining the specs for a new server.
> This one should be able to run protégé and some classifier on
> potentially big ontologies (ncit, maybe fma,...)
>    I would like to invite you to share with me any experience and advice
> about what works and what does not work, with which configuration.
>
> Thank you
> olivier
> _______________________________________________
> 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: config for handling big ontologies

Timothy Redmond

On Sep 7, 2009, at 3:50 PM, Brad Cox wrote:

> For our U.S. DOD work, plain REST APIs (port 80 and 443) would be  
> nice. RMI
> is just impossible to deal with in a strict firewalled environment.

RMI works  fine in a firewalled environment.  You just need to set the  
ports.  I have even made RMI work through a NAT router but it appears  
that this is difficult and I may be the only one who has succeeded at  
this.

>
> JSON is nice for marshaling arguments. But the ultimate be-nice-to DOD
> choice is SOAP. If you don't do it we'll probably be forced by our  
> customer
> to add it.

The protege 4 server will probably support the rest api.

-Timothy

>
>
> On 9/4/09 1:42 PM, "Olivier Dameron" <[hidden email]>
> wrote:
>
>> Dear protégéans,
>>   Our team is in the process of defining the specs for a new server.
>> This one should be able to run protégé and some classifier on
>> potentially big ontologies (ncit, maybe fma,...)
>>   I would like to invite you to share with me any experience and  
>> advice
>> about what works and what does not work, with which configuration.
>>
>> Thank you
>> olivier
>> _______________________________________________
>> 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: config for handling big ontologies

Timothy Redmond
In reply to this post by Olivier Dameron

The first  thing that occurred to me was the ability to tell the  
client to preload certain classes [2].  If a user knows what parts of  
the tree they usually look at, this can make navigation work much  
quicker after the client starts up.

Another thing that is very important is the network latency.  We have  
tried as much as possible to make the protege client work well with  
latencies ranging from 1ms to 100ms.  But a latency of 100ms is very  
hard to work wtih and users will notice.

We have done a lot of work on the client-server tutorial [1] so there  
are probably many things that can be found there.

-Timothy

[1] http://protegewiki.stanford.edu/index.php/Protege_Client-Server_Tutorial
[2] http://protegewiki.stanford.edu/index.php/Protege_Client_Server_Tutorial_Advanced#Client_Side_Settings


On Sep 4, 2009, at 10:42 AM, Olivier Dameron wrote:

> Dear protégéans,
>   Our team is in the process of defining the specs for a new server.
> This one should be able to run protégé and some classifier on
> potentially big ontologies (ncit, maybe fma,...)
>   I would like to invite you to share with me any experience and  
> advice
> about what works and what does not work, with which configuration.
>
> Thank you
> olivier
> _______________________________________________
> 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: config for handling big ontologies

Timothy Redmond
In reply to this post by Timothy Redmond

>> For our U.S. DOD work, plain REST APIs (port 80 and 443) would be  
>> nice. RMI
>> is just impossible to deal with in a strict firewalled environment.
>
> RMI works  fine in a firewalled environment.  You just need to set  
> the ports.  I have even made RMI work through a NAT router but it  
> appears  that this is difficult and I may be the only one who has  
> succeeded at this.

The reference for how to work with firewalls is [1].

-Timothy

[1] http://protegewiki.stanford.edu/index.php/Protege_Client_Server_Tutorial_Advanced#Working_with_Firewalls

On Sep 7, 2009, at 7:45 PM, Timothy Redmond wrote:

>
> On Sep 7, 2009, at 3:50 PM, Brad Cox wrote:
>
>> For our U.S. DOD work, plain REST APIs (port 80 and 443) would be  
>> nice. RMI
>> is just impossible to deal with in a strict firewalled environment.
>
> RMI works  fine in a firewalled environment.  You just need to set  
> the ports.  I have even made RMI work through a NAT router but it  
> appears  that this is difficult and I may be the only one who has  
> succeeded at this.
>
>>
>> JSON is nice for marshaling arguments. But the ultimate be-nice-to  
>> DOD
>> choice is SOAP. If you don't do it we'll probably be forced by our  
>> customer
>> to add it.
>
> The protege 4 server will probably support the rest api.
>
> -Timothy
>
>>
>>
>> On 9/4/09 1:42 PM, "Olivier Dameron" <olivier.dameron@univ-
>> rennes1.fr>
>> wrote:
>>
>>> Dear protégéans,
>>>  Our team is in the process of defining the specs for a new server.
>>> This one should be able to run protégé and some classifier on
>>> potentially big ontologies (ncit, maybe fma,...)
>>>  I would like to invite you to share with me any experience and  
>>> advice
>>> about what works and what does not work, with which configuration.
>>>
>>> Thank you
>>> olivier
>>> _______________________________________________
>>> 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

_______________________________________________
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: config for handling big ontologies

Ronald Cornet
In reply to this post by Timothy Redmond
What I would like is:

* a server that preloads and classifies an ontology.
* a client that connects to the server and asynchronously builds a tree-representation of (part of) the ontology.
Or more general, a thin client that retrieves only what's needed from the server (which may include / require preloading of classes).

Regards,
Ronald

###############################################################
Ronald Cornet, PhD                    email: [hidden email]
dept. of Medical Informatics          phone: +31 (0)20 566 5188
Academic Medical Center, Room J1B-115 fax:   +31 (0)20 691 9840
P.O.Box 22700                         www: http://kik.amc.uva.nl/home/rcornet/
1100 DE  Amsterdam
The Netherlands                       'The truth is out there'
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf
> Of Timothy Redmond
> Sent: Tuesday, September 08, 2009 04:57
> To: User support for the Protege-OWL editor
> Subject: Re: [protege-owl] config for handling big ontologies
>
>
> The first  thing that occurred to me was the ability to tell
> the client to preload certain classes [2].  If a user knows
> what parts of the tree they usually look at, this can make
> navigation work much quicker after the client starts up.
>
> Another thing that is very important is the network latency.  
> We have tried as much as possible to make the protege client
> work well with latencies ranging from 1ms to 100ms.  But a
> latency of 100ms is very hard to work wtih and users will notice.
>
> We have done a lot of work on the client-server tutorial [1]
> so there are probably many things that can be found there.
>
> -Timothy
>
> [1]
> http://protegewiki.stanford.edu/index.php/Protege_Client-Serve
> r_Tutorial
> [2]
> http://protegewiki.stanford.edu/index.php/Protege_Client_Serve
> r_Tutorial_Advanced#Client_Side_Settings
>
>
> On Sep 4, 2009, at 10:42 AM, Olivier Dameron wrote:
>
> > Dear protégéans,
> >   Our team is in the process of defining the specs for a new server.
> > This one should be able to run protégé and some classifier on
> > potentially big ontologies (ncit, maybe fma,...)
> >   I would like to invite you to share with me any experience and
> > advice about what works and what does not work, with which
> > configuration.
> >
> > Thank you
> > olivier
> > _______________________________________________
> > 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: config for handling big ontologies

Richard H. McCullough-3
In reply to this post by Olivier Dameron
Perhaps mke [see http://mkrmke.org/] is what you want.
Ontologies are preloaded into GDBM databases.
 
GDBM tables are limited to 2 GB in size.
Anything larger will require use of another database, such as MySQL.
I expect to implement MySQL version later this year.
 
Dick McCullough
http://mkrmke.org

_______________________________________________
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: config for handling big ontologies

Timothy Redmond
In reply to this post by Ronald Cornet

Hi Ronald,

This is an interesting set of challenges.  I have been thinking about  
them for a few days.  Much of what you are describing sounds like web  
protege.  It is currently actively being developed and an early  
version exists here [1].  It uses a thin client. It gets information  
about an ontology as it is needed.  One might think that retrieving  
parts of the ontology on an as-needed basis would lead to performance  
problems.  If the connection to the server is slow then the client  
will have to wait. But the underlying technology is highly  
asynchronous.  This means that the user experience will not hang  
because of a single rpc call.  Tania tells me that the user experience  
is good even with high latency.  This has been much harder to achieve  
with the Protege 3 client-server where a single rpc can stall the  
client.

We are also looking at creating servers that provide something like  
dynamic svn-like access to ontologies.  I have also been thinking that  
this could be integrated with web-protege and incremental inference.  
The incremental inference work has already been done by Clark-Parsia  
and is being used (with the NCI Protege client-server) by NCI.  If we  
combine these technologies we might get something like what you are  
describing.

But this is all still just vision.  I have been picking off some of  
the pieces of this but there is a lot more work to go.

-Timothy



[1] http://bmir-protege-dev1.stanford.edu/webprotege/

On Sep 8, 2009, at 3:45 AM, Ronald Cornet wrote:

> What I would like is:
>
> * a server that preloads and classifies an ontology.
> * a client that connects to the server and asynchronously builds a  
> tree-representation of (part of) the ontology.
> Or more general, a thin client that retrieves only what's needed  
> from the server (which may include / require preloading of classes).
>
> Regards,
> Ronald
>
> ###############################################################
> Ronald Cornet, PhD                    email: [hidden email]
> dept. of Medical Informatics          phone: +31 (0)20 566 5188
> Academic Medical Center, Room J1B-115 fax:   +31 (0)20 691 9840
> P.O.Box 22700                         www: http://kik.amc.uva.nl/home/rcornet/
> 1100 DE  Amsterdam
> The Netherlands                       'The truth is out there'
>
>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf
>> Of Timothy Redmond
>> Sent: Tuesday, September 08, 2009 04:57
>> To: User support for the Protege-OWL editor
>> Subject: Re: [protege-owl] config for handling big ontologies
>>
>>
>> The first  thing that occurred to me was the ability to tell
>> the client to preload certain classes [2].  If a user knows
>> what parts of the tree they usually look at, this can make
>> navigation work much quicker after the client starts up.
>>
>> Another thing that is very important is the network latency.
>> We have tried as much as possible to make the protege client
>> work well with latencies ranging from 1ms to 100ms.  But a
>> latency of 100ms is very hard to work wtih and users will notice.
>>
>> We have done a lot of work on the client-server tutorial [1]
>> so there are probably many things that can be found there.
>>
>> -Timothy
>>
>> [1]
>> http://protegewiki.stanford.edu/index.php/Protege_Client-Serve
>> r_Tutorial
>> [2]
>> http://protegewiki.stanford.edu/index.php/Protege_Client_Serve
>> r_Tutorial_Advanced#Client_Side_Settings
>>
>>
>> On Sep 4, 2009, at 10:42 AM, Olivier Dameron wrote:
>>
>>> Dear protégéans,
>>>  Our team is in the process of defining the specs for a new server.
>>> This one should be able to run protégé and some classifier on
>>> potentially big ontologies (ncit, maybe fma,...)
>>>  I would like to invite you to share with me any experience and
>>> advice about what works and what does not work, with which
>>> configuration.
>>>
>>> Thank you
>>> olivier
>>> _______________________________________________
>>> 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

_______________________________________________
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: config for handling big ontologies

Ronald Cornet
Hi Timothy,

I'm happy to see what functionality webprotege is now offering.
Having this is really good!

But of course I like to push the limits :)

1. Separation of concepts and instances
I imagine I have a (classified) version of SNOMED running in a server. Now I want to bring my SNOMED-encoded patient records in and do advanced querying and reasoning. Whereas of course the Tbox / concepts / SNOMED CT will be the same for all users, the Abox / instances / patients will differ per case. I have no idea if and how reasoners can deal with that (incrementally?), but as I'm just trying to come up with my 3 (or more) wishes for the genie(s), I don't mind, as long as it is realized :)

2. Being able to install the server on a local machine

3. Having a DL tab available in Web-protégé

I'm sure I'll come up with more, but this is just a start...

Cheers, Ronald


###############################################################
Ronald Cornet, PhD                    email: [hidden email]
dept. of Medical Informatics          phone: +31 (0)20 566 5188
Academic Medical Center, Room J1B-115 fax:   +31 (0)20 691 9840
P.O.Box 22700                         www: http://kik.amc.uva.nl/home/rcornet/
1100 DE  Amsterdam
The Netherlands                       'The truth is out there'
 

> -----Original Message-----
> From: Timothy Redmond [mailto:[hidden email]]
> Sent: Thursday, September 10, 2009 16:54
> To: User support for the Protege-OWL editor
> Cc: [hidden email]
> Subject: Re: [protege-owl] config for handling big ontologies
>
>
> Hi Ronald,
>
> This is an interesting set of challenges.  I have been
> thinking about them for a few days.  Much of what you are
> describing sounds like web protege.  It is currently actively
> being developed and an early version exists here [1].  It
> uses a thin client. It gets information about an ontology as
> it is needed.  One might think that retrieving parts of the
> ontology on an as-needed basis would lead to performance
> problems.  If the connection to the server is slow then the
> client will have to wait. But the underlying technology is
> highly asynchronous.  This means that the user experience
> will not hang because of a single rpc call.  Tania tells me
> that the user experience is good even with high latency.  
> This has been much harder to achieve with the Protege 3
> client-server where a single rpc can stall the client.
>
> We are also looking at creating servers that provide
> something like dynamic svn-like access to ontologies.  I have
> also been thinking that  
> this could be integrated with web-protege and incremental
> inference.  
> The incremental inference work has already been done by
> Clark-Parsia and is being used (with the NCI Protege
> client-server) by NCI.  If we combine these technologies we
> might get something like what you are describing.
>
> But this is all still just vision.  I have been picking off
> some of the pieces of this but there is a lot more work to go.
>
> -Timothy
>
>
>
> [1] http://bmir-protege-dev1.stanford.edu/webprotege/
>
> On Sep 8, 2009, at 3:45 AM, Ronald Cornet wrote:
>
> > What I would like is:
> >
> > * a server that preloads and classifies an ontology.
> > * a client that connects to the server and asynchronously builds a
> > tree-representation of (part of) the ontology.
> > Or more general, a thin client that retrieves only what's
> needed from
> > the server (which may include / require preloading of classes).
> >
> > Regards,
> > Ronald
> >
> > ###############################################################
> > Ronald Cornet, PhD                    email: [hidden email]
> > dept. of Medical Informatics          phone: +31 (0)20 566 5188
> > Academic Medical Center, Room J1B-115 fax:   +31 (0)20 691 9840
> > P.O.Box 22700                         www:
> http://kik.amc.uva.nl/home/rcornet/
> > 1100 DE  Amsterdam
> > The Netherlands                       'The truth is out there'
> >
> >
> >> -----Original Message-----
> >> From: [hidden email]
> >> [mailto:[hidden email]] On Behalf Of
> >> Timothy Redmond
> >> Sent: Tuesday, September 08, 2009 04:57
> >> To: User support for the Protege-OWL editor
> >> Subject: Re: [protege-owl] config for handling big ontologies
> >>
> >>
> >> The first  thing that occurred to me was the ability to tell the
> >> client to preload certain classes [2].  If a user knows
> what parts of
> >> the tree they usually look at, this can make navigation work much
> >> quicker after the client starts up.
> >>
> >> Another thing that is very important is the network latency.
> >> We have tried as much as possible to make the protege client work
> >> well with latencies ranging from 1ms to 100ms.  But a latency of
> >> 100ms is very hard to work wtih and users will notice.
> >>
> >> We have done a lot of work on the client-server tutorial
> [1] so there
> >> are probably many things that can be found there.
> >>
> >> -Timothy
> >>
> >> [1]
> >> http://protegewiki.stanford.edu/index.php/Protege_Client-Serve
> >> r_Tutorial
> >> [2]
> >> http://protegewiki.stanford.edu/index.php/Protege_Client_Serve
> >> r_Tutorial_Advanced#Client_Side_Settings
> >>
> >>
> >> On Sep 4, 2009, at 10:42 AM, Olivier Dameron wrote:
> >>
> >>> Dear protégéans,
> >>>  Our team is in the process of defining the specs for a
> new server.
> >>> This one should be able to run protégé and some classifier on
> >>> potentially big ontologies (ncit, maybe fma,...)  I would like to
> >>> invite you to share with me any experience and advice about what
> >>> works and what does not work, with which configuration.
> >>>
> >>> Thank you
> >>> olivier
> >>> _______________________________________________
> >>> 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
>
>
>

_______________________________________________
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: config for handling big ontologies

Timothy Redmond

> 1. Separation of concepts and instances
> I imagine I have a (classified) version of SNOMED running in a  
> server. Now I want to bring my SNOMED-encoded patient records in and  
> do advanced querying and reasoning. Whereas of course the Tbox /  
> concepts / SNOMED CT will be the same for all users, the Abox /  
> instances / patients will differ per case.

I think you are saying that you want some sort of import capability so  
that you can have ontologies with individual patient records import  
and use the general SNOMED CT concepts.  I will have to think about  
this.  Protege 3 Client server and Web-Protege don't handle this very  
well.

> I have no idea if and how reasoners can deal with that  
> (incrementally?), but as I'm just trying to come up with my 3 (or  
> more) wishes for the genie(s), I don't mind, as long as it is  
> realized :)
>
> 2. Being able to install the server on a local machine

This is quite possible [1,2].  Web-Protege is more complex to setup  
than the Protege  client-server.  Neither of these are going to be as  
easy to setup as the standalone Protege.  But WebProtege is in the  
early days now and it will probably get much simpler over time.  I  
have some ideas about this but they are in the very early development  
stages yet.

>
> 3. Having a DL tab available in Web-protégé


I am thinking hard and starting the implementation of a transition of  
WebProtege to the Manchester owl api.  If this happens things such as  
a DL tab will become much more natural.

-Timothy


[1] http://protegewiki.stanford.edu/index.php/WebProtege
[2] http://protegewiki.stanford.edu/index.php/Protege_Client-Server_Tutorial

On Sep 12, 2009, at 2:45 AM, Ronald Cornet wrote:

> Hi Timothy,
>
> I'm happy to see what functionality webprotege is now offering.
> Having this is really good!
>
> But of course I like to push the limits :)
>
> 1. Separation of concepts and instances
> I imagine I have a (classified) version of SNOMED running in a  
> server. Now I want to bring my SNOMED-encoded patient records in and  
> do advanced querying and reasoning. Whereas of course the Tbox /  
> concepts / SNOMED CT will be the same for all users, the Abox /  
> instances / patients will differ per case. I have no idea if and how  
> reasoners can deal with that (incrementally?), but as I'm just  
> trying to come up with my 3 (or more) wishes for the genie(s), I  
> don't mind, as long as it is realized :)
>
> 2. Being able to install the server on a local machine
>
> 3. Having a DL tab available in Web-protégé
>
> I'm sure I'll come up with more, but this is just a start...
>
> Cheers, Ronald
>
>
> ###############################################################
> Ronald Cornet, PhD                    email: [hidden email]
> dept. of Medical Informatics          phone: +31 (0)20 566 5188
> Academic Medical Center, Room J1B-115 fax:   +31 (0)20 691 9840
> P.O.Box 22700                         www: http://kik.amc.uva.nl/home/rcornet/
> 1100 DE  Amsterdam
> The Netherlands                       'The truth is out there'
>
>
>> -----Original Message-----
>> From: Timothy Redmond [mailto:[hidden email]]
>> Sent: Thursday, September 10, 2009 16:54
>> To: User support for the Protege-OWL editor
>> Cc: [hidden email]
>> Subject: Re: [protege-owl] config for handling big ontologies
>>
>>
>> Hi Ronald,
>>
>> This is an interesting set of challenges.  I have been
>> thinking about them for a few days.  Much of what you are
>> describing sounds like web protege.  It is currently actively
>> being developed and an early version exists here [1].  It
>> uses a thin client. It gets information about an ontology as
>> it is needed.  One might think that retrieving parts of the
>> ontology on an as-needed basis would lead to performance
>> problems.  If the connection to the server is slow then the
>> client will have to wait. But the underlying technology is
>> highly asynchronous.  This means that the user experience
>> will not hang because of a single rpc call.  Tania tells me
>> that the user experience is good even with high latency.
>> This has been much harder to achieve with the Protege 3
>> client-server where a single rpc can stall the client.
>>
>> We are also looking at creating servers that provide
>> something like dynamic svn-like access to ontologies.  I have
>> also been thinking that
>> this could be integrated with web-protege and incremental
>> inference.
>> The incremental inference work has already been done by
>> Clark-Parsia and is being used (with the NCI Protege
>> client-server) by NCI.  If we combine these technologies we
>> might get something like what you are describing.
>>
>> But this is all still just vision.  I have been picking off
>> some of the pieces of this but there is a lot more work to go.
>>
>> -Timothy
>>
>>
>>
>> [1] http://bmir-protege-dev1.stanford.edu/webprotege/
>>
>> On Sep 8, 2009, at 3:45 AM, Ronald Cornet wrote:
>>
>>> What I would like is:
>>>
>>> * a server that preloads and classifies an ontology.
>>> * a client that connects to the server and asynchronously builds a
>>> tree-representation of (part of) the ontology.
>>> Or more general, a thin client that retrieves only what's
>> needed from
>>> the server (which may include / require preloading of classes).
>>>
>>> Regards,
>>> Ronald
>>>
>>> ###############################################################
>>> Ronald Cornet, PhD                    email: [hidden email]
>>> dept. of Medical Informatics          phone: +31 (0)20 566 5188
>>> Academic Medical Center, Room J1B-115 fax:   +31 (0)20 691 9840
>>> P.O.Box 22700                         www:
>> http://kik.amc.uva.nl/home/rcornet/
>>> 1100 DE  Amsterdam
>>> The Netherlands                       'The truth is out there'
>>>
>>>
>>>> -----Original Message-----
>>>> From: [hidden email]
>>>> [mailto:[hidden email]] On Behalf Of
>>>> Timothy Redmond
>>>> Sent: Tuesday, September 08, 2009 04:57
>>>> To: User support for the Protege-OWL editor
>>>> Subject: Re: [protege-owl] config for handling big ontologies
>>>>
>>>>
>>>> The first  thing that occurred to me was the ability to tell the
>>>> client to preload certain classes [2].  If a user knows
>> what parts of
>>>> the tree they usually look at, this can make navigation work much
>>>> quicker after the client starts up.
>>>>
>>>> Another thing that is very important is the network latency.
>>>> We have tried as much as possible to make the protege client work
>>>> well with latencies ranging from 1ms to 100ms.  But a latency of
>>>> 100ms is very hard to work wtih and users will notice.
>>>>
>>>> We have done a lot of work on the client-server tutorial
>> [1] so there
>>>> are probably many things that can be found there.
>>>>
>>>> -Timothy
>>>>
>>>> [1]
>>>> http://protegewiki.stanford.edu/index.php/Protege_Client-Serve
>>>> r_Tutorial
>>>> [2]
>>>> http://protegewiki.stanford.edu/index.php/Protege_Client_Serve
>>>> r_Tutorial_Advanced#Client_Side_Settings
>>>>
>>>>
>>>> On Sep 4, 2009, at 10:42 AM, Olivier Dameron wrote:
>>>>
>>>>> Dear protégéans,
>>>>> Our team is in the process of defining the specs for a
>> new server.
>>>>> This one should be able to run protégé and some classifier on
>>>>> potentially big ontologies (ncit, maybe fma,...)  I would like to
>>>>> invite you to share with me any experience and advice about what
>>>>> works and what does not work, with which configuration.
>>>>>
>>>>> Thank you
>>>>> olivier
>>>>> _______________________________________________
>>>>> 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
>>
>>
>>
>

_______________________________________________
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