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-owl] adding read/write support for another OWL embedding filetype to protege OWL

Timothy Redmond tredmond at stanford.edu
Wed Jul 7 15:12:58 PDT 2010


> what would make you think i'm talking about protege 3? in my first mail i indeed said that this is about latest protege owl 4.1.
> i'm curious why you would think that i was talking about the older one?
>    

Ok - that explains why I thought you were using Protege 4.   The 
reference to import/export plugins threw me off because Protege 4 
doesn't have these.

> why is a backend not relevant? because it is easier to import/export?
>    

Regardless of backend, the OWLOntology will only provide OWL content.  
You need a place to put the non-OWL content.

> i dont need to provide access to the non-OWL content - protege should only be used to edit the OWL parts of the file
> and i already thought of storing the extra non-OWL content as part of the OWL passed to protege - as an annotation or something. this would then be used to reconstruct the original file structure when saving.
>    

This should  work.  Is this a good option for you?

If this works, there will still be the issue of how nicely you can 
present this to the end user.  The easiest thing to do would be to have 
two new menu items for load and save.  But it would be better if the 
regular Protege load and save did the right thing.  I think that this 
can be done but it requires a bit of fancy OWL API footwork.

For the loading, I think that you could add your own parser to the 
OWLParserFactoryRegistry.  Essentially this parser would handle parsing 
your file format.  I think that you can also arrange that save works by 
giving the OWLOntology the right ontology format (instance of the 
OWLOntologyFormat class from the OWL API) and by giving the 
OWLOntologyManager a  OWLOntologyStorer (another OWL api class) that 
knows how to save your format.

I made this up on the spot and haven't tested it.  It sounds like, if 
this is a common type of plugin, I should look into making this easier 
in the future.

-Timothy


On 07/07/2010 01:52 PM, Johannes Schauer wrote:
> hi!
>
>    
>> In your original message I had assumed that you were thinking Protege
>> 4.1 for some reason but I now suspect that you are looking at Protege
>> 3.  In either case I think that there are two possible approaches here
>> and I don't think that a backend relevant to either approach.
>>      
> what would make you think i'm talking about protege 3? in my first mail i indeed said that this is about latest protege owl 4.1.
> i'm curious why you would think that i was talking about the older one?
>
> why is a backend not relevant? because it is easier to import/export?
>
>    
>> The first option is that you are implementing your own file format.  In
>> this case your file is not an OWL file and is not something that is
>> generally loaded or written from Protege.  You could still handle this
>> with a plugin.  The plugin would separate the OWL content and the other
>> content and would keep track of both.  Regular Protege plugins (e.g. the
>> OWL classes tab) would see the OWL content and your plugin would provide
>> access to the non-OWL based content.  You could even hook the save
>> method (e.g. a Protege 3 project plugin) to arrange that the non-OWL
>> content was saved when the OWL content was saved.
>>
>> The second option would be to encode your extra non-OWL content in the
>> OWL content that is loaded in Protege.  You could keep your separate
>> file format but when the ontology is loaded into Protege the non-OWL
>> content of your file would get encoded into OWL constructs.  In this
>> case, a Protege 3 import/export plugin might work.  The import
>> functionality would read your file format into OWL and the export plugin
>> would write the OWL back into your file format.
>>      
> you see me at a loss while reading those last two paragraphs - i dont see any difference between the two options.
> yes, my file is not an OWL file - it only embeds several OWL snippets that form different ontologies when stitched together.
> yes i need to seperate the OWL content from the other content (done with javacc)
> i dont need to provide access to the non-OWL content - protege should only be used to edit the OWL parts of the file
> and i already thought of storing the extra non-OWL content as part of the OWL passed to protege - as an annotation or something. this would then be used to reconstruct the original file structure when saving.
>
> so what is the difference in "implementing my own file format" (first paragraph) and "encode extra non-OWL content in the OWL" - of course i have to do bothe anyways as the original format is not pure OWL to begin with but only contains it?
>
> why do you talk about a protege 3 project/import/export plugin? aren't there protege owl 4 project/import/export plugins?
>
> thank you for bearing with me for so long - i guess that there is some concept that i did not yet grasp to make the matter clear for me yet.
> cheers
> johannes
> _______________________________________________
> protege-owl mailing list
> protege-owl at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
>    




More information about the protege-owl mailing list