[Discussion] Annotations feature current state and roadmap

[Anca Luca]

Hello devs,

The current state of the annotation feature in the sandbox can be described by
the follwing:
* there is a single type of annotation which can be added, using a specific
javascript client backed by a rest service. Such an annotation contains an
annotation text, the annotated content and its position and this type is highly
coupled in the plugin implementation
* the backing annotation storage is based on components, currently with an XWiki
objects implementation but a different service can be easily created (there is
one implemented for Scribo annotations stored in RDF)
* for the moment, only xwiki documents and feed entries fetched by the
feedreader plugin can be used as targets for annotations (the annotated
documents), with the restriction that the content of the document is *not*
generated using scripting. A component can be implemented for a new type of
document but the current UI (the javascript client) is *specific to xwiki documents*
* the javascript client (UI) is only in the state of a prototype: while proving
that it works, it is not robust enough and the user experience is poor
* annotation creation algorithm seems to perform well in practice, but we should
put it to more real-world test (by releasing).

Some *requirements* in terms of functionality, in order to make this an
extensible and flexible feature, would be to:
* be able to have different types of annotations (one to be able to easily
specify fields for the annotations to add), with storage as xwiki objects. This
needs to be flexible at all levels: UI and storage backend, preferably using
xwiki scripting (no jars on the server side, or java coding) so that it can be
easily customized. Also, the annotation UI should be thought of as easy to
customize and create whatever forms and actions in a light manner.
* be able to annotate any type of document (object inside such a document),
namely all or any number of text fields in such an object. Preferably this
should also be doable only using xwiki scripting or configuration.

I would like to propose the following road to perfect this feature:
*Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
The aim would be to take feature out of sandbox preserving its current features:
allowing to add a specific type of annotation saved as XWiki object on a
regular, non scripted XWiki Document. We should:
- format, improve comments, generally clean up the current code sandbox to match
XWiki coding styles
- refactor packages and components to remove some dependencies issues and
increase flexibility
- simplify flow, stripping out all code which is not strictly needed by the
targeted functionality (such as the Feed entry handling code), and make it
easily implementable by a component in a distinct jar (so that the Scribo
requirements currently implemented can be preserved)
- finish the javascript client: robust user interaction, intuitive interface,
cleaned up integration with XE
- ensure quality assurance process by a well setup battery of tests, unit and
functional
At this point I propose to have the annotation feature as an installable plugin
but not included by default in XE, unless after a few bugfixing cycles.

*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next year)
* first iteration on the 2 desired features. At this point one should be able to
configure the type of annotation to add, UI should be accomodate this type,
backing XWiki storage should be easy to integrate with any annotation storage
service (for Scribo requirements), and one should easily set a field in a
structured document which would support annotations. (Note that this might
require heavy rewrite / refactor of the 1.0 version. We could decide to skip it
and go straight to this version, but it would take longer.)
* integration of Scribo requirements can be met at this point by setting the
configurations according to the Scribo annotation type and target requirements.
At this point, if we find appropriate, we could make the decision of including
the annotation feature in XE by default

*Version 1.2* (future)
* finish the 2 requirements, integration with Scribo would be done in the same
manner, by specific configuration and storage backend specific implementation.

What do you think?

For the moment I will focus on version 1's tasks while finding a good
architecture to achieve the desired requirements, converting, where necessary,
the direction of the development towards that goal.

Thanks (for reading this very long mail),
Anca
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[Guillaume Lerouge]

Hi Anca,

On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca <[hidden email]>wrote:

> Hello devs,
>
> The current state of the annotation feature in the sandbox can be described
> by
> the following:
> * there is a single type of annotation which can be added, using a specific
> javascript client backed by a rest service. Such an annotation contains an
> annotation text, the annotated content and its position and this type is
> highly
> coupled in the plugin implementation
> * the backing annotation storage is based on components, currently with an
> XWiki
> objects implementation but a different service can be easily created (there
> is
> one implemented for Scribo annotations stored in RDF)
> * for the moment, only xwiki documents and feed entries fetched by the
> feedreader plugin can be used as targets for annotations (the annotated
> documents), with the restriction that the content of the document is *not*
> generated using scripting. A component can be implemented for a new type of
> document but the current UI (the javascript client) is *specific to xwiki
> documents*
> * the javascript client (UI) is only in the state of a prototype: while
> proving
> that it works, it is not robust enough and the user experience is poor
> * annotation creation algorithm seems to perform well in practice, but we
> should
> put it to more real-world test (by releasing).
>
> Some *requirements* in terms of functionality, in order to make this an
> extensible and flexible feature, would be to:
> * be able to have different types of annotations (one to be able to easily
> specify fields for the annotations to add), with storage as xwiki objects.
> This
> needs to be flexible at all levels: UI and storage backend, preferably
> using
> xwiki scripting (no jars on the server side, or java coding) so that it can
> be
> easily customized. Also, the annotation UI should be thought of as easy to
> customize and create whatever forms and actions in a light manner.
>

I'm not sure I understand this one well. What exactly do you mean by
"different types of annotations"? From what I understand right now, this
means the following:

   1. I select text and choose to annotate it
   2. I select custom properties for my annotation (let's say additional
   "city" & "country" fields)
   3. I fill in those fields and save the annotation
   4. My annotation is saved with those custom fields

If this is correct, I'm a bit afraid this will bring un-needed complexity
both to the UI and the backend implementation. From what I understood so far
it looks a bit like having the XClass editor each time ones creates a new
annotation -> isn't that overkill?

An alternative solution I was thinking about was to use only 1 field with a
semantic syntax & autosuggest (something like: @city:Paris @country:France).
Is that a possible option? Or maybe it doesn't make sense in the context or
your work?

Yet another option would be to offer a number of already configured types to
select from in a list when adding a new annotation.


> * be able to annotate any type of document (object inside such a document),
> namely all or any number of text fields in such an object. Preferably this
> should also be doable only using xwiki scripting or configuration.
>

Sounds good.

I would like to propose the following road to perfect this feature:

> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
> The aim would be to take feature out of sandbox preserving its current
> features:
> allowing to add a specific type of annotation saved as XWiki object on a
> regular, non scripted XWiki Document. We should:
> - format, improve comments, generally clean up the current code sandbox to
> match
> XWiki coding styles
> - refactor packages and components to remove some dependencies issues and
> increase flexibility
> - simplify flow, stripping out all code which is not strictly needed by the
> targeted functionality (such as the Feed entry handling code), and make it
> easily implementable by a component in a distinct jar (so that the Scribo
> requirements currently implemented can be preserved)
> - finish the javascript client: robust user interaction, intuitive
> interface,
> cleaned up integration with XE
>

Do you plan on using GWT to achieve this? If not, what's the best way to
code it in a cross-browser, maintainable way? Using one of the JS library
already embedded in XWiki such as Prototype I guess?


> - ensure quality assurance process by a well setup battery of tests, unit
> and
> functional
> At this point I propose to have the annotation feature as an installable
> plugin
> but not included by default in XE, unless after a few bugfixing cycles.
>

Plugin or component? (maybe this is the same thing under a different name)

*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next

> year)
> * first iteration on the 2 desired features. At this point one should be
> able to
> configure the type of annotation to add, UI should be accomodate this type,
> backing XWiki storage should be easy to integrate with any annotation
> storage
> service (for Scribo requirements), and one should easily set a field in a
> structured document which would support annotations. (Note that this might
> require heavy rewrite / refactor of the 1.0 version. We could decide to
> skip it
> and go straight to this version, but it would take longer.)
>

My personal point of view is that being able to annotate any part of a XWiki
document is more important than being able to configure the type of
annotation to add. Is there a hard requirement on the order from the Scribo
research project on this?


> * integration of Scribo requirements can be met at this point by setting
> the
> configurations according to the Scribo annotation type and target
> requirements.
> At this point, if we find appropriate, we could make the decision of
> including
> the annotation feature in XE by default
>

I guess that will depend on its quality by this time. I think it would be a
great addition to XE's default feature set.

*Version 1.2* (future)
> * finish the 2 requirements, integration with Scribo would be done in the
> same
> manner, by specific configuration and storage backend specific
> implementation.
>
> What do you think?
>

I think this can become a key differentiating feature of XWiki since I'm not
aware of any wiki that has them implemented yet. MS Word's annotation system
is widely used and I think XWiki annotation would resonate positively with
XWiki users coming from such text editors.

For the moment I will focus on version 1's tasks while finding a good
> architecture to achieve the desired requirements, converting, where
> necessary,
> the direction of the development towards that goal.
>
> Thanks (for reading this very long mail),
>

:-)

Guillaume


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



--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[vmassol]

On Oct 14, 2009, at 10:03 PM, Anca Luca wrote:

> Hello devs,
>
> The current state of the annotation feature in the sandbox can be  
> described by
> the follwing:
> * there is a single type of annotation which can be added, using a  
> specific
> javascript client backed by a rest service. Such an annotation  
> contains an
> annotation text, the annotated content and its position and this  
> type is highly
> coupled in the plugin implementation
> * the backing annotation storage is based on components, currently  
> with an XWiki
> objects implementation but a different service can be easily created  
> (there is
> one implemented for Scribo annotations stored in RDF)
> * for the moment, only xwiki documents and feed entries fetched by the
> feedreader plugin can be used as targets for annotations (the  
> annotated
> documents), with the restriction that the content of the document is  
> *not*
> generated using scripting. A component can be implemented for a new  
> type of
> document but the current UI (the javascript client) is *specific to  
> xwiki documents*
> * the javascript client (UI) is only in the state of a prototype:  
> while proving
> that it works, it is not robust enough and the user experience is poor
> * annotation creation algorithm seems to perform well in practice,  
> but we should
> put it to more real-world test (by releasing).
>
> Some *requirements* in terms of functionality, in order to make this  
> an
> extensible and flexible feature, would be to:
> * be able to have different types of annotations (one to be able to  
> easily
> specify fields for the annotations to add), with storage as xwiki  
> objects. This
> needs to be flexible at all levels: UI and storage backend,  
> preferably using
> xwiki scripting (no jars on the server side, or java coding) so that  
> it can be
> easily customized. Also, the annotation UI should be thought of as  
> easy to
> customize and create whatever forms and actions in a light manner.
> * be able to annotate any type of document (object inside such a  
> document),
> namely all or any number of text fields in such an object.  
> Preferably this
> should also be doable only using xwiki scripting or configuration.
>
> I would like to propose the following road to perfect this feature:
> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
> The aim would be to take feature out of sandbox preserving its  
> current features:
> allowing to add a specific type of annotation saved as XWiki object  
> on a
> regular, non scripted XWiki Document. We should:
> - format, improve comments, generally clean up the current code  
> sandbox to match
> XWiki coding styles
> - refactor packages and components to remove some dependencies  
> issues and
> increase flexibility
> - simplify flow, stripping out all code which is not strictly needed  
> by the
> targeted functionality (such as the Feed entry handling code), and  
> make it
> easily implementable by a component in a distinct jar (so that the  
> Scribo
> requirements currently implemented can be preserved)
> - finish the javascript client: robust user interaction, intuitive  
> interface,
> cleaned up integration with XE
> - ensure quality assurance process by a well setup battery of tests,  
> unit and
> functional
> At this point I propose to have the annotation feature as an  
> installable plugin
> but not included by default in XE, unless after a few bugfixing  
> cycles.

Sounds good. What do you miss to make it use the "new" architecture  
fully?

Thanks
-Vincent

>
> *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning  
> of next year)
> * first iteration on the 2 desired features. At this point one  
> should be able to
> configure the type of annotation to add, UI should be accomodate  
> this type,
> backing XWiki storage should be easy to integrate with any  
> annotation storage
> service (for Scribo requirements), and one should easily set a field  
> in a
> structured document which would support annotations. (Note that this  
> might
> require heavy rewrite / refactor of the 1.0 version. We could decide  
> to skip it
> and go straight to this version, but it would take longer.)
> * integration of Scribo requirements can be met at this point by  
> setting the
> configurations according to the Scribo annotation type and target  
> requirements.
> At this point, if we find appropriate, we could make the decision of  
> including
> the annotation feature in XE by default
>
> *Version 1.2* (future)
> * finish the 2 requirements, integration with Scribo would be done  
> in the same
> manner, by specific configuration and storage backend specific  
> implementation.
>
> What do you think?
>
> For the moment I will focus on version 1's tasks while finding a good
> architecture to achieve the desired requirements, converting, where  
> necessary,
> the direction of the development towards that goal.
>
> Thanks (for reading this very long mail),
> Anca

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

[Anca Luca]

Hi Guillaume,

Guillaume Lerouge wrote:

> Hi Anca,
>
> On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca <[hidden email]>wrote:
>
>> Hello devs,
>>
>> The current state of the annotation feature in the sandbox can be described
>> by
>> the following:
>> * there is a single type of annotation which can be added, using a specific
>> javascript client backed by a rest service. Such an annotation contains an
>> annotation text, the annotated content and its position and this type is
>> highly
>> coupled in the plugin implementation
>> * the backing annotation storage is based on components, currently with an
>> XWiki
>> objects implementation but a different service can be easily created (there
>> is
>> one implemented for Scribo annotations stored in RDF)
>> * for the moment, only xwiki documents and feed entries fetched by the
>> feedreader plugin can be used as targets for annotations (the annotated
>> documents), with the restriction that the content of the document is *not*
>> generated using scripting. A component can be implemented for a new type of
>> document but the current UI (the javascript client) is *specific to xwiki
>> documents*
>> * the javascript client (UI) is only in the state of a prototype: while
>> proving
>> that it works, it is not robust enough and the user experience is poor
>> * annotation creation algorithm seems to perform well in practice, but we
>> should
>> put it to more real-world test (by releasing).
>>
>> Some *requirements* in terms of functionality, in order to make this an
>> extensible and flexible feature, would be to:
>> * be able to have different types of annotations (one to be able to easily
>> specify fields for the annotations to add), with storage as xwiki objects.
>> This
>> needs to be flexible at all levels: UI and storage backend, preferably
>> using
>> xwiki scripting (no jars on the server side, or java coding) so that it can
>> be
>> easily customized. Also, the annotation UI should be thought of as easy to
>> customize and create whatever forms and actions in a light manner.
>>
>
> I'm not sure I understand this one well. What exactly do you mean by
> "different types of annotations"? From what I understand right now, this
> means the following:
>
>    1. I select text and choose to annotate it
>    2. I select custom properties for my annotation (let's say additional
>    "city" & "country" fields)
>    3. I fill in those fields and save the annotation
>    4. My annotation is saved with those custom fields
>
> If this is correct, I'm a bit afraid this will bring un-needed complexity
> both to the UI and the backend implementation. From what I understood so far
> it looks a bit like having the XClass editor each time ones creates a new
> annotation -> isn't that overkill?
>
> An alternative solution I was thinking about was to use only 1 field with a
> semantic syntax & autosuggest (something like: @city:Paris @country:France).
> Is that a possible option? Or maybe it doesn't make sense in the context or
> your work?
>
> Yet another option would be to offer a number of already configured types to
> select from in a list when adding a new annotation.

Not exactly.
The idea was that an admin or a wiki programmer could configure the annotation
application (such as setting an XWiki class as the annotation type) and then
whenever a user adds an annotation, he will get, in the annotation "bubble", a
form to edit an object from that class. Right now, to do that, you'd need to
write a few java components & rewrite the js client. The idea is to have that
easily configurable, "scriptable" from the wiki.

>
>
>> * be able to annotate any type of document (object inside such a document),
>> namely all or any number of text fields in such an object. Preferably this
>> should also be doable only using xwiki scripting or configuration.
>>
>
> Sounds good.
>
> I would like to propose the following road to perfect this feature:
>> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
>> The aim would be to take feature out of sandbox preserving its current
>> features:
>> allowing to add a specific type of annotation saved as XWiki object on a
>> regular, non scripted XWiki Document. We should:
>> - format, improve comments, generally clean up the current code sandbox to
>> match
>> XWiki coding styles
>> - refactor packages and components to remove some dependencies issues and
>> increase flexibility
>> - simplify flow, stripping out all code which is not strictly needed by the
>> targeted functionality (such as the Feed entry handling code), and make it
>> easily implementable by a component in a distinct jar (so that the Scribo
>> requirements currently implemented can be preserved)
>> - finish the javascript client: robust user interaction, intuitive
>> interface,
>> cleaned up integration with XE
>>
>
> Do you plan on using GWT to achieve this? If not, what's the best way to
> code it in a cross-browser, maintainable way? Using one of the JS library
> already embedded in XWiki such as Prototype I guess?

I don't have a plan.

>
>
>> - ensure quality assurance process by a well setup battery of tests, unit
>> and
>> functional
>> At this point I propose to have the annotation feature as an installable
>> plugin
>> but not included by default in XE, unless after a few bugfixing cycles.
>>
>
> Plugin or component? (maybe this is the same thing under a different name)

Application with server side code, I don't know exactly how this would be called.

>
> *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next
>> year)
>> * first iteration on the 2 desired features. At this point one should be
>> able to
>> configure the type of annotation to add, UI should be accomodate this type,
>> backing XWiki storage should be easy to integrate with any annotation
>> storage
>> service (for Scribo requirements), and one should easily set a field in a
>> structured document which would support annotations. (Note that this might
>> require heavy rewrite / refactor of the 1.0 version. We could decide to
>> skip it
>> and go straight to this version, but it would take longer.)
>>
>
> My personal point of view is that being able to annotate any part of a XWiki
> document is more important than being able to configure the type of
> annotation to add. Is there a hard requirement on the order from the Scribo
> research project on this?

No, it's not atm afaik, although Scribo could be implemented like that (Scribo
annotations are structured, not only a piece of text, even if "serializable" as
a text).

Actually this point is supposed to be an iteration in both directions (not only
about typed annotations leaving behind the second requirement), and for the
annotation target I specified:

 >> and one should easily set a field in a
 >> structured document which would support annotations.

>
>
>> * integration of Scribo requirements can be met at this point by setting
>> the
>> configurations according to the Scribo annotation type and target
>> requirements.
>> At this point, if we find appropriate, we could make the decision of
>> including
>> the annotation feature in XE by default
>>
>
> I guess that will depend on its quality by this time. I think it would be a
> great addition to XE's default feature set.
>
> *Version 1.2* (future)
>> * finish the 2 requirements, integration with Scribo would be done in the
>> same
>> manner, by specific configuration and storage backend specific
>> implementation.
>>
>> What do you think?
>>
>
> I think this can become a key differentiating feature of XWiki since I'm not
> aware of any wiki that has them implemented yet. MS Word's annotation system
> is widely used and I think XWiki annotation would resonate positively with
> XWiki users coming from such text editors.
>
> For the moment I will focus on version 1's tasks while finding a good
>> architecture to achieve the desired requirements, converting, where
>> necessary,
>> the direction of the development towards that goal.
>>
>> Thanks (for reading this very long mail),
>>
>
> :-)

Thanks,
Anca

>
> Guillaume
>
>
>> 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]

Vincent Massol wrote:

> On Oct 14, 2009, at 10:03 PM, Anca Luca wrote:
>
>> Hello devs,
>>
>> The current state of the annotation feature in the sandbox can be  
>> described by
>> the follwing:
>> * there is a single type of annotation which can be added, using a  
>> specific
>> javascript client backed by a rest service. Such an annotation  
>> contains an
>> annotation text, the annotated content and its position and this  
>> type is highly
>> coupled in the plugin implementation
>> * the backing annotation storage is based on components, currently  
>> with an XWiki
>> objects implementation but a different service can be easily created  
>> (there is
>> one implemented for Scribo annotations stored in RDF)
>> * for the moment, only xwiki documents and feed entries fetched by the
>> feedreader plugin can be used as targets for annotations (the  
>> annotated
>> documents), with the restriction that the content of the document is  
>> *not*
>> generated using scripting. A component can be implemented for a new  
>> type of
>> document but the current UI (the javascript client) is *specific to  
>> xwiki documents*
>> * the javascript client (UI) is only in the state of a prototype:  
>> while proving
>> that it works, it is not robust enough and the user experience is poor
>> * annotation creation algorithm seems to perform well in practice,  
>> but we should
>> put it to more real-world test (by releasing).
>>
>> Some *requirements* in terms of functionality, in order to make this  
>> an
>> extensible and flexible feature, would be to:
>> * be able to have different types of annotations (one to be able to  
>> easily
>> specify fields for the annotations to add), with storage as xwiki  
>> objects. This
>> needs to be flexible at all levels: UI and storage backend,  
>> preferably using
>> xwiki scripting (no jars on the server side, or java coding) so that  
>> it can be
>> easily customized. Also, the annotation UI should be thought of as  
>> easy to
>> customize and create whatever forms and actions in a light manner.
>> * be able to annotate any type of document (object inside such a  
>> document),
>> namely all or any number of text fields in such an object.  
>> Preferably this
>> should also be doable only using xwiki scripting or configuration.
>>
>> I would like to propose the following road to perfect this feature:
>> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
>> The aim would be to take feature out of sandbox preserving its  
>> current features:
>> allowing to add a specific type of annotation saved as XWiki object  
>> on a
>> regular, non scripted XWiki Document. We should:
>> - format, improve comments, generally clean up the current code  
>> sandbox to match
>> XWiki coding styles
>> - refactor packages and components to remove some dependencies  
>> issues and
>> increase flexibility
>> - simplify flow, stripping out all code which is not strictly needed  
>> by the
>> targeted functionality (such as the Feed entry handling code), and  
>> make it
>> easily implementable by a component in a distinct jar (so that the  
>> Scribo
>> requirements currently implemented can be preserved)
>> - finish the javascript client: robust user interaction, intuitive  
>> interface,
>> cleaned up integration with XE
>> - ensure quality assurance process by a well setup battery of tests,  
>> unit and
>> functional
>> At this point I propose to have the annotation feature as an  
>> installable plugin
>> but not included by default in XE, unless after a few bugfixing  
>> cycles.
>
> Sounds good. What do you miss to make it use the "new" architecture  
> fully?

Hi Vincent,
I don't think I fully understand what you mean. Can you rephrase, please?

Thanks,
Anca

>
> Thanks
> -Vincent
>
>> *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning  
>> of next year)
>> * first iteration on the 2 desired features. At this point one  
>> should be able to
>> configure the type of annotation to add, UI should be accomodate  
>> this type,
>> backing XWiki storage should be easy to integrate with any  
>> annotation storage
>> service (for Scribo requirements), and one should easily set a field  
>> in a
>> structured document which would support annotations. (Note that this  
>> might
>> require heavy rewrite / refactor of the 1.0 version. We could decide  
>> to skip it
>> and go straight to this version, but it would take longer.)
>> * integration of Scribo requirements can be met at this point by  
>> setting the
>> configurations according to the Scribo annotation type and target  
>> requirements.
>> At this point, if we find appropriate, we could make the decision of  
>> including
>> the annotation feature in XE by default
>>
>> *Version 1.2* (future)
>> * finish the 2 requirements, integration with Scribo would be done  
>> in the same
>> manner, by specific configuration and storage backend specific  
>> implementation.
>>
>> What do you think?
>>
>> For the moment I will focus on version 1's tasks while finding a good
>> architecture to achieve the desired requirements, converting, where  
>> necessary,
>> the direction of the development towards that goal.
>>
>> Thanks (for reading this very long mail),
>> 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

[vmassol]

On Oct 15, 2009, at 9:08 PM, Anca Luca wrote:

> Vincent Massol wrote:
>> On Oct 14, 2009, at 10:03 PM, Anca Luca wrote:
>>
>>> Hello devs,
>>>
>>> The current state of the annotation feature in the sandbox can be
>>> described by
>>> the follwing:
>>> * there is a single type of annotation which can be added, using a
>>> specific
>>> javascript client backed by a rest service. Such an annotation
>>> contains an
>>> annotation text, the annotated content and its position and this
>>> type is highly
>>> coupled in the plugin implementation
>>> * the backing annotation storage is based on components, currently
>>> with an XWiki
>>> objects implementation but a different service can be easily created
>>> (there is
>>> one implemented for Scribo annotations stored in RDF)
>>> * for the moment, only xwiki documents and feed entries fetched by  
>>> the
>>> feedreader plugin can be used as targets for annotations (the
>>> annotated
>>> documents), with the restriction that the content of the document is
>>> *not*
>>> generated using scripting. A component can be implemented for a new
>>> type of
>>> document but the current UI (the javascript client) is *specific to
>>> xwiki documents*
>>> * the javascript client (UI) is only in the state of a prototype:
>>> while proving
>>> that it works, it is not robust enough and the user experience is  
>>> poor
>>> * annotation creation algorithm seems to perform well in practice,
>>> but we should
>>> put it to more real-world test (by releasing).
>>>
>>> Some *requirements* in terms of functionality, in order to make this
>>> an
>>> extensible and flexible feature, would be to:
>>> * be able to have different types of annotations (one to be able to
>>> easily
>>> specify fields for the annotations to add), with storage as xwiki
>>> objects. This
>>> needs to be flexible at all levels: UI and storage backend,
>>> preferably using
>>> xwiki scripting (no jars on the server side, or java coding) so that
>>> it can be
>>> easily customized. Also, the annotation UI should be thought of as
>>> easy to
>>> customize and create whatever forms and actions in a light manner.
>>> * be able to annotate any type of document (object inside such a
>>> document),
>>> namely all or any number of text fields in such an object.
>>> Preferably this
>>> should also be doable only using xwiki scripting or configuration.
>>>
>>> I would like to propose the following road to perfect this feature:
>>> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
>>> The aim would be to take feature out of sandbox preserving its
>>> current features:
>>> allowing to add a specific type of annotation saved as XWiki object
>>> on a
>>> regular, non scripted XWiki Document. We should:
>>> - format, improve comments, generally clean up the current code
>>> sandbox to match
>>> XWiki coding styles
>>> - refactor packages and components to remove some dependencies
>>> issues and
>>> increase flexibility
>>> - simplify flow, stripping out all code which is not strictly needed
>>> by the
>>> targeted functionality (such as the Feed entry handling code), and
>>> make it
>>> easily implementable by a component in a distinct jar (so that the
>>> Scribo
>>> requirements currently implemented can be preserved)
>>> - finish the javascript client: robust user interaction, intuitive
>>> interface,
>>> cleaned up integration with XE
>>> - ensure quality assurance process by a well setup battery of tests,
>>> unit and
>>> functional
>>> At this point I propose to have the annotation feature as an
>>> installable plugin
>>> but not included by default in XE, unless after a few bugfixing
>>> cycles.
>>
>> Sounds good. What do you miss to make it use the "new" architecture
>> fully?
>
> Hi Vincent,
> I don't think I fully understand what you mean. Can you rephrase,  
> please?

I meant using components and not plugins.

Thanks
-Vincent

>
> Thanks,
> Anca
>
>>
>> Thanks
>> -Vincent
>>
>>> *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning
>>> of next year)
>>> * first iteration on the 2 desired features. At this point one
>>> should be able to
>>> configure the type of annotation to add, UI should be accomodate
>>> this type,
>>> backing XWiki storage should be easy to integrate with any
>>> annotation storage
>>> service (for Scribo requirements), and one should easily set a field
>>> in a
>>> structured document which would support annotations. (Note that this
>>> might
>>> require heavy rewrite / refactor of the 1.0 version. We could decide
>>> to skip it
>>> and go straight to this version, but it would take longer.)
>>> * integration of Scribo requirements can be met at this point by
>>> setting the
>>> configurations according to the Scribo annotation type and target
>>> requirements.
>>> At this point, if we find appropriate, we could make the decision of
>>> including
>>> the annotation feature in XE by default
>>>
>>> *Version 1.2* (future)
>>> * finish the 2 requirements, integration with Scribo would be done
>>> in the same
>>> manner, by specific configuration and storage backend specific
>>> implementation.
>>>
>>> What do you think?
>>>
>>> For the moment I will focus on version 1's tasks while finding a  
>>> good
>>> architecture to achieve the desired requirements, converting, where
>>> necessary,
>>> the direction of the development towards that goal.
>>>
>>> Thanks (for reading this very long mail),
>>> Anca

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

[Guillaume Lerouge]

Hi Anca,

On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca <[hidden email]> wrote:

> Hi Guillaume,
>
> Guillaume Lerouge wrote:
> > Hi Anca,
> >
> > On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca <[hidden email]
> >wrote:
> >
> >> Hello devs,
> >>
> >> The current state of the annotation feature in the sandbox can be
> described
> >> by
> >> the following:
> >> * there is a single type of annotation which can be added, using a
> specific
> >> javascript client backed by a rest service. Such an annotation contains
> an
> >> annotation text, the annotated content and its position and this type is
> >> highly
> >> coupled in the plugin implementation
> >> * the backing annotation storage is based on components, currently with
> an
> >> XWiki
> >> objects implementation but a different service can be easily created
> (there
> >> is
> >> one implemented for Scribo annotations stored in RDF)
> >> * for the moment, only xwiki documents and feed entries fetched by the
> >> feedreader plugin can be used as targets for annotations (the annotated
> >> documents), with the restriction that the content of the document is
> *not*
> >> generated using scripting. A component can be implemented for a new type
> of
> >> document but the current UI (the javascript client) is *specific to
> xwiki
> >> documents*
> >> * the javascript client (UI) is only in the state of a prototype: while
> >> proving
> >> that it works, it is not robust enough and the user experience is poor
> >> * annotation creation algorithm seems to perform well in practice, but
> we
> >> should
> >> put it to more real-world test (by releasing).
> >>
> >> Some *requirements* in terms of functionality, in order to make this an
> >> extensible and flexible feature, would be to:
> >> * be able to have different types of annotations (one to be able to
> easily
> >> specify fields for the annotations to add), with storage as xwiki
> objects.
> >> This
> >> needs to be flexible at all levels: UI and storage backend, preferably
> >> using
> >> xwiki scripting (no jars on the server side, or java coding) so that it
> can
> >> be
> >> easily customized. Also, the annotation UI should be thought of as easy
> to
> >> customize and create whatever forms and actions in a light manner.
> >>
> >
> > I'm not sure I understand this one well. What exactly do you mean by
> > "different types of annotations"? From what I understand right now, this
> > means the following:
> >
> >    1. I select text and choose to annotate it
> >    2. I select custom properties for my annotation (let's say additional
> >    "city" & "country" fields)
> >    3. I fill in those fields and save the annotation
> >    4. My annotation is saved with those custom fields
> >
> > If this is correct, I'm a bit afraid this will bring un-needed complexity
> > both to the UI and the backend implementation. From what I understood so
> far
> > it looks a bit like having the XClass editor each time ones creates a new
> > annotation -> isn't that overkill?
> >
> > An alternative solution I was thinking about was to use only 1 field with
> a
> > semantic syntax & autosuggest (something like: @city:Paris
> @country:France).
> > Is that a possible option? Or maybe it doesn't make sense in the context
> or
> > your work?
> >
> > Yet another option would be to offer a number of already configured types
> to
> > select from in a list when adding a new annotation.
>
> Not exactly.
> The idea was that an admin or a wiki programmer could configure the
> annotation
> application (such as setting an XWiki class as the annotation type) and
> then
> whenever a user adds an annotation, he will get, in the annotation
> "bubble", a
> form to edit an object from that class. Right now, to do that, you'd need
> to
> write a few java components & rewrite the js client. The idea is to have
> that
> easily configurable, "scriptable" from the wiki.
>

Ok, thanks for the clarification :-)

Sounds good to me since it's not too complex for users but at the same time
addresses Scribo's needs (if I understood those correctly).

> >> * be able to annotate any type of document (object inside such a
> document),
> >> namely all or any number of text fields in such an object. Preferably
> this
> >> should also be doable only using xwiki scripting or configuration.
> >>
> >
> > Sounds good.
> >
> > I would like to propose the following road to perfect this feature:
> >> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
> >> The aim would be to take feature out of sandbox preserving its current
> >> features:
> >> allowing to add a specific type of annotation saved as XWiki object on a
> >> regular, non scripted XWiki Document. We should:
> >> - format, improve comments, generally clean up the current code sandbox
> to
> >> match
> >> XWiki coding styles
> >> - refactor packages and components to remove some dependencies issues
> and
> >> increase flexibility
> >> - simplify flow, stripping out all code which is not strictly needed by
> the
> >> targeted functionality (such as the Feed entry handling code), and make
> it
> >> easily implementable by a component in a distinct jar (so that the
> Scribo
> >> requirements currently implemented can be preserved)
> >> - finish the javascript client: robust user interaction, intuitive
> >> interface,
> >> cleaned up integration with XE
> >>
> >
> > Do you plan on using GWT to achieve this? If not, what's the best way to
> > code it in a cross-browser, maintainable way? Using one of the JS library
> > already embedded in XWiki such as Prototype I guess?
>
> I don't have a plan.
>

Good luck.

> >> - ensure quality assurance process by a well setup battery of tests,
> unit
> >> and
> >> functional
> >> At this point I propose to have the annotation feature as an installable
> >> plugin
> >> but not included by default in XE, unless after a few bugfixing cycles.
> >>
> >
> > Plugin or component? (maybe this is the same thing under a different
> name)
>
> Application with server side code, I don't know exactly how this would be
> called.
>
> >
> > *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of
> next
> >> year)
> >> * first iteration on the 2 desired features. At this point one should be
> >> able to
> >> configure the type of annotation to add, UI should be accomodate this
> type,
> >> backing XWiki storage should be easy to integrate with any annotation
> >> storage
> >> service (for Scribo requirements), and one should easily set a field in
> a
> >> structured document which would support annotations. (Note that this
> might
> >> require heavy rewrite / refactor of the 1.0 version. We could decide to
> >> skip it
> >> and go straight to this version, but it would take longer.)
> >>
> >
> > My personal point of view is that being able to annotate any part of a
> XWiki
> > document is more important than being able to configure the type of
> > annotation to add. Is there a hard requirement on the order from the
> Scribo
> > research project on this?
>
> No, it's not atm afaik, although Scribo could be implemented like that
> (Scribo
> annotations are structured, not only a piece of text, even if
> "serializable" as
> a text).
>
> Actually this point is supposed to be an iteration in both directions (not
> only
> about typed annotations leaving behind the second requirement), and for the
> annotation target I specified
>
>  >> and one should easily set a field in a
>  >> structured document which would support annotations.
>

Ok. Sounds good given your above explanation about annotation definition in
a XClass.

Guillaume

> >> * integration of Scribo requirements can be met at this point by setting
> >> the
> >> configurations according to the Scribo annotation type and target
> >> requirements.
> >> At this point, if we find appropriate, we could make the decision of
> >> including
> >> the annotation feature in XE by default
> >>
> >
> > I guess that will depend on its quality by this time. I think it would be
> a
> > great addition to XE's default feature set.
> >
> > *Version 1.2* (future)
> >> * finish the 2 requirements, integration with Scribo would be done in
> the
> >> same
> >> manner, by specific configuration and storage backend specific
> >> implementation.
> >>
> >> What do you think?
> >>
> >
> > I think this can become a key differentiating feature of XWiki since I'm
> not
> > aware of any wiki that has them implemented yet. MS Word's annotation
> system
> > is widely used and I think XWiki annotation would resonate positively
> with
> > XWiki users coming from such text editors.
> >
> > For the moment I will focus on version 1's tasks while finding a good
> >> architecture to achieve the desired requirements, converting, where
> >> necessary,
> >> the direction of the development towards that goal.
> >>
> >> Thanks (for reading this very long mail),
> >>
> >
> > :-)
>
> Thanks,
> Anca
>
> >
> > Guillaume
> >
> >
> >> 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
>

--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[Anca Luca]

On 10/16/2009 10:13 AM, Vincent Massol wrote:

>
> On Oct 15, 2009, at 9:08 PM, Anca Luca wrote:
>
>> Vincent Massol wrote:
>>> On Oct 14, 2009, at 10:03 PM, Anca Luca wrote:
>>>
>>>> Hello devs,
>>>>
>>>> The current state of the annotation feature in the sandbox can be
>>>> described by
>>>> the follwing:
>>>> * there is a single type of annotation which can be added, using a
>>>> specific
>>>> javascript client backed by a rest service. Such an annotation
>>>> contains an
>>>> annotation text, the annotated content and its position and this
>>>> type is highly
>>>> coupled in the plugin implementation
>>>> * the backing annotation storage is based on components, currently
>>>> with an XWiki
>>>> objects implementation but a different service can be easily created
>>>> (there is
>>>> one implemented for Scribo annotations stored in RDF)
>>>> * for the moment, only xwiki documents and feed entries fetched by
>>>> the
>>>> feedreader plugin can be used as targets for annotations (the
>>>> annotated
>>>> documents), with the restriction that the content of the document is
>>>> *not*
>>>> generated using scripting. A component can be implemented for a new
>>>> type of
>>>> document but the current UI (the javascript client) is *specific to
>>>> xwiki documents*
>>>> * the javascript client (UI) is only in the state of a prototype:
>>>> while proving
>>>> that it works, it is not robust enough and the user experience is
>>>> poor
>>>> * annotation creation algorithm seems to perform well in practice,
>>>> but we should
>>>> put it to more real-world test (by releasing).
>>>>
>>>> Some *requirements* in terms of functionality, in order to make this
>>>> an
>>>> extensible and flexible feature, would be to:
>>>> * be able to have different types of annotations (one to be able to
>>>> easily
>>>> specify fields for the annotations to add), with storage as xwiki
>>>> objects. This
>>>> needs to be flexible at all levels: UI and storage backend,
>>>> preferably using
>>>> xwiki scripting (no jars on the server side, or java coding) so that
>>>> it can be
>>>> easily customized. Also, the annotation UI should be thought of as
>>>> easy to
>>>> customize and create whatever forms and actions in a light manner.
>>>> * be able to annotate any type of document (object inside such a
>>>> document),
>>>> namely all or any number of text fields in such an object.
>>>> Preferably this
>>>> should also be doable only using xwiki scripting or configuration.
>>>>
>>>> I would like to propose the following road to perfect this feature:
>>>> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
>>>> The aim would be to take feature out of sandbox preserving its
>>>> current features:
>>>> allowing to add a specific type of annotation saved as XWiki object
>>>> on a
>>>> regular, non scripted XWiki Document. We should:
>>>> - format, improve comments, generally clean up the current code
>>>> sandbox to match
>>>> XWiki coding styles
>>>> - refactor packages and components to remove some dependencies
>>>> issues and
>>>> increase flexibility
>>>> - simplify flow, stripping out all code which is not strictly needed
>>>> by the
>>>> targeted functionality (such as the Feed entry handling code), and
>>>> make it
>>>> easily implementable by a component in a distinct jar (so that the
>>>> Scribo
>>>> requirements currently implemented can be preserved)
>>>> - finish the javascript client: robust user interaction, intuitive
>>>> interface,
>>>> cleaned up integration with XE
>>>> - ensure quality assurance process by a well setup battery of tests,
>>>> unit and
>>>> functional
>>>> At this point I propose to have the annotation feature as an
>>>> installable plugin
>>>> but not included by default in XE, unless after a few bugfixing
>>>> cycles.
>>>
>>> Sounds good. What do you miss to make it use the "new" architecture
>>> fully?
>>
>> Hi Vincent,
>> I don't think I fully understand what you mean. Can you rephrase,
>> please?
>
> I meant using components and not plugins.

Of course we're using components, annotation feature is all based on that as we
speak. "Plugin" was a general way of referring an XWiki application with a wiki
part (a .xar) and one (or several) server side parts (written as components of
course).

Thanks,
Anca

>
> Thanks
> -Vincent
>
>>
>> Thanks,
>> Anca
>>
>>>
>>> Thanks
>>> -Vincent
>>>
>>>> *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning
>>>> of next year)
>>>> * first iteration on the 2 desired features. At this point one
>>>> should be able to
>>>> configure the type of annotation to add, UI should be accomodate
>>>> this type,
>>>> backing XWiki storage should be easy to integrate with any
>>>> annotation storage
>>>> service (for Scribo requirements), and one should easily set a field
>>>> in a
>>>> structured document which would support annotations. (Note that this
>>>> might
>>>> require heavy rewrite / refactor of the 1.0 version. We could decide
>>>> to skip it
>>>> and go straight to this version, but it would take longer.)
>>>> * integration of Scribo requirements can be met at this point by
>>>> setting the
>>>> configurations according to the Scribo annotation type and target
>>>> requirements.
>>>> At this point, if we find appropriate, we could make the decision of
>>>> including
>>>> the annotation feature in XE by default
>>>>
>>>> *Version 1.2* (future)
>>>> * finish the 2 requirements, integration with Scribo would be done
>>>> in the same
>>>> manner, by specific configuration and storage backend specific
>>>> implementation.
>>>>
>>>> What do you think?
>>>>
>>>> For the moment I will focus on version 1's tasks while finding a
>>>> good
>>>> architecture to achieve the desired requirements, converting, where
>>>> necessary,
>>>> the direction of the development towards that goal.
>>>>
>>>> Thanks (for reading this very long mail),
>>>> 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]

On 10/16/2009 10:44 AM, Guillaume Lerouge wrote:

> Hi Anca,
>
> On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca<[hidden email]>  wrote:
>
>> Hi Guillaume,
>>
>> Guillaume Lerouge wrote:
>>> Hi Anca,
>>>
>>> On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca<[hidden email]
>>> wrote:
>>>
>>>> Hello devs,
>>>>
>>>> The current state of the annotation feature in the sandbox can be
>> described
>>>> by
>>>> the following:
>>>> * there is a single type of annotation which can be added, using a
>> specific
>>>> javascript client backed by a rest service. Such an annotation contains
>> an
>>>> annotation text, the annotated content and its position and this type is
>>>> highly
>>>> coupled in the plugin implementation
>>>> * the backing annotation storage is based on components, currently with
>> an
>>>> XWiki
>>>> objects implementation but a different service can be easily created
>> (there
>>>> is
>>>> one implemented for Scribo annotations stored in RDF)
>>>> * for the moment, only xwiki documents and feed entries fetched by the
>>>> feedreader plugin can be used as targets for annotations (the annotated
>>>> documents), with the restriction that the content of the document is
>> *not*
>>>> generated using scripting. A component can be implemented for a new type
>> of
>>>> document but the current UI (the javascript client) is *specific to
>> xwiki
>>>> documents*
>>>> * the javascript client (UI) is only in the state of a prototype: while
>>>> proving
>>>> that it works, it is not robust enough and the user experience is poor
>>>> * annotation creation algorithm seems to perform well in practice, but
>> we
>>>> should
>>>> put it to more real-world test (by releasing).
>>>>
>>>> Some *requirements* in terms of functionality, in order to make this an
>>>> extensible and flexible feature, would be to:
>>>> * be able to have different types of annotations (one to be able to
>> easily
>>>> specify fields for the annotations to add), with storage as xwiki
>> objects.
>>>> This
>>>> needs to be flexible at all levels: UI and storage backend, preferably
>>>> using
>>>> xwiki scripting (no jars on the server side, or java coding) so that it
>> can
>>>> be
>>>> easily customized. Also, the annotation UI should be thought of as easy
>> to
>>>> customize and create whatever forms and actions in a light manner.
>>>>
>>>
>>> I'm not sure I understand this one well. What exactly do you mean by
>>> "different types of annotations"? From what I understand right now, this
>>> means the following:
>>>
>>>     1. I select text and choose to annotate it
>>>     2. I select custom properties for my annotation (let's say additional
>>>     "city"&  "country" fields)
>>>     3. I fill in those fields and save the annotation
>>>     4. My annotation is saved with those custom fields
>>>
>>> If this is correct, I'm a bit afraid this will bring un-needed complexity
>>> both to the UI and the backend implementation. From what I understood so
>> far
>>> it looks a bit like having the XClass editor each time ones creates a new
>>> annotation ->  isn't that overkill?
>>>
>>> An alternative solution I was thinking about was to use only 1 field with
>> a
>>> semantic syntax&  autosuggest (something like: @city:Paris
>> @country:France).
>>> Is that a possible option? Or maybe it doesn't make sense in the context
>> or
>>> your work?
>>>
>>> Yet another option would be to offer a number of already configured types
>> to
>>> select from in a list when adding a new annotation.
>>
>> Not exactly.
>> The idea was that an admin or a wiki programmer could configure the
>> annotation
>> application (such as setting an XWiki class as the annotation type) and
>> then
>> whenever a user adds an annotation, he will get, in the annotation
>> "bubble", a
>> form to edit an object from that class. Right now, to do that, you'd need
>> to
>> write a few java components&  rewrite the js client. The idea is to have
>> that
>> easily configurable, "scriptable" from the wiki.
>>
>
> Ok, thanks for the clarification :-)
>
> Sounds good to me since it's not too complex for users but at the same time
> addresses Scribo's needs (if I understood those correctly).
>

Well, users shouldn't really be aware of the fact that the annotation type if
flexible, they should get a nice form allowing them to fill in data about an
annotation. This annotation typing should allow programmers to set up their
wiki-specific types.

Anca

>
>>>> * be able to annotate any type of document (object inside such a
>> document),
>>>> namely all or any number of text fields in such an object. Preferably
>> this
>>>> should also be doable only using xwiki scripting or configuration.
>>>>
>>>
>>> Sounds good.
>>>
>>> I would like to propose the following road to perfect this feature:
>>>> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
>>>> The aim would be to take feature out of sandbox preserving its current
>>>> features:
>>>> allowing to add a specific type of annotation saved as XWiki object on a
>>>> regular, non scripted XWiki Document. We should:
>>>> - format, improve comments, generally clean up the current code sandbox
>> to
>>>> match
>>>> XWiki coding styles
>>>> - refactor packages and components to remove some dependencies issues
>> and
>>>> increase flexibility
>>>> - simplify flow, stripping out all code which is not strictly needed by
>> the
>>>> targeted functionality (such as the Feed entry handling code), and make
>> it
>>>> easily implementable by a component in a distinct jar (so that the
>> Scribo
>>>> requirements currently implemented can be preserved)
>>>> - finish the javascript client: robust user interaction, intuitive
>>>> interface,
>>>> cleaned up integration with XE
>>>>
>>>
>>> Do you plan on using GWT to achieve this? If not, what's the best way to
>>> code it in a cross-browser, maintainable way? Using one of the JS library
>>> already embedded in XWiki such as Prototype I guess?
>>
>> I don't have a plan.
>>
>
> Good luck.

The only problem with GWT is that the javascript is not editable right away: it
goes through compilation (so the source itself is not the "executable" anymore,
as in standard interpreted languages which js is) whereas a jsx, for example, is
editable from the wiki. Again, an admin / programmer in a wiki could go in and
tweak some js without access to the server fs, or a GWT compiler, or downloading
sources, or etc.

However, the main advantage of GWT is its cross-browser-ness, the precious
selection API we have and easy development in the more "stable" Java.

I don't have a clear opinion about this yet,
WDYT?

Thanks,
Anca

>
>
>>>> - ensure quality assurance process by a well setup battery of tests,
>> unit
>>>> and
>>>> functional
>>>> At this point I propose to have the annotation feature as an installable
>>>> plugin
>>>> but not included by default in XE, unless after a few bugfixing cycles.
>>>>
>>>
>>> Plugin or component? (maybe this is the same thing under a different
>> name)
>>
>> Application with server side code, I don't know exactly how this would be
>> called.
>>
>>>
>>> *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of
>> next
>>>> year)
>>>> * first iteration on the 2 desired features. At this point one should be
>>>> able to
>>>> configure the type of annotation to add, UI should be accomodate this
>> type,
>>>> backing XWiki storage should be easy to integrate with any annotation
>>>> storage
>>>> service (for Scribo requirements), and one should easily set a field in
>> a
>>>> structured document which would support annotations. (Note that this
>> might
>>>> require heavy rewrite / refactor of the 1.0 version. We could decide to
>>>> skip it
>>>> and go straight to this version, but it would take longer.)
>>>>
>>>
>>> My personal point of view is that being able to annotate any part of a
>> XWiki
>>> document is more important than being able to configure the type of
>>> annotation to add. Is there a hard requirement on the order from the
>> Scribo
>>> research project on this?
>>
>> No, it's not atm afaik, although Scribo could be implemented like that
>> (Scribo
>> annotations are structured, not only a piece of text, even if
>> "serializable" as
>> a text).
>>
>> Actually this point is supposed to be an iteration in both directions (not
>> only
>> about typed annotations leaving behind the second requirement), and for the
>> annotation target I specified
>>
>>   >>  and one should easily set a field in a
>>   >>  structured document which would support annotations.
>>
>
> Ok. Sounds good given your above explanation about annotation definition in
> a XClass.
>
> Guillaume
>
>
>>>> * integration of Scribo requirements can be met at this point by setting
>>>> the
>>>> configurations according to the Scribo annotation type and target
>>>> requirements.
>>>> At this point, if we find appropriate, we could make the decision of
>>>> including
>>>> the annotation feature in XE by default
>>>>
>>>
>>> I guess that will depend on its quality by this time. I think it would be
>> a
>>> great addition to XE's default feature set.
>>>
>>> *Version 1.2* (future)
>>>> * finish the 2 requirements, integration with Scribo would be done in
>> the
>>>> same
>>>> manner, by specific configuration and storage backend specific
>>>> implementation.
>>>>
>>>> What do you think?
>>>>
>>>
>>> I think this can become a key differentiating feature of XWiki since I'm
>> not
>>> aware of any wiki that has them implemented yet. MS Word's annotation
>> system
>>> is widely used and I think XWiki annotation would resonate positively
>> with
>>> XWiki users coming from such text editors.
>>>
>>> For the moment I will focus on version 1's tasks while finding a good
>>>> architecture to achieve the desired requirements, converting, where
>>>> necessary,
>>>> the direction of the development towards that goal.
>>>>
>>>> Thanks (for reading this very long mail),
>>>>
>>>
>>> :-)
>>
>> Thanks,
>> Anca
>>
>>>
>>> Guillaume
>>>
>>>
>>>> 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

[Guillaume Lerouge]

Hi Anca,

On Fri, Oct 16, 2009 at 10:54 AM, Anca Luca <[hidden email]>wrote:

> On 10/16/2009 10:44 AM, Guillaume Lerouge wrote:
> > Hi Anca,
> >
> > On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca<[hidden email]>
>  wrote:
> >
> >> Hi Guillaume,
> >>
> >> Guillaume Lerouge wrote:
> >>> Hi Anca,
> >>>
> >>> On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca<[hidden email]
> >>> wrote:
> >>>
> >>>> Hello devs,
> >>>>
> >>>> The current state of the annotation feature in the sandbox can be
> >> described
> >>>> by
> >>>> the following:
> >>>> * there is a single type of annotation which can be added, using a
> >> specific
> >>>> javascript client backed by a rest service. Such an annotation
> contains
> >> an
> >>>> annotation text, the annotated content and its position and this type
> is
> >>>> highly
> >>>> coupled in the plugin implementation
> >>>> * the backing annotation storage is based on components, currently
> with
> >> an
> >>>> XWiki
> >>>> objects implementation but a different service can be easily created
> >> (there
> >>>> is
> >>>> one implemented for Scribo annotations stored in RDF)
> >>>> * for the moment, only xwiki documents and feed entries fetched by the
> >>>> feedreader plugin can be used as targets for annotations (the
> annotated
> >>>> documents), with the restriction that the content of the document is
> >> *not*
> >>>> generated using scripting. A component can be implemented for a new
> type
> >> of
> >>>> document but the current UI (the javascript client) is *specific to
> >> xwiki
> >>>> documents*
> >>>> * the javascript client (UI) is only in the state of a prototype:
> while
> >>>> proving
> >>>> that it works, it is not robust enough and the user experience is poor
> >>>> * annotation creation algorithm seems to perform well in practice, but
> >> we
> >>>> should
> >>>> put it to more real-world test (by releasing).
> >>>>
> >>>> Some *requirements* in terms of functionality, in order to make this
> an
> >>>> extensible and flexible feature, would be to:
> >>>> * be able to have different types of annotations (one to be able to
> >> easily
> >>>> specify fields for the annotations to add), with storage as xwiki
> >> objects.
> >>>> This
> >>>> needs to be flexible at all levels: UI and storage backend, preferably
> >>>> using
> >>>> xwiki scripting (no jars on the server side, or java coding) so that
> it
> >> can
> >>>> be
> >>>> easily customized. Also, the annotation UI should be thought of as
> easy
> >> to
> >>>> customize and create whatever forms and actions in a light manner.
> >>>>
> >>>
> >>> I'm not sure I understand this one well. What exactly do you mean by
> >>> "different types of annotations"? From what I understand right now,
> this
> >>> means the following:
> >>>
> >>>     1. I select text and choose to annotate it
> >>>     2. I select custom properties for my annotation (let's say
> additional
> >>>     "city"&  "country" fields)
> >>>     3. I fill in those fields and save the annotation
> >>>     4. My annotation is saved with those custom fields
> >>>
> >>> If this is correct, I'm a bit afraid this will bring un-needed
> complexity
> >>> both to the UI and the backend implementation. From what I understood
> so
> >> far
> >>> it looks a bit like having the XClass editor each time ones creates a
> new
> >>> annotation ->  isn't that overkill?
> >>>
> >>> An alternative solution I was thinking about was to use only 1 field
> with
> >> a
> >>> semantic syntax&  autosuggest (something like: @city:Paris
> >> @country:France).
> >>> Is that a possible option? Or maybe it doesn't make sense in the
> context
> >> or
> >>> your work?
> >>>
> >>> Yet another option would be to offer a number of already configured
> types
> >> to
> >>> select from in a list when adding a new annotation.
> >>
> >> Not exactly.
> >> The idea was that an admin or a wiki programmer could configure the
> >> annotation
> >> application (such as setting an XWiki class as the annotation type) and
> >> then
> >> whenever a user adds an annotation, he will get, in the annotation
> >> "bubble", a
> >> form to edit an object from that class. Right now, to do that, you'd
> need
> >> to
> >> write a few java components&  rewrite the js client. The idea is to have
> >> that
> >> easily configurable, "scriptable" from the wiki.
> >>
> >
> > Ok, thanks for the clarification :-)
> >
> > Sounds good to me since it's not too complex for users but at the same
> time
> > addresses Scribo's needs (if I understood those correctly).
> >
>
> Well, users shouldn't really be aware of the fact that the annotation type
> if
> flexible, they should get a nice form allowing them to fill in data about
> an
> annotation. This annotation typing should allow programmers to set up their
> wiki-specific types.
>
> Anca
>
> >
> >>>> * be able to annotate any type of document (object inside such a
> >> document),
> >>>> namely all or any number of text fields in such an object. Preferably
> >> this
> >>>> should also be doable only using xwiki scripting or configuration.
> >>>>
> >>>
> >>> Sounds good.
> >>>
> >>> I would like to propose the following road to perfect this feature:
> >>>> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
> >>>> The aim would be to take feature out of sandbox preserving its current
> >>>> features:
> >>>> allowing to add a specific type of annotation saved as XWiki object on
> a
> >>>> regular, non scripted XWiki Document. We should:
> >>>> - format, improve comments, generally clean up the current code
> sandbox
> >> to
> >>>> match
> >>>> XWiki coding styles
> >>>> - refactor packages and components to remove some dependencies issues
> >> and
> >>>> increase flexibility
> >>>> - simplify flow, stripping out all code which is not strictly needed
> by
> >> the
> >>>> targeted functionality (such as the Feed entry handling code), and
> make
> >> it
> >>>> easily implementable by a component in a distinct jar (so that the
> >> Scribo
> >>>> requirements currently implemented can be preserved)
> >>>> - finish the javascript client: robust user interaction, intuitive
> >>>> interface,
> >>>> cleaned up integration with XE
> >>>>
> >>>
> >>> Do you plan on using GWT to achieve this? If not, what's the best way
> to
> >>> code it in a cross-browser, maintainable way? Using one of the JS
> library
> >>> already embedded in XWiki such as Prototype I guess?
> >>
> >> I don't have a plan.
> >>
> >
> > Good luck.
>
> The only problem with GWT is that the javascript is not editable right
> away: it
> goes through compilation (so the source itself is not the "executable"
> anymore,
> as in standard interpreted languages which js is) whereas a jsx, for
> example, is
> editable from the wiki. Again, an admin / programmer in a wiki could go in
> and
> tweak some js without access to the server fs, or a GWT compiler, or
> downloading
> sources, or etc.
>
> However, the main advantage of GWT is its cross-browser-ness, the precious
> selection API we have and easy development in the more "stable" Java.
>

