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] protege-discussion Digest, Vol 17, Issue 25

Jennifer Vendetti vendetti at stanford.edu
Thu Jan 3 11:34:32 PST 2008


Hui,

Have you looked at the Jambalaya plug-in?  Information about the plug-in 
is available from the University of Victoria's Web site:

http://www.thechiselgroup.org/jambalaya

There is another option as well called "OntoViz", which uses the 
Graphviz software:

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

Jennifer

hhuang wrote:
> Would anyone be kind enough to point to me another way to show a 
> graphic view, other than GraphWidget, of an ontology developed in 
> Frame?  I followed the tutorial for GraphWidget and got the 
> idea.  What I am wondering is whether there is any plugin that simply 
> takes the ontology file(s) and generates a graphic view without 
> requiring the user to manually pick the classes/instances/... and 
> draw the picture as GraphWidget does?  I took a quick look at 
> graphviz and could not figure out whether it might serve the purposes.
>
> Thanks very much and Happy New Year!
>
> Hui
>
> At 03:05 PM 12/22/2007, you wrote:
>   
>> Send protege-discussion mailing list submissions to
>>         protege-discussion at lists.stanford.edu
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>> or, via email, send a message with subject or body 'help' to
>>         protege-discussion-request at lists.stanford.edu
>>
>> You can reach the person managing the list at
>>         protege-discussion-owner at lists.stanford.edu
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of protege-discussion digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Missing       mapinstance     warningsfrom    GraphWidget 
>> (Jonathan Carter)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 21 Dec 2007 21:05:32 -0000
>> From: "Jonathan Carter" <jonathan.carter at e-asolutions.com>
>> Subject: Re: [protege-discussion] Missing       mapinstance     warningsfrom
>>         GraphWidget
>> To: "'User support for Core Protege and the Protege-Frames editor'"
>>         <protege-discussion at lists.stanford.edu>
>> Message-ID: <001201c84415$3d49fc40$4001a8c0 at obiwan>
>> Content-Type: text/plain;       charset="iso-8859-1"
>>
>> 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
>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> protege-discussion mailing list
>> protege-discussion at lists.stanford.edu
>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>
>>
>> End of protege-discussion Digest, Vol 17, Issue 25
>> **************************************************
>>     
>
>
> _______________________________________________
> 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