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-dev] WebProtégé - update object property frame inverses

Matthew Horridge matthew.horridge at stanford.edu
Fri May 8 10:19:02 PDT 2015


Hi Karl,

> In light of this, if I want to to modify inverses of object properties (or do other manipulation of properties and/or classes), in my own custom portlets, where would you recommend I do this? I thought that by reusing the existing services and actions instead of creating my own service, I could save myself a bit of work and be more compliant with the existing practices in WebProtégé. Indeed, if your plans are to have WebProtégé be extensible (I don't know if this is a design goal) then providing a somewhat stable service-level API open for developers to reuse may be worth considering?

We could do with a more general API for ontology manipulation I suppose.  At the moment, each portlet implements optimised calls to suit its needs.  e.g. The frame stuff is really specific to the simplified editing portlet.

> If however the existing dispatch service actions are only intended to be used by the specific UI functionality that the built-in portlet set provides, and are not intended or planned to be more generally reusable by other devs/customizers, then I'll have to do a bit of refactoring for the sake of future-proofing my work (basically put more things into my own custom service). That won't be a problem for me, but it would be nice to know what your plans are with regard to this so I can make the right choice.

You should use the dispatch service.  You should definitely not add your own services (i.e. do not touch the web.xml).  In the end we will make actions, results and action handlers pluggable (we’re almost there - this will be done by annotations btw).  This means that rather than adding your own service you should add custom actions, results and action handlers.  At the moment, you will currently have to modify the ActionHandlersModule by hand to add your action handler.  Put the action and result classes in a shared package (so they can be used by both the client and server).  Use dependency injection to inject the things you need into your action handler - see the other action handlers for examples here (try to be as minimal as possible here).

Hope this helps,

Please let me know if you have any questions.

Cheers,

Matthew






> 
> Cheers,
> 
> /Karl
> 
> 2015-05-05 20:31 GMT+02:00 Matthew Horridge <matthew.horridge at stanford.edu <mailto:matthew.horridge at stanford.edu>>:
> Hi Karl,
> 
> I think we considered showing inverses in the simple UI (which is what the frames are intended for) but then decided against this.  The inverses should probably be removed from the frame rather than being added to the frame translator.  If you want to clean this up please feel free to do so and issue a pull request.
> 
> Cheers,
> 
> Matthew
> 
> 
> > On 5 May 2015, at 05:14, Karl Hammar <karl at karlhammar.com <mailto:karl at karlhammar.com>> wrote:
> >
> > Hi,
> >
> > I'm looking into how to in WebProtégé update object properties using the Dispatch service with UpdateObjectActions and ObjectPropertyFrame objects.
> >
> > I've noted that the corresponding translator, ObjectPropertyFrameTranslator, that from such frame objects generates axioms for storage in the ontology, does not generate or parse owl:inverseOf statements. The ObjectPropertyFrame class itself however has an "inverses" member variable of the expected type (a Set of OWLObjectProperty:s).
> >
> > Is there a reason for this mismatch between the frame class and its translator class, and would you like for me to try and fix it? That would enable object property inverses to be modified using the dispatch service, just as ranges, domains, and annotations currently can be modified.
> >
> > /Karl
> > _______________________________________________
> > protege-dev mailing list
> > protege-dev at lists.stanford.edu <mailto:protege-dev at lists.stanford.edu>
> > https://mailman.stanford.edu/mailman/listinfo/protege-dev <https://mailman.stanford.edu/mailman/listinfo/protege-dev>
> 
> 
> _______________________________________________
> protege-dev mailing list
> protege-dev at lists.stanford.edu <mailto:protege-dev at lists.stanford.edu>
> https://mailman.stanford.edu/mailman/listinfo/protege-dev <https://mailman.stanford.edu/mailman/listinfo/protege-dev>
> 
> _______________________________________________
> protege-dev mailing list
> protege-dev at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/protege-dev/attachments/20150508/0f59e293/attachment.html>


More information about the protege-dev mailing list