Is there a way to have GWT retrieve values for some CSS properties from
XObjects?

For instance, is the GWT-based UI could retrieve its CSS color codes from a
ColorTheme object it would allow you to code in GWT while still giving the
wiki admin some control over the annotations' look.

Is that doable?

Guillaume

I don't have a clear opinion about this yet,

> WDYT?
>
> Thanks,
> Anca
>
> >
> >
> >>>> - ensure quality assurance process by a well setup battery of tests,
> >> unit
> >>>> and
> >>>> functional
> >>>> At this point I propose to have the annotation feature as an
> installable
> >>>> plugin
> >>>> but not included by default in XE, unless after a few bugfixing
> cycles.
> >>>>
> >>>
> >>> Plugin or component? (maybe this is the same thing under a different
> >> name)
> >>
> >> Application with server side code, I don't know exactly how this would
> be
> >> called.
> >>
> >>>
> >>> *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of
> >> next
> >>>> year)
> >>>> * first iteration on the 2 desired features. At this point one should
> be
> >>>> able to
> >>>> configure the type of annotation to add, UI should be accomodate this
> >> type,
> >>>> backing XWiki storage should be easy to integrate with any annotation
> >>>> storage
> >>>> service (for Scribo requirements), and one should easily set a field
> in
> >> a
> >>>> structured document which would support annotations. (Note that this
> >> might
> >>>> require heavy rewrite / refactor of the 1.0 version. We could decide
> to
> >>>> skip it
> >>>> and go straight to this version, but it would take longer.)
> >>>>
> >>>
> >>> My personal point of view is that being able to annotate any part of a
> >> XWiki
> >>> document is more important than being able to configure the type of
> >>> annotation to add. Is there a hard requirement on the order from the
> >> Scribo
> >>> research project on this?
> >>
> >> No, it's not atm afaik, although Scribo could be implemented like that
> >> (Scribo
> >> annotations are structured, not only a piece of text, even if
> >> "serializable" as
> >> a text).
> >>
> >> Actually this point is supposed to be an iteration in both directions
> (not
> >> only
> >> about typed annotations leaving behind the second requirement), and for
> the
> >> annotation target I specified
> >>
> >>   >>  and one should easily set a field in a
> >>   >>  structured document which would support annotations.
> >>
> >
> > Ok. Sounds good given your above explanation about annotation definition
> in
> > a XClass.
> >
> > Guillaume
> >
> >
> >>>> * integration of Scribo requirements can be met at this point by
> setting
> >>>> the
> >>>> configurations according to the Scribo annotation type and target
> >>>> requirements.
> >>>> At this point, if we find appropriate, we could make the decision of
> >>>> including
> >>>> the annotation feature in XE by default
> >>>>
> >>>
> >>> I guess that will depend on its quality by this time. I think it would
> be
> >> a
> >>> great addition to XE's default feature set.
> >>>
> >>> *Version 1.2* (future)
> >>>> * finish the 2 requirements, integration with Scribo would be done in
> >> the
> >>>> same
> >>>> manner, by specific configuration and storage backend specific
> >>>> implementation.
> >>>>
> >>>> What do you think?
> >>>>
> >>>
> >>> I think this can become a key differentiating feature of XWiki since
> I'm
> >> not
> >>> aware of any wiki that has them implemented yet. MS Word's annotation
> >> system
> >>> is widely used and I think XWiki annotation would resonate positively
> >> with
> >>> XWiki users coming from such text editors.
> >>>
> >>> For the moment I will focus on version 1's tasks while finding a good
> >>>> architecture to achieve the desired requirements, converting, where
> >>>> necessary,
> >>>> the direction of the development towards that goal.
> >>>>
> >>>> Thanks (for reading this very long mail),
> >>>>
> >>>
> >>> :-)
> >>
> >> Thanks,
> >> Anca
> >>
> >>>
> >>> Guillaume
> >>>
> >>>
> >>>> 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
>

--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[Sergiu Dumitriu-2]

On 10/16/2009 11:12 AM, Guillaume Lerouge wrote:

> Hi Anca,
>
> On Fri, Oct 16, 2009 at 10:54 AM, Anca Luca<[hidden email]>wrote:
>
>> On 10/16/2009 10:44 AM, Guillaume Lerouge wrote:
>>> Hi Anca,
>>>
>>> On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca<[hidden email]>
>>   wrote:
>>>
>>>> Hi Guillaume,
>>>>
>>>> Guillaume Lerouge wrote:
>>>>> Hi Anca,
>>>>> Do you plan on using GWT to achieve this? If not, what's the best way
>> to
>>>>> code it in a cross-browser, maintainable way? Using one of the JS
>> library
>>>>> already embedded in XWiki such as Prototype I guess?
>>>>
>>>> I don't have a plan.
>>>>
>>>
>>> Good luck.
>>
>> The only problem with GWT is that the javascript is not editable right
>> away: it
>> goes through compilation (so the source itself is not the "executable"
>> anymore,
>> as in standard interpreted languages which js is) whereas a jsx, for
>> example, is
>> editable from the wiki. Again, an admin / programmer in a wiki could go in
>> and
>> tweak some js without access to the server fs, or a GWT compiler, or
>> downloading
>> sources, or etc.
>>
>> However, the main advantage of GWT is its cross-browser-ness, the precious
>> selection API we have and easy development in the more "stable" Java.
>>
>
> Is there a way to have GWT retrieve values for some CSS properties from
> XObjects?
>
> For instance, is the GWT-based UI could retrieve its CSS color codes from a
> ColorTheme object it would allow you to code in GWT while still giving the
> wiki admin some control over the annotations' look.
>
> Is that doable?

Styling was never an issue with GWT code. Editing the source javascript
is, and it's not possible to do it.

What's doable is to have a mix of GWT and plain javascript, like a core
functionality and API in GWT, which is used by a JSX to provide the UI.
But this only increases the complexity, and doesn't add the advantages
of both frameworks, on the contrary, it only sums their disadvantages.

Still, why do you think that GWT is more cross-browser than Prototype?
IIRC, there were lots of problems with GWT code, too, and the main
problem with both JS and GWT code is not the code itself, but the very
general rules in the core skin, which have many side effects hard to
overcome. Am I right?

So, personally I prefer the Prototype way, but Anca's vote counts more,
since she'll have to write the code.


By the way, +1 for the general goals, Anca.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[Anca Luca]

On 10/16/2009 04:46 PM, Sergiu Dumitriu wrote:

> On 10/16/2009 11:12 AM, Guillaume Lerouge wrote:
>> Hi Anca,
>>
>> On Fri, Oct 16, 2009 at 10:54 AM, Anca Luca<[hidden email]>wrote:
>>
>>> On 10/16/2009 10:44 AM, Guillaume Lerouge wrote:
>>>> Hi Anca,
>>>>
>>>> On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca<[hidden email]>
>>>    wrote:
>>>>
>>>>> Hi Guillaume,
>>>>>
>>>>> Guillaume Lerouge wrote:
>>>>>> Hi Anca,
>>>>>> Do you plan on using GWT to achieve this? If not, what's the best way
>>> to
>>>>>> code it in a cross-browser, maintainable way? Using one of the JS
>>> library
>>>>>> already embedded in XWiki such as Prototype I guess?
>>>>>
>>>>> I don't have a plan.
>>>>>
>>>>
>>>> Good luck.
>>>
>>> The only problem with GWT is that the javascript is not editable right
>>> away: it
>>> goes through compilation (so the source itself is not the "executable"
>>> anymore,
>>> as in standard interpreted languages which js is) whereas a jsx, for
>>> example, is
>>> editable from the wiki. Again, an admin / programmer in a wiki could go in
>>> and
>>> tweak some js without access to the server fs, or a GWT compiler, or
>>> downloading
>>> sources, or etc.
>>>
>>> However, the main advantage of GWT is its cross-browser-ness, the precious
>>> selection API we have and easy development in the more "stable" Java.
>>>
>>
>> Is there a way to have GWT retrieve values for some CSS properties from
>> XObjects?
>>
>> For instance, is the GWT-based UI could retrieve its CSS color codes from a
>> ColorTheme object it would allow you to code in GWT while still giving the
>> wiki admin some control over the annotations' look.
>>
>> Is that doable?

the problem is not with looks but with slight adjust of functionality, like,
say, extra validation before you click a button, or an extra help message or
baloon. If in GWT you need to recompile and redeploy while in jsx you just edit
in the browser. Now, this is a frequent use-case only for developers, and edit
in browser is a very "nice to have", we need to find out if we're willing to trade.

>
> Styling was never an issue with GWT code. Editing the source javascript
> is, and it's not possible to do it.
>
> What's doable is to have a mix of GWT and plain javascript, like a core
> functionality and API in GWT, which is used by a JSX to provide the UI.

I don't think you'd be able to cover all cases where users might want to hack.
Since hacking is not supposed to happen (we'd only give one the chance to easily
do it if she wants), I think it's very hard to define an API for it.

> But this only increases the complexity, and doesn't add the advantages
> of both frameworks, on the contrary, it only sums their disadvantages.
>
> Still, why do you think that GWT is more cross-browser than Prototype?
> IIRC, there were lots of problems with GWT code, too, and the main
> problem with both JS and GWT code is not the code itself, but the very
> general rules in the core skin, which have many side effects hard to
> overcome. Am I right?

More or less about the skin rules.
GWT might be more cross-browser at least because Marius has been working a lot
on making it very cross browser (we have our xwiki-gwt-dom module which
encapsulates selection API and the fixes for the DOM api). We can reuse some of
this work.

>
> So, personally I prefer the Prototype way, but Anca's vote counts more,
> since she'll have to write the code.

The whole issue is if it's worth to employ a whole GWT app for such a thing
(which might be too light for it). Otherwise GWT has pretty good parts: easier
to write code with, automated testing, hosted mode debugging (well, that's
achievable with firebug), and all the others that coding in Java brings.

Thanks,
Anca

>
>
> By the way, +1 for the general goals, Anca.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[Niels Mayer]

On Wed, Oct 14, 2009 at 1:03 PM, Anca Luca <[hidden email]> wrote:

> * the backing annotation storage is based on components, currently with an
> XWiki
> objects implementation but a different service can be easily created (there
> is
> one implemented for Scribo annotations stored in RDF)
>

Where is the source for the xwiki-based annotation storage? Is this it?
http://hg.nuxeo.org/sandbox/scribo/file/a9c5293ae8b3/scribo-xwiki-documentsource/src/main/java/ws/scribo/or
some other part of
http://hg.nuxeo.org/sandbox/scribo/summary ?

Also, I request a simple feature: The addition of an extra, separate,
string-property alongside every annotation. This would allow an arbitrary
JSON structure (text) to be entered, containing additional information.

As my interest is in semantic video and audio annotations, this kind of
"back-link" would allow easy addition of structured information alongside an
annotation. One of the issues with "annotation" in general is that there can
be a variety of information one wants to supply. For example, in
a structured document, one may want to annotate a named element, an
unnamed-element positionally defined within a larger named structure, as
well as an "extent" , in case the annotation doesn't correspond to an exact
DOM structure.
With streaming media, you will want to annotate with a start and a stop
time, but also there may be the need for much additional information to be
cross-referenced: for example, if using automatic indexing, structure or
dialog detection in a video or audio stream, one will typically have a
variety of other information one may need attached to any particular
annotation. So in my need for annotation, I may want to include a JSON
structure like this alongside every audio annotation:

