[Discussion] Annotations improvements -- allowing different annotation types

[Anca Luca]

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#HFeaturesimprovements 
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#HSolution1extrafieldsintheAnnotationclass 
.

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#HSolution2XWikiobjectsmodelbasedimplementation

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#HCurrentImplementation 
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[Chris Mitchell]

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: [hidden email] [mailto:[hidden email]] 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[Anca Luca]

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: [hidden email] [mailto:[hidden email]] 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs