[xwiki-devs] [Discussion] Annotations improvements -- allowing different annotation types
Hi devs, Following the previous mail with the desired improvements for the annotation feature, I would like to discuss some options for implementing the first of the enhancements, namely the ability to configure easily the type of added annotation. (see http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HFeaturesimprov... for details). Two alternatives for this would be: A) to preserve the current architecture of the annotations plugin and only add a map of "extra fields" to the annotation type. The type of the annotation would be known by the js client through the configuration of an XWiki class and the js client would create a "generic" form for any such type. See more details about this solution at http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution1extra... . Pros: preserves the current annotations architecture, creates an easy way to plug an annotation storage service Cons: the Annotation class would be nothing else but a "BaseCollection" the same as a generic XWiki object, and we would be reimplementing view, save, edit, delete of this type (already implemented through the xwiki action) from the web forms level (editing and displaying an annotation), through the controller (REST this time instead of actions in the standard wiki servlet), to the storage level (XWikiIOService will only transform a map (the Annotation class) to another map (the XWikiObject in the xwiki document)). B) to make an XWiki object model based implementation where the js client, to create the UI, would just asynchronously fetch standard actions in XWiki (edit, view, save). In this case, where all is handled exclusively through the XWiki model, Scribo would be plugged as an external service performing periodic updates between the XWiki instance and its RDF store. See more details about this solution at: http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution2XWiki... Pros: uses the xwiki object model 100%, there's no reimplementing of the whole process of saving, editing objects, etc, the forms and views are light customizations of standard XWiki mechanisms Cons: the annotation mapping to document source cannot be implemented straightforward (there are changes needed in the architecture and algorithm), Scribo (or any other storage model different from XWiki) would need to duplicate data, and it would not be 100% real time (since it would be a periodical synchronizer) The current implementation is illustrated in the http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HCurrentImpleme... section. I like the elegance of the first solution more, for the way a different storage can be easily plugged, but I don't like that we're reimplementing a lot of XWiki objects manipulation (which is why 2 would be a better solution). WDYT? Thanks, Anca
I like the ideas, but how hard would it be to add semantic annotations to the todo list? Thanks in advance, Chris -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Anca Luca Sent: Tuesday, October 20, 2009 10:12 AM To: XWiki Developers Subject: [xwiki-devs] [Discussion] Annotations improvements -- allowing different annotation types Hi devs, Following the previous mail with the desired improvements for the annotation feature, I would like to discuss some options for implementing the first of the enhancements, namely the ability to configure easily the type of added annotation. (see http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HFeaturesimprov ements for details). Two alternatives for this would be: A) to preserve the current architecture of the annotations plugin and only add a map of "extra fields" to the annotation type. The type of the annotation would be known by the js client through the configuration of an XWiki class and the js client would create a "generic" form for any such type. See more details about this solution at http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution1extra fieldsintheAnnotationclass . Pros: preserves the current annotations architecture, creates an easy way to plug an annotation storage service Cons: the Annotation class would be nothing else but a "BaseCollection" the same as a generic XWiki object, and we would be reimplementing view, save, edit, delete of this type (already implemented through the xwiki action) from the web forms level (editing and displaying an annotation), through the controller (REST this time instead of actions in the standard wiki servlet), to the storage level (XWikiIOService will only transform a map (the Annotation class) to another map (the XWikiObject in the xwiki document)). B) to make an XWiki object model based implementation where the js client, to create the UI, would just asynchronously fetch standard actions in XWiki (edit, view, save). In this case, where all is handled exclusively through the XWiki model, Scribo would be plugged as an external service performing periodic updates between the XWiki instance and its RDF store. See more details about this solution at: http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution2XWiki objectsmodelbasedimplementation Pros: uses the xwiki object model 100%, there's no reimplementing of the whole process of saving, editing objects, etc, the forms and views are light customizations of standard XWiki mechanisms Cons: the annotation mapping to document source cannot be implemented straightforward (there are changes needed in the architecture and algorithm), Scribo (or any other storage model different from XWiki) would need to duplicate data, and it would not be 100% real time (since it would be a periodical synchronizer) The current implementation is illustrated in the http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HCurrentImpleme ntation section. I like the elegance of the first solution more, for the way a different storage can be easily plugged, but I don't like that we're reimplementing a lot of XWiki objects manipulation (which is why 2 would be a better solution). WDYT? Thanks, Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Chris, On 10/22/2009 03:25 AM, Chris Mitchell wrote:
I like the ideas, but how hard would it be to add semantic annotations to the todo list?
I'm not sure I understand right what do you mean by semantic annotations, but if it's about automatically extracting information from wiki documents and labeling it with various metadata, this is exactly what the Scribo project aims to do, which is using the annotation system I am discussing as a presentation and input method for those annotations. See http://www.scribo.ws for more information. Thanks, Anca
Thanks in advance,
Chris
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Anca Luca Sent: Tuesday, October 20, 2009 10:12 AM To: XWiki Developers Subject: [xwiki-devs] [Discussion] Annotations improvements -- allowing different annotation types
Hi devs,
Following the previous mail with the desired improvements for the annotation feature, I would like to discuss some options for implementing the first of the enhancements, namely the ability to configure easily the type of added annotation. (see http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HFeaturesimprov ements for details).
Two alternatives for this would be:
A) to preserve the current architecture of the annotations plugin and only add a map of "extra fields" to the annotation type. The type of the annotation would be known by the js client through the configuration of an XWiki class and the js client would create a "generic" form for any such type. See more details about this solution at http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution1extra fieldsintheAnnotationclass .
Pros: preserves the current annotations architecture, creates an easy way to plug an annotation storage service
Cons: the Annotation class would be nothing else but a "BaseCollection" the same as a generic XWiki object, and we would be reimplementing view, save, edit, delete of this type (already implemented through the xwiki action) from the web forms level (editing and displaying an annotation), through the controller (REST this time instead of actions in the standard wiki servlet), to the storage level (XWikiIOService will only transform a map (the Annotation class) to another map (the XWikiObject in the xwiki document)).
B) to make an XWiki object model based implementation where the js client, to create the UI, would just asynchronously fetch standard actions in XWiki (edit, view, save). In this case, where all is handled exclusively through the XWiki model, Scribo would be plugged as an external service performing periodic updates between the XWiki instance and its RDF store.
See more details about this solution at: http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution2XWiki objectsmodelbasedimplementation
Pros: uses the xwiki object model 100%, there's no reimplementing of the whole process of saving, editing objects, etc, the forms and views are light customizations of standard XWiki mechanisms
Cons: the annotation mapping to document source cannot be implemented straightforward (there are changes needed in the architecture and algorithm), Scribo (or any other storage model different from XWiki) would need to duplicate data, and it would not be 100% real time (since it would be a periodical synchronizer)
The current implementation is illustrated in the http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HCurrentImpleme ntation section.
I like the elegance of the first solution more, for the way a different storage can be easily plugged, but I don't like that we're reimplementing a lot of XWiki objects manipulation (which is why 2 would be a better solution).
WDYT?
Thanks, Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
Anca Luca -
Chris Mitchell