{"title": "Michael Jackson Special", "file": "
http://www.aspenpublicradio.com/podcasts/sp/soulpatrol_mjspecialjul09.mp3",
"type": "sound", "link": "http://www.aspenpublicradio.org/support.php",
"tags": "Music", "image": "/Misc_icon_Media_Clip_1813.jpg", "author": "KAJX,
Soul Patrol Podcast", "description": "Clip: segment32 start: 00:15:12.600
end: 00:19:01.400 length: 228.80000000000007s.
analyzer=VampQmSegmenter:segment", "date": "2009-07-05T08:00:00Z", "start":
912.6, "duration": 228.80000000000007, "captions.file":
"/xwiki/bin/view/Episodes/www_aspenpublicradio_com_podcasts_sp_soulpatrol_mjspecialjul09_mp3?xpage=plain&analyzer=VampQmSegmenter%3Asegment",
"trainspodder.analysis": "VampQmSegmenter:segment"}

This is from a real-world example:
http://nielsmayer.com/trainspodder-prototype-2009-10-16.jpg

... This discussion is timely, as I'm now implementing the functionality
behind the "add comment" button in the timeline popup bubble. Thus my
interest in finding the source code and it's status for your annotations
back-end for use outside your project....

Regarding Scribo,
http://trueg.wordpress.com/2009/05/14/scribo-getting-natural-language-into-the-mix/suggests
that the main focus is on natural language processing for
documents, which is a laudable goal, as I spent some time in college writing
in prolog for just this purpose and then spent 8 years in research working
alongside NLP people.
See before the web existed, we did "web" over email:
http://nielsmayer.com/p93-shepherd.pdf and worried about semantic tagging of
"intent", and automating conversation structures based on tracking
conversational moves....

Today, however, a vast unexplored chunk of content and "intelligence" (and
it's dialectic, stupidity) out there is in audio and video form. For that,
semantic-audio technologies on which I base my work come in very handy,
e.g. http://www.omras2.org/ . Is scribo intending to focus any effort on
semantic tagging audio and video content? Given the shared platform, Xwiki,
perhaps there's room for collaboration?

Also, please note that there is a good deal of potential with the "idiot
savant" technology such as that employed by http://www.google.com/voice .
Excited to see things from the labs hit the mainstream, I installed my new
free google voice "Call Me" button on my website... the performance of the
transcription capabilities are less than stellar (it's own "annotation"
animated beautifully in synchrony with the recorded message, dynamically
underlining each spoken word in the transcript, many of which were
completely wrong):

*Niels Mayer* () .....11:10 PMHey this is a groovy tester google voice on my
homepage. I wanna see how prizes, as I can release my number. What they're
gonna do. I have keep number private sector so. Ohh no it's not facts of
course it's not gonna do it. Anyways, it's all very excited and an call on
the web and see what it actually and they call.

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

[Anca Luca]

Hi Niels,

On 10/16/2009 11:49 PM, Niels Mayer wrote:

> On Wed, Oct 14, 2009 at 1:03 PM, Anca Luca <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     * the backing annotation storage is based on components, currently
>     with an XWiki
>     objects implementation but a different service can be easily created
>     (there is
>     one implemented for Scribo annotations stored in RDF)
>
>
> Where is the source for the xwiki-based annotation storage? Is this it?
> http://hg.nuxeo.org/sandbox/scribo/file/a9c5293ae8b3/scribo-xwiki-documentsource/src/main/java/ws/scribo/
> or some other part of http://hg.nuxeo.org/sandbox/scribo/summary ?

The xwiki based storage backend is here in the xwiki sandbox:
https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/xwiki-annotation-io/src/main/java/com/xpn/xwiki/annotation/internal/document/ 
implementing the interfaces in
https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/xwiki-annotation-core/src/main/java/org/xwiki/annotation/ 
.

In the scribo sources, they're here (slightly refactored compared to the xwiki
sandbox):
http://bitbucket.org/lpereira/scribo/src/tip/scribo-xwiki-annotation-parent/scribo-xwiki-annotation-io/src/main/java/org/xwiki/annotation/internal/document/ 
, along with the ScriboIOService implementation.

>
> Also, I request a simple feature: The addition of an extra, separate,
> string-property alongside every annotation. This would allow an
> arbitrary JSON structure (text) to be entered, containing additional
> information.
>
> As my interest is in semantic video and audio annotations, this kind of
> "back-link" would allow easy addition of structured information
> alongside an annotation. One of the issues with "annotation" in general
> is that there can be a variety of information one wants to supply. For
> example, in a structured document, one may want to annotate a named
> element, an unnamed-element positionally defined within a larger named
> structure, as well as an "extent" , in case the annotation doesn't
> correspond to an exact DOM structure.
> With streaming media, you will want to annotate with a start and a stop
> time, but also there may be the need for much additional information to
> be cross-referenced: for example, if using automatic indexing, structure
> or dialog detection in a video or audio stream, one will typically have
> a variety of other information one may need attached to any particular
> annotation. So in my need for annotation, I may want to include a JSON
> structure like this alongside every audio annotation:
>
> {"title": "Michael Jackson Special", "file":
> "http://www.aspenpublicradio.com/podcasts/sp/soulpatrol_mjspecialjul09.mp3",
> "type": "sound", "link": "http://www.aspenpublicradio.org/support.php",
> "tags": "Music", "image": "/Misc_icon_Media_Clip_1813.jpg", "author":
> "KAJX, Soul Patrol Podcast", "description": "Clip: segment32 start:
> 00:15:12.600 end: 00:19:01.400 length: 228.80000000000007s.
> analyzer=VampQmSegmenter:segment", "date": "2009-07-05T08:00:00Z",
> "start": 912.6, "duration": 228.80000000000007, "captions.file":
> "/xwiki/bin/view/Episodes/www_aspenpublicradio_com_podcasts_sp_soulpatrol_mjspecialjul09_mp3?xpage=plain&analyzer=VampQmSegmenter%3Asegment",
> "trainspodder.analysis": "VampQmSegmenter:segment"}
>
> This is from a real-world example:
> http://nielsmayer.com/trainspodder-prototype-2009-10-16.jpg

But this is the requirement number 1 that I mentioned in my original mail:
"* be able to have different types of annotations (one to be able to easily
specify fields for the annotations to add), with storage as xwiki objects. This
needs to be flexible at all levels: UI and storage backend, preferably using
xwiki scripting (no jars on the server side, or java coding) so that it can be
easily customized. Also, the annotation UI should be thought of as easy to
customize and create whatever forms and actions in a light manner.
"
, isn't it?

in short, my idea would be that a programmer of the wiki would write (and
configure) an xwiki class that would define the type of the annotation that
needs to be added, and then the javascript client, UI, communication with server
and default xwiki storage) would all automatically handle all the fields in the
class, without the need to pass and handle custom JSON.

More, right now, the communication between the javascript client and annotations
REST service is done in XML, using JAXB for deserialization on the server. So
rather than accepting a piece of JSON, more straightforward would be to loosen
the schema to accept anything.

The sources for the XWiki annotation application are here:
https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/ and some
user & developer guides are here:
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature .

Happy hacking,
Anca

>
> ... This discussion is timely, as I'm now implementing the functionality
> behind the "add comment" button in the timeline popup bubble. Thus my
> interest in finding the source code and it's status for your annotations
> back-end for use outside your project....
>
> Regarding Scribo,
> http://trueg.wordpress.com/2009/05/14/scribo-getting-natural-language-into-the-mix/
> suggests that the main focus is on natural language processing for
> documents, which is a laudable goal, as I spent some time in college
> writing in prolog for just this purpose and then spent 8 years in
> research working alongside NLP people.
> See before the web existed, we did "web" over email:
> http://nielsmayer.com/p93-shepherd.pdf and worried about semantic
> tagging of "intent", and automating conversation structures based on
> tracking conversational moves....
>
> Today, however, a vast unexplored chunk of content and "intelligence"
> (and it's dialectic, stupidity) out there is in audio and video form.
> For that, semantic-audio technologies on which I base my work come in
> very handy, e.g. http://www.omras2.org/ . Is scribo intending to focus
> any effort on semantic tagging audio and video content? Given the shared
> platform, Xwiki, perhaps there's room for collaboration?
>
> Also, please note that there is a good deal of potential with the "idiot
> savant" technology such as that employed by
> http://www.google.com/voice . Excited to see things from the labs hit
> the mainstream, I installed my new free google voice "Call Me" button on
> my website... the performance of the transcription capabilities are less
> than stellar (it's own "annotation" animated beautifully in synchrony
> with the recorded message, dynamically underlining each spoken word in
> the transcript, many of which were completely wrong):
>
> *Niels Mayer* () .....
> 11:10 PM
> Hey this is a groovy tester google voice on my homepage. I wanna see how
> prizes, as I can release my number. What they're gonna do. I have keep
> number private sector so. Ohh no it's not facts of course it's not gonna
> do it. Anyways, it's all very excited and an call on the web and see
> what it actually and they call.
>
>
> -- Niels
> http://nielsmayer.com
>

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

[Anca Luca]

On 10/19/2009 11:20 AM, Anca Luca wrote:

> Hi Niels,
>
> On 10/16/2009 11:49 PM, Niels Mayer wrote:
>> On Wed, Oct 14, 2009 at 1:03 PM, Anca Luca<[hidden email]
>> <mailto:[hidden email]>>  wrote:
>>
>>      * the backing annotation storage is based on components, currently
>>      with an XWiki
>>      objects implementation but a different service can be easily created
>>      (there is
>>      one implemented for Scribo annotations stored in RDF)
>>
>>
>> Where is the source for the xwiki-based annotation storage? Is this it?
>> http://hg.nuxeo.org/sandbox/scribo/file/a9c5293ae8b3/scribo-xwiki-documentsource/src/main/java/ws/scribo/
>> or some other part of http://hg.nuxeo.org/sandbox/scribo/summary ?
>
> The xwiki based storage backend is here in the xwiki sandbox:
> https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/xwiki-annotation-io/src/main/java/com/xpn/xwiki/annotation/internal/document/
> implementing the interfaces in
> https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/xwiki-annotation-core/src/main/java/org/xwiki/annotation/
> .
>
> In the scribo sources, they're here (slightly refactored compared to the xwiki
> sandbox):
> http://bitbucket.org/lpereira/scribo/src/tip/scribo-xwiki-annotation-parent/scribo-xwiki-annotation-io/src/main/java/org/xwiki/annotation/internal/document/
> , along with the ScriboIOService implementation.
>
>>
>> Also, I request a simple feature: The addition of an extra, separate,
>> string-property alongside every annotation. This would allow an
>> arbitrary JSON structure (text) to be entered, containing additional
>> information.
>>
>> As my interest is in semantic video and audio annotations, this kind of
>> "back-link" would allow easy addition of structured information
>> alongside an annotation. One of the issues with "annotation" in general
>> is that there can be a variety of information one wants to supply. For
>> example, in a structured document, one may want to annotate a named
>> element, an unnamed-element positionally defined within a larger named
>> structure, as well as an "extent" , in case the annotation doesn't
>> correspond to an exact DOM structure.
>> With streaming media, you will want to annotate with a start and a stop
>> time, but also there may be the need for much additional information to
>> be cross-referenced: for example, if using automatic indexing, structure
>> or dialog detection in a video or audio stream, one will typically have
>> a variety of other information one may need attached to any particular
>> annotation. So in my need for annotation, I may want to include a JSON
>> structure like this alongside every audio annotation:
>>
>> {"title": "Michael Jackson Special", "file":
>> "http://www.aspenpublicradio.com/podcasts/sp/soulpatrol_mjspecialjul09.mp3",
>> "type": "sound", "link": "http://www.aspenpublicradio.org/support.php",
>> "tags": "Music", "image": "/Misc_icon_Media_Clip_1813.jpg", "author":
>> "KAJX, Soul Patrol Podcast", "description": "Clip: segment32 start:
>> 00:15:12.600 end: 00:19:01.400 length: 228.80000000000007s.
>> analyzer=VampQmSegmenter:segment", "date": "2009-07-05T08:00:00Z",
>> "start": 912.6, "duration": 228.80000000000007, "captions.file":
>> "/xwiki/bin/view/Episodes/www_aspenpublicradio_com_podcasts_sp_soulpatrol_mjspecialjul09_mp3?xpage=plain&analyzer=VampQmSegmenter%3Asegment",
>> "trainspodder.analysis": "VampQmSegmenter:segment"}
>>
>> This is from a real-world example:
>> http://nielsmayer.com/trainspodder-prototype-2009-10-16.jpg
>
> But this is the requirement number 1 that I mentioned in my original mail:
> "* be able to have different types of annotations (one to be able to easily
> specify fields for the annotations to add), with storage as xwiki objects. This
> needs to be flexible at all levels: UI and storage backend, preferably using
> xwiki scripting (no jars on the server side, or java coding) so that it can be
> easily customized. Also, the annotation UI should be thought of as easy to
> customize and create whatever forms and actions in a light manner.
> "
> , isn't it?
>
> in short, my idea would be that a programmer of the wiki would write (and
> configure) an xwiki class that would define the type of the annotation that
> needs to be added, and then the javascript client, UI, communication with server
> and default xwiki storage) would all automatically handle all the fields in the
> class, without the need to pass and handle custom JSON.
>
> More, right now, the communication between the javascript client and annotations
> REST service is done in XML, using JAXB for deserialization on the server. So
> rather than accepting a piece of JSON, more straightforward would be to loosen
> the schema to accept anything.
>
> The sources for the XWiki annotation application are here:
> https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/ and some
> user&  developer guides are here:
> http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature .

