A dynamically extensible open cross document link service
•Download as PPTX, PDF•
0 likes•205 views
Presentation of our work at WISE 2015 conference
Recommended
Recommended
More Related Content
Similar to A dynamically extensible open cross document link service
Similar to A dynamically extensible open cross document link service (20)
Recently uploaded
Recently uploaded (20)
A dynamically extensible open cross document link service
- 1. 2 December 2005 A Dynamically Extensible Open Cross-Document Link Service Ahmed A.O.Tayeh and Beat Signer Web & Information Systems Engineering Lab (WISE) Department of Computer Science Vrije Universiteit Brussel WEB & INFORMATION SYSTEMS ENGINEERING
- 2. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Isolated Digital Documents × 2 HTML document PDF document
- 3. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Isolated Digital Documents … 3 × × × Word document PDF document
- 4. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Cross-Document Link Service 4 HTML Gateway [Web Sockets + Messages Handling] Google Chrome local visual plug-ins external visual extension The Linking Model (RSL) TextHTML PDF data plug-ins visual PDF plug-invisual Text plug-in
- 5. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Cross-Document Link Service … Link snippets of information across different documents formats Dynamic extensibility avoid link service redeployment - data, visual and gateway plug-ins seamless integration of third-party document applications - no necessary changes to the core - third-party application extensions non-monolithic link service - customisation of supported document formats 5
- 6. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Dynamic Extensibility 6 Developer Document Plug-ins write and upload plug-ins End user Plug-in Tracking keep track and download plug-ins inject plug-ins at runtimeAcrobat Reader
- 7. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Requirements for Dynamic Extensibility R1: Flexible and extensible link service architecture extensible data and visual layer R2: Support multiple document formats existing as well as emerging document formats R3: Easy integration of third-party applications R4: Flexible communication channels R5: Customisable link service on-demand extensibility R6: Plug-in versioning deal with updates in document standards and applications 7
- 8. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Cross-Document Link Service Architecture 8 Visual Plug-ins Visualisation Third-Party Applications Visualisation DocFormat1 Visualisation DocFormat2 Browser Plug-in Tracker Update Manager Plug-in Tracking Online Plug-in Repository Data Plug-insVisual Plug-insGateways Online Repository Gateways Gateway DocFormat4 DocFormat4 Application DocFormat3 Application WebSockets Communication Message Pool Database Database Manager RSL DocFormat4 DocFormat3DocFormat2 DocFormat1 REST API TCP Sockets DocFormat3DocFormat2DocFormat1 Data Plug-ins Core Data Layer
- 9. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Visual Plug-ins DefaultDocument class necessary methods to visualise any document format - getSelector() - openDocument() - getResource() - showTarget() - … extends Java JPanel Component Visual plug-ins can use existing document libraries 9 Visual Plug-ins Visualisation Visualisation DocFormat1 Visualisation DocFormat2 Browser Plug-in Tracker Update Manager Plug-in Tracking Online Plug-in Repository Data Plug-insVisual Plug-insGateways Online Repository DocFormat2DocFormat1
- 10. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Third-Party Applications Extensions based on applications SDKs and APIs offer GUI actions for CRUD operations on links communicate with the link service - highlight, create, get, update anchors - link navigation - open documents - … 10 Third-Party Applications Gateways Gateway DocFormat4 DocFormat4 Application DocFormat3 Application WebSockets Communication Message Pool REST API TCP Sockets DocFormat3 Microsoft Word Add-in
- 11. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Third-Party Applications… Flexible communication channels REST API, WebSockets and TCP Sockets Gateway offers the following interface - openDocument() - getResource() - showTarget() - … JSON communication - each message must contain a command • {“command”: ”showTarget”, …} • {“command”: “openDocument”, …} • … 11 Third-Party Applications Gateways Gateway DocFormat4 DocFormat4 Application DocFormat3 Application WebSockets Communication Message Pool REST API TCP Sockets DocFormat3
- 12. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Online Repository Store different plug-ins data, visual, gateway plug-ins third-party application extensions Plug-in must contain specific metadata Extension-Mime, Extension-Type and Extension-Name Visual and gateway plug-ins must include Extension-Class metadata Example: 12 Visual Plug-ins Visualisation Visualisation DocFormat1 Visualisation DocFormat2 Browser Plug-in Tracker Update Manager Plug-in Tracking Online Plug-in Repository Data Plug-insVisual Plug-insGateways Online Repository DocFormat2DocFormat1
- 13. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Plug-in Tracking Update manager keeps track of available plug-ins in the online repository offers search functionality downloads plug-ins Plug-in tracker installs plug-ins ensures consistency of installed plug-ins keeps track and manages plug-ins in the link service Based on OSGi framework 13 Visual Plug-ins Visualisation Visualisation DocFormat1 Visualisation DocFormat2 Browser Plug-in Tracker Update Manager Plug-in Tracking Online Plug-in Repository Data Plug-insVisual Plug-insGateways Online Repository DocFormat2DocFormat1
- 14. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 OSGi Defines a dynamic modular system for Java applications Consists of three layers module layer: packaging code into bundles (plug-ins) life cycle layer: controls bundles at execution time service layer: communication between bundles Dynamic extensibility is achieved using the OSGi extender pattern 14
- 15. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Integrated Documents & Multimedia 15 PDF Visual Plug-in YouTubeGoogle Chrome Images Visual Plug-in
- 16. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Related Work Link Service R1:Extensible Arch. R2:Cross- Document Linking R2:Emerging Document Formats R3:External Applications R4:Flexible Channels R5:Customis- ability R6:Plug-in Versioning Intermedia () Sun’s Link Service () () () Microcosm () Annotea Solutions MADCOW FAST () Dynamic Link Service 16 Comparison based on the dynamic extensibility requirements
- 17. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Conclusion Fundamental requirements (R1-R6) for dynamically extensible cross-document link services Dynamically extensible link service support existing as well as emerging document formats without link service redeployment seamless integration of third-party applications customisation of installed document plug-ins Integration of different document formats and document applications 17
- 18. Ahmed Tayeh - Department of Computer Science - atayeh@vub.ac.beNovember 2, 2015 Future Work Usability evaluation Integration of other document formats and applications Enhanced desktop environment for document discovery 18
Editor's Notes
- Extend the link service with Word document
- The same example as before, extension to PDF acrobat Reader
- R1: documents have different models – different anchors, flexible to deal with new document format as well well as emarging document formats … R2: even if R1 is satisfied (in our case) we still need the intervention of developers
- Dashed stuff-----communication
- The extensibity on the linking browser has been realised by having a specific DefaultDocument class that has to be extended by the visual plug-ins for individual document document formats. The DefaultDocument class extends the Jpanel compoenent and offers some necessary methods to visualise any document format and any selector. The user interface instantiate any visual plug-in using the DefaultDocument class. Any local visual plug-in has to implement the abstract methods of the DefaultDocument class which are used by by the browser when visualising a document. Third-party visualisation libraries might be used when implementing a visual plug-in. We have, for example, used the ICEpdf library to implement a local visual plug-in for PDF documents.
- To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
- To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
- To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
- Keep track of available document formats by reading the different plug-ins metadata
- rely mainly on the life cycle layer checks modules metadata download modules via Secure Shell protocol inject modules at run time into OSGi running instance
- To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
- Extend the link service with Word document
- To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
- An interesting idea that can we have adopted to realise the open cross-document service is the proposal of the general cross-media annotation and link architecture by Signer and Norrie, which has been presented in this conference in 2009. The idea of their architecture has never been realised before. It’s basic idea is the separation of linking functionality from the annotated media and using external hyperlinks. The core link and annotation service knows how to deal with the core link and annotation model and is extensible to support new media types. The core linking model is based on the Resource Selector Metamodel which will be explained later. In order to have an extensible architecture Signer and Norrie suggested using data plug-ins for extending the core linking while using visual plug-ins to extend the linking service browser. Normally, when a link or annotation service is extended to support a new media type, also the user interface has to be extended to support the visualization of the new media type. Hence, with the use of visual plug-ins we will avoid a re-implementation and deployment of the entire user interface.
- An interesting idea that can we have adopted to realise the open cross-document service is the proposal of the general cross-media annotation and link architecture by Signer and Norrie, which has been presented in this conference in 2009. The idea of their architecture has never been realised before. It’s basic idea is the separation of linking functionality from the annotated media and using external hyperlinks. The core link and annotation service knows how to deal with the core link and annotation model and is extensible to support new media types. The core linking model is based on the Resource Selector Metamodel which will be explained later. In order to have an extensible architecture Signer and Norrie suggested using data plug-ins for extending the core linking while using visual plug-ins to extend the linking service browser. Normally, when a link or annotation service is extended to support a new media type, also the user interface has to be extended to support the visualization of the new media type. Hence, with the use of visual plug-ins we will avoid a re-implementation and deployment of the entire user interface.
- A central component in the linking architecture is the core link service which is based on the RSL metamodel. The RSL model is based on the concpet of linking arbitrary entities, whereby an entity can either be a resource, a selector or a link. A resource defines a media type such as a text, a video or a complete document. A selector is always attached to a resource and used to address parts of a resource. Finally, a link can be one-to-one, one-to-many, many-to-many bidirectional association between any entities. The core is extensible to support arbitrary document formats by providing a data plug-in consisting of a media-specific implementation of the resource and selector concepts. The data plug-in for a specific document format must provide the definition of its logical structure by extending the RSL resource class and further define how to create selectors within this struccture by extending the RSL selector class.
- The user interface is the linking service browser that visualizes the supported document formats and their hyperlinks. For each document format to be rendered in the browser, a visual plug-in must be implemented. The visual plug-in has two main responsibilities. First it has to render a specific document format and visualise any selectors that have been defined. Second, it should provide functionalities for the basic create, read , update and delete operations for a given document.
- Taking into account that many document formats come along with their own proprietary third-party applications, visual plug-ins also have to be provided for these applications. These external visual plug-ins do not directly support the CRUD operations on the underlying documents, but have to communicate with our link browser in order to exchange information about selectors to be activated or created.
- The extensibity on the linking browser has been realised by having a specific DefaultDocument class that has to be extended by the visual plug-ins for individual document document formats. The DefaultDocument class extends the Jpanel compoenent and offers some necessary methods to visualise any document format and any selector. The user interface instantiate any visual plug-in using the DefaultDocument class. Any local visual plug-in has to implement the abstract methods of the DefaultDocument class which are used by by the browser when visualising a document. Third-party visualisation libraries might be used when implementing a visual plug-in. We have, for example, used the ICEpdf library to implement a local visual plug-in for PDF documents.
- An external visual plug-in has to provide some methods to get and set selections in a document that is visualised in a third-party application. This can be achieved since most document applications provide their own SDKs or APIS. Furthermore, the external visual plug-in also has to provide the GUI actions for the necessary hyperlink CRUD operation which are offered by the browser for the local visual plug-ins. The communication between the linking browser and the external visual plug-in is achieved by a special gateway for the visual plug-in. The gateways is responsible for lunching the third-party application and to communicate information between the browser and visual plug-in. gateways should communicate with their visual plug-ins using a full-duplex communication protocol. However, we have also implemented a REST communication as a fallback in case that the third-party applications SKDs don’t support the full-duplex communication.
- We have decided to make use of the open Service Gateway intiative for the development of the link service. The OSGI specifications defines a dynamic modular system for java. Various server applications such as IBM Websphere apply the OSGI framwork and also the eclips IDE uses OSGi to enable the modularaisation of its compoennts as well as to support dynamic extensions via plug-ins. We decided to use it for many reasons, fist of all, it will enhance the modularisation of the linking service. It will also promotes the dynamic extensibility of the linking service. Last but not least, we will avoid the JAR hell in the case of the existence of multiple visual plug-ins for the same document formats.
- Each compoenent installed in the OSGI framework has to provide it’s OSGI manifest. In contrast to Java, OSGi modules do not share arbitrary code but they have to explicitly define export packages to be shared and import packages to be used. Hence, due the clear definition of exported functionality, code can’t be misused by other installed modules.
- Here we present a link navigation scenerio. The Registry is a compoent that keep track of all installed visual plug-ins. DocFirmat1 and DocFormat2 are local visual plug-ins while DocFormat3 is an external visual plug-in and this is its gateway. When a user clicks on a hyperlink in a document that is visualised in the browser, the browser communicated with the core RSL to retreive the target document and it’s selectors inclusive the target selector of the selected link. The Registry then is asked for information about the visual plug-in for the target document. If the target document has a local visual plugin, then the command will be forwarded the main class in the visual plug-in , the main class in the class extending the DefaultDocument class, while if it has an external visual plug-in, then gateway will lucnch the application and then forward the request to open the document with its selectors.
- Our cross-document link service currently supports the linking of HTML, PDF, text and XML documents, The browser is able to visualise XML, text and PDF documents via local visual plug-ins while the visualisation of HTML documents in delegated to Google Chrome web browser. This screenshot shows a bi-directioanl link between XML and PDF documents as well as a PDF and HTML documents. For more information about the different document formats data and visual plug-ins please refer to our paper.
- Actually documents do not exist in isolation, but have relationships with other documents. The relationship can be explicit via explicit links or footnotes or can be implicitly established on the similarity of content in different document formats.
- Open Hypermedia systems had a significant impact in enhancing the management of hyperlinks. However, open hypermedia systems had two major shortcomings. First of all, they didn’t investigate the possibilites for creating hyperlinks between snippets of information in different document formats. Second, it is not clear how to extend these systems to support cross-document linking on the model as well as the application layer. Moreover, annotation systems have a significant enhancement for external linking of some document formats. However, they have the same shortcomings as open hypermedia systems. For example, if a new media type has to be supprted in MADCOW which is implemented as a monolithic component, then a new version of the user interface has to be deployed.
- The user interface is the linking service browser that visualizes the supported document formats and their hyperlinks. For each document format to be rendered in the browser, a visual plug-in must be implemented. The visual plug-in has two main responsibilities. First it has to render a specific document format and visualise any selectors that have been defined. Second, it should provide functionalities for the basic create, read , update and delete operations for a given document.
- The user interface is the linking service browser that visualizes the supported document formats and their hyperlinks. For each document format to be rendered in the browser, a visual plug-in must be implemented. The visual plug-in has two main responsibilities. First it has to render a specific document format and visualise any selectors that have been defined. Second, it should provide functionalities for the basic create, read , update and delete operations for a given document.
- Actually documents do not exist in isolation, but have relationships with other documents. The relationship can be explicit via explicit links or footnotes or can be implicitly established on the similarity of content in different document formats.
- A central component in the linking architecture is the core link service which is based on the RSL metamodel. The RSL model is based on the concpet of linking arbitrary entities, whereby an entity can either be a resource, a selector or a link. A resource defines a media type such as a text, a video or a complete document. A selector is always attached to a resource and used to address parts of a resource. Finally, a link can be one-to-one, one-to-many, many-to-many bidirectional association between any entities. The core is extensible to support arbitrary document formats by providing a data plug-in consisting of a media-specific implementation of the resource and selector concepts. The data plug-in for a specific document format must provide the definition of its logical structure by extending the RSL resource class and further define how to create selectors within this struccture by extending the RSL selector class.
- Limitations of the link service extensiblity
- Actually documents do not exist in isolation, but have relationships with other documents. The relationship can be explicit via explicit links or footnotes or can be implicitly established on the similarity of content in different document formats.
- To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
- We have decided to make use of the open Service Gateway intiative for the development of the link service. The OSGI specifications defines a dynamic modular system for java. Various server applications such as IBM Websphere apply the OSGI framwork and also the eclips IDE uses OSGi to enable the modularaisation of its compoennts as well as to support dynamic extensions via plug-ins. We decided to use it for many reasons, fist of all, it will enhance the modularisation of the linking service. It will also promotes the dynamic extensibility of the linking service. Last but not least, we will avoid the JAR hell in the case of the existence of multiple visual plug-ins for the same document formats.
- We have decided to make use of the open Service Gateway intiative for the development of the link service. The OSGI specifications defines a dynamic modular system for java. Various server applications such as IBM Websphere apply the OSGI framwork and also the eclips IDE uses OSGi to enable the modularaisation of its compoennts as well as to support dynamic extensions via plug-ins. We decided to use it for many reasons, fist of all, it will enhance the modularisation of the linking service. It will also promotes the dynamic extensibility of the linking service. Last but not least, we will avoid the JAR hell in the case of the existence of multiple visual plug-ins for the same document formats.
- Each compoenent installed in the OSGI framework has to provide it’s OSGI manifest. In contrast to Java, OSGi modules do not share arbitrary code but they have to explicitly define export packages to be shared and import packages to be used. Hence, due the clear definition of exported functionality, code can’t be misused by other installed modules.
- To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
- Taking into account that many document formats come along with their own proprietary third-party applications, visual plug-ins also have to be provided for these applications. These external visual plug-ins do not directly support the CRUD operations on the underlying documents, but have to communicate with our link browser in order to exchange information about selectors to be activated or created.
- We have decided to make use of the open Service Gateway intiative for the development of the link service. The OSGI specifications defines a dynamic modular system for java. Various server applications such as IBM Websphere apply the OSGI framwork and also the eclips IDE uses OSGi to enable the modularaisation of its compoennts as well as to support dynamic extensions via plug-ins. We decided to use it for many reasons, fist of all, it will enhance the modularisation of the linking service. It will also promotes the dynamic extensibility of the linking service. Last but not least, we will avoid the JAR hell in the case of the existence of multiple visual plug-ins for the same document formats.
- To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
- Taking into account that many document formats come along with their own proprietary third-party applications, visual plug-ins also have to be provided for these applications. These external visual plug-ins do not directly support the CRUD operations on the underlying documents, but have to communicate with our link browser in order to exchange information about selectors to be activated or created.