Changes between Version 5 and Version 6 of CmdiPortal


Ignore:
Timestamp:
07/30/09 12:03:53 (15 years ago)
Author:
vronk
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • CmdiPortal

    v5 v6  
    66== Components and Deployment ==
    77CmdiPortal and MDService are tightly intertwined. Plus there is a bunch of further related components.
    8 Following a first sketch on components interdependencies and deployment situation around CmdiPortal and MDService, that wait to be verbosed and refined yet.
     8Following a first sketch on components interdependencies and deployment situation around CmdiPortal and MDService, that waits to be verbosed and refined yet. Especially [[span('''AAI completely missing''', style="color:red;")]] here as well yet!
    99
    10 [[Image(CmdiPortal_MDServices_v3.png,650)]]
    11 [[Image(Deploy_MDServices_v3.png,500)]]
     10''Figure 1 CMDIPortal, MDService and interacting/related components''[[BR]]
     11[[Image(CmdiPortal_MDServices_v3.png,630)]]
     12
     13''Figure 2 One possible deployment situation for CMDIPortal, MDService & co.''[[BR]]
     14[[Image(Deploy_MDServices_v3.png,480)]]
    1215
    1316== Web User Interface ==
    … …  
    1518The interface should/could integrate various components. From the point of view of the user it could be a comprehensive toolbox, where everything is reachable within a click. :)
    1619
     20''Figure 3 This is a tentative sketch of a possible user interface already in a highly evolved stage.''
    1721[[Image(portal_gui.png)]]
    1822
    19 This is a tentative sketch of a possible user interface already in a highly evolved stage. The building blocks are:
     23Following the building blocks are discussed, but beware that these terms will probably get increasingly fuzzy, because for example detail view of a Virtual Collection MD record will be a MD collection itself, which means a list of MD entries! :
    2024 Search/Browse::
    2125   This is where every workflow starts. It has multiple tabs: Browsing (Catalogue), Searching, Bookmarks etc.
    2226   But a more "organic", hybrid approach shall be examined (ie mixing of Browsing and Searching).
    2327   Controls MDList.
    24  MDList::
    25    Here the results of a search or the members of a category are listed.[[BR]]
     28 MDList/Tree::
     29   Here the results [MD collection] of a search or the members of a category are listed.[[BR]]
    2630   ~ One MD record in one row.[[BR]]
    2731   As we want the searching very flexibel etc. it may be, that the distinction between the Search block and MDList will not be that clear,
    … …  
    2933 MDDetail::
    3034   A detail view for one Metadata record. Controlled by the MDList.
    31  !PrivateWorkspace::
     35 Local/PrivateWorkspace::
    3236   This block is similar to the Browse block and could be probably even integrated in the main Search/Browse control.
    33    The important distinctive function is, that this block does not show data from (Central) MetaDataRepository, but rather local data,
    34    ie data available on user's machine. Be it private resources, resources downloaded from the repository or results of processing existing resources.
    35    This component would accordingly (unlike all the other components) need access to local file system. This will require the user to install this component on her machine, be it a firefox extension, some mini-java-app or any other sort of standalone application.
    36    To not put pressure on the user to install anything, this component has to be optional, installable on demand.
    37    This component shall be very tiny, it should be really only concerned with managing and enriching the local data and providing the information to the rest of the system.
     37   The important distinctive function is, that this block does not show data from (Central) MetaDataRepository, but rather local data, ie data available on user's machine. Be it private resources, resources downloaded from the repository or results of processing existing resources.[[BR]]
     38   This component would accordingly (unlike all the other components) need '''access to local file system'''. This will require the user to install this component on her machine, be it a firefox extension, some mini-java-app or any other sort of standalone application. To not put pressure on the user to install anything, this component has to be optional, installable on demand.[[BR]]
     39   This component shall be very tiny, it should be really only concerned with reaching out to the local data (managing and enriching them) and providing the information to the rest of the system.
    3840 !ResourceViewer::
    3941   An extensible container for displaying the resources. See [[CmdiPortal#resource-viewer Section: Resource Viewer]]
    4042 WorkflowEngine::
    4143   In a advanced stage of evolution, there should be integration or a tight interoperability between the MD-Browser and the Workflow-Engine.
    42    The utopic scenario is to use MD-Browser for finding the Resources, both content and tools and just drag them into the graphical WorkflowEngine pane, rearranging them, equipping them with necessary parameters and running the workflow, the results automatically being added in the Results tab of user's workspace.
     44   The ''utopic scenario'' is to use MD-Browser for finding the Resources, both content and tools and just drag them into the graphical WorkflowEngine pane, rearranging them, equipping them with necessary parameters and running the workflow, the results automatically being added in the Results tab of user's workspace.
    4345
    4446=== Resource Viewer === #resource-viewer
    4547While CMDI is primarily about metadata, to really make a difference to just a collection of links, it seems necessary to integrate a resource viewer in the long run. Of course every Resource type requires a different view and there are many ways one can look at every resource.
    46 The idea here is to provide a kind of an extensible container, which based on the provided metadata tries to reach the actual resources and display them as good as it can. The important thing here ist "extensible", meaning new kinds (novelty implementations) of displaying resources can be incorporated in the infrastructure on this hook.
     48The idea here is to provide a kind of an extensible container, which based on the provided metadata tries to reach the actual resources and display them as good as it can. The important attribute here is "extensible", meaning new kinds (novelty implementations) of displaying resources can be incorporated in the infrastructure at this hook.
    4749
    4850So ResourceViewer is a abstract class/interface, which will be base for different implementations.
    49 First two implementations, that would already provide for good show cases are `CorpusViewer` and `ResourceStats`.
     51Following a few ideas for derived classes / implementations, that would already provide for good show cases:
    5052
    51  ResourceStats::
     53 `CorpusViewer`::
     54  see next section
     55 `ResourceStats`::
    5256   A generic viewer trying to give an overall look on the resource. Probably it also needs to be typed respectively to resource type.
    53    It should give information about all kind of count (tokens, sentences, documents, entries, bib-usage, etc...)
     57   It should give information about all kind of count (tokens, sentences, documents, entries, bib-usage, etc...). The question is, to which extent this information would have to be provided by the resource provider via a specific interface, or how much is already contained in the MD, making it just some pimped up MDDetail view.
     58 `Audio/Video Viewer`::
     59   listen to the spoken corpus, watch the video!
     60 `Generic_iFrame`::
     61   really just a placeholder for integrating a user interface provided by the resource provider.
     62   This will look nasty (the patchwork will be recognizable visually), but would be fast to do.
     63   Don't know if useful really.
    5464
    5565==== Corpus Viewer ====
    5666A considerable part of the language resources is text corpora. Corpora require a specific user interface, the minimum requirement being some kind of query-interface and a KWIC-display of the results. This can be extended in many ways, but this is a necessary minimum. Plus there is the server side to this, a Corpus Query System, capable of answering the queries exactly and fast based on its prebuilt indices.
    5767
    58 There is already a few (very good) implementations of this system, every corpus has to use one. Some of them provide even a API, allowing to query the corpus from own/third applications. The idea for the CorpusViewer is to provide a query interface + KWIC-display (+ everything else in the long run) based on the APIs provided, querying the corpora where it is, ie communicating with the corpus query system at the content provider's site. (Let's forget problems with workload and performance for now.)
     68There is already a few (very good) implementations of this system, as every corpus has to use one. Some of them provide even an API, allowing to query the corpus from own/third applications. The idea for the CorpusViewer is to provide a query user interface + KWIC-display (+ "everything else" in the long run) based on the APIs provided, querying the corpora where it is, ie communicating with the corpus query system at the content provider's site. (Let's forget problems with workload and performance for now.)
    5969
    6070There are two implementations (i know of) which seem to lend themselves happily / suit fine in this scenario:
    … …  
    6474Both are open source, provide a very expressive query language, scale fine, robust and proven in production environments.
    6575manatee/bonito is used by both Slovak and Czech National Corpora and Korpus Südtirol, 
    66 ddc is used by DWDS - Berlin, Schweizer Text Korpus and a unique corpus cooperation project C4. (and most probably a few more)
     76ddc is used by DWDS - Berlin, Schweizer Text Korpus - Basel and a unique corpus cooperation project C4 (and most probably a few more).
     77
    6778Furthermore manatee builds the base for SketchEngine - a next generation query tool
    68 and ddc comes with integrated functionality for distributed corpora, ie the data are user-transparently spread across network.
    69 They both provide thin APIs in perl and/or python.
     79and ddc comes with integrated functionality for distributed corpora, ie the data are user-transparently spread across network. They both provide thin APIs in perl and/or python.
    7080
    71 With such a Corpus Viewer implemented the CLARIN user would be (technically) able to query these existing corpora (running on these Corpus Query System) and a Corpus Service could be introduced to accomodate various "homeless" corpora from CLARIN member research groups, then also reachable via this components, integrated in the CMDI Portal.
     81With such a Corpus Viewer implemented, the CLARIN user would be (technically) able to query the existing corpora (running on these Corpus Query System), theoretically even heterogenously, ie multiple corpora with different format and running on different CQS could be queried at once. Also a `Corpus Housing Service` could be introduced to accomodate various "homeless" corpora from CLARIN member research groups, then also reachable via this components, integrated in the CMDI Portal.
    7282
    7383Wouldn't that be nice? ;)
    7484
    7585== Profile ==
    76 The proposed workspace shall be highly personalizable. This information shall be stored in a profile.
    77 Multiple profiles can be managed by one user (correspond to different workspaces).
     86Propositions:
     87 * The proposed workspace shall be highly personalizable.
     88 * This information shall be stored in a profile.
     89 * Multiple profiles can be managed by one user (correspond to different workspaces).
     90 * The internal format for profiles be JSON.[[BR]]
     91 * We can have personal and project/team profiles.[[BR]]
     92 * A project team could/should share a common project profile.
     93 * We need to think of overlaying multiple profiles.
     94 * Despite anticipated heavy use of AJAX, any given workspace-state shall be linkable, for example by providing `linkToThis()` method which would freeze the state of application as Profile[JSON] and publish this under a generated link.
    7895
    79 The internal format for profiles be JSON.[[BR]]
    80 We can have personal and project/team profiles.[[BR]]
    81 A project team could/should share a common project profile.
    82 
    83 We need to think of overlaying multiple profiles.
     96== Samples ==
     97Here screenshots of existing systems, user interfaces shall be collected, as base for discussion. Ideas:
     98 * Flamenco Faceted Search at clarin.eu