Search Mailing List Archives
[protege-owl] adding read/write support for another OWL embedding filetype to protege OWL
j.schauer at email.de
Wed Jul 7 13:52:00 PDT 2010
>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.
More information about the protege-owl