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

Notes de l'éditeur

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.
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
Extend the link service with Word document
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.
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
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.

A dynamically extensible open cross document link service

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

A dynamically extensible open cross document link service

Plus De Contenu Connexe

Similaire à A dynamically extensible open cross document link service (20)

Plus récents (20)

A dynamically extensible open cross document link service

Notes de l'éditeur

A dynamically extensible open cross document link service

Vous êtes en train de lire un aperçu.

A dynamically extensible open cross document link service

Suggestions

Plus De Contenu Connexe

Similaire à A dynamically extensible open cross document link service (20)

Plus récents (20)

A dynamically extensible open cross document link service

Notes de l'éditeur