actually the link above contains more implementation details, about usage &
setup, it's more here: http://dev.xwiki.org/xwiki/bin/view/Drafts/AnnotationModule .

Anca

>
> Happy hacking,
> Anca
>
>>
>> ... This discussion is timely, as I'm now implementing the functionality
>> behind the "add comment" button in the timeline popup bubble. Thus my
>> interest in finding the source code and it's status for your annotations
>> back-end for use outside your project....
>>
>> Regarding Scribo,
>> http://trueg.wordpress.com/2009/05/14/scribo-getting-natural-language-into-the-mix/
>> suggests that the main focus is on natural language processing for
>> documents, which is a laudable goal, as I spent some time in college
>> writing in prolog for just this purpose and then spent 8 years in
>> research working alongside NLP people.
>> See before the web existed, we did "web" over email:
>> http://nielsmayer.com/p93-shepherd.pdf and worried about semantic
>> tagging of "intent", and automating conversation structures based on
>> tracking conversational moves....
>>
>> Today, however, a vast unexplored chunk of content and "intelligence"
>> (and it's dialectic, stupidity) out there is in audio and video form.
>> For that, semantic-audio technologies on which I base my work come in
>> very handy, e.g. http://www.omras2.org/ . Is scribo intending to focus
>> any effort on semantic tagging audio and video content? Given the shared
>> platform, Xwiki, perhaps there's room for collaboration?
>>
>> Also, please note that there is a good deal of potential with the "idiot
>> savant" technology such as that employed by
>> http://www.google.com/voice . Excited to see things from the labs hit
>> the mainstream, I installed my new free google voice "Call Me" button on
>> my website... the performance of the transcription capabilities are less
>> than stellar (it's own "annotation" animated beautifully in synchrony
>> with the recorded message, dynamically underlining each spoken word in
>> the transcript, many of which were completely wrong):
>>
>> *Niels Mayer* () .....
>> 11:10 PM
>> Hey this is a groovy tester google voice on my homepage. I wanna see how
>> prizes, as I can release my number. What they're gonna do. I have keep
>> number private sector so. Ohh no it's not facts of course it's not gonna
>> do it. Anyways, it's all very excited and an call on the web and see
>> what it actually and they call.
>>
>>
>> -- Niels
>> http://nielsmayer.com
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

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

[Fabio Mancinelli-4]

On Oct 16, 2009, at 10:49 PM, Niels Mayer wrote:

> On Wed, Oct 14, 2009 at 1:03 PM, Anca Luca  
> <[hidden email]> wrote:
>
>> * the backing annotation storage is based on components, currently  
>> with an
>> XWiki
>> objects implementation but a different service can be easily  
>> created (there
>> is
>> one implemented for Scribo annotations stored in RDF)
>>
>

Hi Niels,

thank you for your email. I'll try to answer and to clarify things.

> Where is the source for the xwiki-based annotation storage? Is this  
> it?
> http://hg.nuxeo.org/sandbox/scribo/file/a9c5293ae8b3/scribo-xwiki-documentsource/src/main/java/ws/scribo/or
> some other part of
> http://hg.nuxeo.org/sandbox/scribo/summary ?
>
I saw that Anca has already replied to you so I will not repeat what  
she said.
The repository you mentioned is what we called "the scribo framework"  
that will be used/integrated into XWiki's annotation framework which  
is currently in a development phase.

What you will find in those repos is not really XWiki specific but it  
is the foundation for building an integration with XWiki (and also  
with other products that are developed by the partners of the Scribo  
project).

Just to be clearer, Scribo is a research project and currently  
consists of a "cloud" of heterogeneous and independent technologies  
developed by several partners, among them several research  
institutions and industrial partners (including XWiki). You can the  
links to these technology on this page: http://www.scribo.ws/xwiki/bin/view/Main/Development 
  The project is still in its "initial phases", we are almost at month  
10 of 24. We already have some usable stuff but we expect to have  
something more usable at the beginning of 2010.

XWiki's annotation feature will come in a little bit faster :)

> Today, however, a vast unexplored chunk of content and  
> "intelligence" (and
> it's dialectic, stupidity) out there is in audio and video form. For  
> that,
> semantic-audio technologies on which I base my work come in very  
> handy,
> e.g. http://www.omras2.org/ . Is scribo intending to focus any  
> effort on
> semantic tagging audio and video content? Given the shared platform,  
> Xwiki,
> perhaps there's room for collaboration?
>

As you already read from Sebastian's blog, Scribo's main focus is  
about NLP but we also have a workpackage whose focus is about "image  
dematerialization". In particular it aims at isolating interesting  
parts of an image (for example the text in a complex picture) or  
recognizing its structure and assigning "meaning" to the components.  
Think, for example, to an invoice. It has several areas: the company  
address, the product list, the recipient of the invoice, etc.

In developing Scribo we are trying to reuse open source frameworks and  
build on them. In particular we are using UIMA as the integration  
layer. So in principle a technology based on audio/video recognition  
could be integrated but this is out of the scope of the Scribo project.

Concerning XWiki, we have different use cases to implement for the  
Scribo project and we also have different requirements coming from  
other sources. The annotation component will try to provide a "common  
ground" for integrating all those requirements easily (where Scribo  
will be just one of those integrations)

I hope that this answer your mail, feel free to ask other question.

Thanks again for your input.

Regards,
Fabio

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

[Anca Luca]

Hi all

I also added a section about the current implementation along with some schemes
about how it works at
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HCurrentImplementation 
.

Happy hacking,
Anca

On 10/14/2009 11:03 PM, Anca Luca wrote:

> Hello devs,
>
> The current state of the annotation feature in the sandbox can be described by
> the follwing:
> * there is a single type of annotation which can be added, using a specific
> javascript client backed by a rest service. Such an annotation contains an
> annotation text, the annotated content and its position and this type is highly
> coupled in the plugin implementation
> * the backing annotation storage is based on components, currently with an XWiki
> objects implementation but a different service can be easily created (there is
> one implemented for Scribo annotations stored in RDF)
> * for the moment, only xwiki documents and feed entries fetched by the
> feedreader plugin can be used as targets for annotations (the annotated
> documents), with the restriction that the content of the document is *not*
> generated using scripting. A component can be implemented for a new type of
> document but the current UI (the javascript client) is *specific to xwiki documents*
> * the javascript client (UI) is only in the state of a prototype: while proving
> that it works, it is not robust enough and the user experience is poor
> * annotation creation algorithm seems to perform well in practice, but we should
> put it to more real-world test (by releasing).
>
> Some *requirements* in terms of functionality, in order to make this an
> extensible and flexible feature, would be to:
> * be able to have different types of annotations (one to be able to easily
> specify fields for the annotations to add), with storage as xwiki objects. This
> needs to be flexible at all levels: UI and storage backend, preferably using
> xwiki scripting (no jars on the server side, or java coding) so that it can be
> easily customized. Also, the annotation UI should be thought of as easy to
> customize and create whatever forms and actions in a light manner.
> * be able to annotate any type of document (object inside such a document),
> namely all or any number of text fields in such an object. Preferably this
> should also be doable only using xwiki scripting or configuration.
>
> I would like to propose the following road to perfect this feature:
> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
> The aim would be to take feature out of sandbox preserving its current features:
> allowing to add a specific type of annotation saved as XWiki object on a
> regular, non scripted XWiki Document. We should:
> - format, improve comments, generally clean up the current code sandbox to match
> XWiki coding styles
> - refactor packages and components to remove some dependencies issues and
> increase flexibility
> - simplify flow, stripping out all code which is not strictly needed by the
> targeted functionality (such as the Feed entry handling code), and make it
> easily implementable by a component in a distinct jar (so that the Scribo
> requirements currently implemented can be preserved)
> - finish the javascript client: robust user interaction, intuitive interface,
> cleaned up integration with XE
> - ensure quality assurance process by a well setup battery of tests, unit and
> functional
> At this point I propose to have the annotation feature as an installable plugin
> but not included by default in XE, unless after a few bugfixing cycles.
>
> *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next year)
> * first iteration on the 2 desired features. At this point one should be able to
> configure the type of annotation to add, UI should be accomodate this type,
> backing XWiki storage should be easy to integrate with any annotation storage
> service (for Scribo requirements), and one should easily set a field in a
> structured document which would support annotations. (Note that this might
> require heavy rewrite / refactor of the 1.0 version. We could decide to skip it
> and go straight to this version, but it would take longer.)
> * integration of Scribo requirements can be met at this point by setting the
> configurations according to the Scribo annotation type and target requirements.
> At this point, if we find appropriate, we could make the decision of including
> the annotation feature in XE by default
>
> *Version 1.2* (future)
> * finish the 2 requirements, integration with Scribo would be done in the same
> manner, by specific configuration and storage backend specific implementation.
>
> What do you think?
>
> For the moment I will focus on version 1's tasks while finding a good
> architecture to achieve the desired requirements, converting, where necessary,
> the direction of the development towards that goal.
>
> Thanks (for reading this very long mail),
> 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