Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] Missing mapinstance warningsfrom GraphWidget

Jonathan Carter jonathan.carter at e-asolutions.com
Fri Dec 21 13:05:32 PST 2007


Thanks Tania

Cheers 
Jonathan


-----Original Message-----
From: protege-discussion-bounces at lists.stanford.edu
[mailto:protege-discussion-bounces at lists.stanford.edu] On Behalf Of Tania
Tudorache
Sent: 21 December 2007 20:03
To: User support for Core Protege and the Protege-Frames editor
Subject: Re: [protege-discussion] Missing mapinstance warningsfrom
GraphWidget

Hi Jonathan,

Thanks a lot for the suggestion. We'll be investigating this and other ideas
for shared vs local forms next year. As you probably know, the devil lies in
the details. We really need to think through a solution proposal to make
sure that it will work, especially in a client-server setting.

A quick note: with the latest beta, you should not get the warnings anymore.

Cheers,
Tania


Jonathan Carter wrote:
> Thanks for this explanation, Tania.
>
> I agree that there are some interesting multi-user challenges in 
> there! All makes sense now.
> It's reassuring to know that you're aware of this and I'd agree with 
> your special approach for the node positioning on the graph widget.
> The only approach that I can think of for widgets like the graph 
> widget would be to use some kind of check-out/check-in model where 
> when I open a graph widget for editing (via some kind of explicit "I'm
editing this now"
> button maybe?) this would then lock the graph for editing until I 
> explicitly commit my changes (again via a specific button) which would 
> then save the positions and sizes of the objects. I realise that this 
> is a bit of a departure for Protégé users - never mind how the 
> software works in that we're all used to not having to explicitly save 
> our edits on forms (and I really like the modeless dialog approach). 
> Just some thoughts at this stage
> - which I'd be happy to take off-line if there's any interest in 
> exploring them.
>
> Thanks again for taking us through the issues - it really helps to 
> know the background to these sorts of things. For now, I think I will 
> just live with the warnings (the graphs do a default layout on my clients
which is fine).
>
> Regards
>
> Jonathan
>
> __________________________________________
> Jonathan Carter - Head of Technical Architecture Enterprise 
> Architecture Solutions Ltd
>
>
> -----Original Message-----
> From: protege-discussion-bounces at lists.stanford.edu
> [mailto:protege-discussion-bounces at lists.stanford.edu] On Behalf Of 
> Tania Tudorache
> Sent: 20 December 2007 20:57
> To: User support for Core Protege and the Protege-Frames editor
> Subject: Re: [protege-discussion] Missing map instance warningsfrom 
> GraphWidget
>
> Jonathan,
>
> If you use the latest beta (build 125 or greater), you should not see 
> the Missing client information warnings anymore.
>
> In the previous beta, we have added support for included forms in 
> client-server mode, and especially for included graph widgets. As a 
> side effect of this enhancement, you should not see the warnings in 
> the client console anymore.
>
> The way the forms work in client-server is as following: When the 
> server starts, the forms are loaded from the pprj files. When a client 
> connects to a server, the pprj file information is copied on the 
> client, and from that moment on, whatever changes happen on the form on
the client (e.g.
> move nodes in graph widget), won't be reflected on the server.
>
> The issue of syncing the forms from different clients is complicated. 
> And there is no clear solution. You can imagine that one client won't 
> appreciate if another client suddenly changed the layout of the class 
> he is just working on. The same with browser texts, instance layout, 
> colors of graph widget nodes, etc. We thought of a solution that would 
> solve this issue and which involves having different form 
> customization for each client that are stored in a local pprj file.
>
> So, there would be a new type of pprj file (transparent to the user), 
> that would serve a remote ontology. When the client opens the pprj 
> file, he will have his own form configuration but the contents of the 
> ontology would come from the remote server.
>
> We were thinking also for a solution for the graph widget, for which 
> we might have a special handling for the position of nodes. So, if the 
> position of a node is changed on a client, this should be reflected on 
> the other clients as well. This may mean that the graph you are just 
> viewing will have some nodes moving around (but probably this won't be
very often the case).
> This is better than the current implementation, in which the new nodes 
> created by other clients are put one on top of another in the upper 
> left corner of the widget.
>
> If you have other suggestions for possible solutions, we are happy to 
> hear about them.
>
> Tania
>
>
> Samson Tu wrote:
>   
>> Jonathan Carter wrote:
>>   
>>     
>>> Hi Samson,
>>>
>>> OK, so to make sure I understand, if I create a graph in a client, 
>>> when I come to open it again, the server cannot serve me the
>>>       
> locations/sizes etc.
>   
>>> and so everything reverts to default (at least it doesn't fail or
>>>       
> crash!)?
>   
>>>     
>>>       
>> Yes. The automatic layout feature is probably your best option with 
>> new graphs in client/server mode.
>>
>>   
>>     
>>> What I've got is a project that was created in stand-alone mode, 
>>> including some graphs and now I'm using this project in 
>>> client-server mode and even all the graph properties that I can see 
>>> in the server project files are not 'sent down' to the clients. So, 
>>> effectively, I've started with what you suggested as the solution 
>>> but am still having problems. If I open the server's project locally 
>>> on the server in stand-alone mode, everything is fine with my 
>>> graphs. I saved this standalone project to a new version on the 
>>> server and used this for client-server mode, but I am still getting the
warnings from my clients.
>>>     
>>>       
>> Install the most recent version of Protege 3.4 beta. I never used 
>> Protege in client/server mode until this past week because of 
>> problems with form customizations and graph widget, but Protege 
>> developers have fixed some of these bugs recently. You should get the 
>> standalone layout with the current beta at least.
>>
>>
>>   
>>     
>>> Do you know if there are any plans to resolve this at some point? Or 
>>> are there any pointers/thoughts as to what the solution is? I'd be 
>>> happy to help resolve the issue.
>>>     
>>>       
>> There is hope that the issue may get resolved early next year.
>>
>> Samson
>>   
>>     
>
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03
>
>
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: 
> http://protege.stanford.edu/doc/faq.html#01a.03
>
>   

_______________________________________________
protege-discussion mailing list
protege-discussion at lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/protege-discussion

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





More information about the protege-discussion mailing list