Confirmed users
70
edits
| Line 134: | Line 134: | ||
And what we believe that is more important in collaboration: it may allow an user to discover friends and co-workers workflows - this would be achievable by publishing workflows with a [[http://xmlns.com/foaf/spec/#term_maker foaf:maker]] relation, and the user's foaf profile could point to friends, organisations (hence co-workers). (If the user lacks an explicit foaf profile, we could use one based on his Twitter relations: http://semantictweet.com ) | And what we believe that is more important in collaboration: it may allow an user to discover friends and co-workers workflows - this would be achievable by publishing workflows with a [[http://xmlns.com/foaf/spec/#term_maker foaf:maker]] relation, and the user's foaf profile could point to friends, organisations (hence co-workers). (If the user lacks an explicit foaf profile, we could use one based on his Twitter relations: http://semantictweet.com ) | ||
Also, apart of the mentioned RDF approach, we hope that future versions of Mozilla [[Labs/Weave|Weave]] could enable various levels of collaboration. | |||
We consider each recordable action as an annotation, and we would like to have them compatible/interoperable at some level with [[http://www.openannotation.org/ Open Annotation]] initiative. We already use [[http://xpointerlib.mozdev.org/ xpointerlib]] for ''note actions'' which would allow us to create [[http://www.w3.org/2001/Annotea/ Annotea-like]] annotations and be interoperable with Open Annotation. | We consider each recordable action as an annotation, and we would like to have them compatible/interoperable at some level with [[http://www.openannotation.org/ Open Annotation]] initiative. We already use [[http://xpointerlib.mozdev.org/ xpointerlib]] for ''note actions'' which would allow us to create [[http://www.w3.org/2001/Annotea/ Annotea-like]] annotations and be interoperable with Open Annotation. | ||
| Line 140: | Line 142: | ||
Moreover, think of the possibilities that the sole command ''translate'' from Ubiquity could bring to MUPPLE: ''collaboration that spans language barriers''. | Moreover, think of the possibilities that the sole command ''translate'' from Ubiquity could bring to MUPPLE: ''collaboration that spans language barriers''. | ||
As we already mentioned, a LISL implementation on top of the Ubiquity's [[Labs/Ubiquity/Parser_2|Parser 2]] might allow for a tight integration between LISL and existing Ubiquity commands, and it might leverage the [[Labs/Ubiquity/Parser_2/Localization_Tutorial|localization possibilities of the parser]] if needed. | |||
Right now the prototype as UI is pretty much what we envisioned, but with partial functionality; this is mostly due not to the difficulties in added the envisioned functionality, but when observing, hands-on, that some activities must be separated, namely editing a workflow and "replaying" a workflow have to be distinct, as controls, as visual state communicated to the user; we did not add extra functionality for the sake of a prototype because a ''reboot'' of MUPPLE II is required, and we plan to do it in February. | Right now the prototype as UI is pretty much what we envisioned, but with partial functionality; this is mostly due not to the difficulties in added the envisioned functionality, but when observing, hands-on, that some activities must be separated, namely editing a workflow and "replaying" a workflow have to be distinct, as controls, as visual state communicated to the user; we did not add extra functionality for the sake of a prototype because a ''reboot'' of MUPPLE II is required, and we plan to do it in February. | ||