Changes between Version 8 and Version 9 of CmdiCollections

Timestamp:

09/14/10 12:47:40 (14 years ago)

Author:

vronk

Comment:

--

CmdiCollections

@@ -78 +78 @@
 Also the question is not completely solved about identifying the collections. Currently we use the handles in `MdSelfLinks`, which were replaced with collection-paths where the handles were missing or not unique. This is not very satisfying as the handles are meaningless and bulky. The collection-paths are meaningful but still bulky, but mainly they are just a temporary workaround around the missing handles. They are probably not usable in production as they are derived from the implicit folder hierarchy, which is confusing. Of course the user is presented with the names, which are then translated to IDs, but the question, if it wouldn't be possible to define meaningful identifiers for the collections  (e.g. domain-names-like).
 {{{
-  mpi.dobes.1
+  mpi:dobes:1
+  clarin-at:aac-test-corpus:sozialismus:1
 }}}
 
@@ -87 +88 @@
 (This is in the context of the basic setup, where the user defines his VC in MDBrowser (and publishes it to VCR) and wants to continue with querying this VC. Thus only MDBrowser/MDService know about both the query and the VC.)
 
-The three possible solutions: 
+Proposed solutions: 
  Virtual Collection is in the MDRepository::
    It is actually planned to harvest the VCR by MDRepository, so eventually all VCs should end up in the Repository..[[BR]]
@@ -93 +94 @@
    or if they are handled separately, applying them as filter on the fly (filtering the result of the actual query, before sending the final result)[[BR]]
    The problem is the '''harvesting-latency'''.
+ POST the VC to MDRepository::
+   To bridge the harvesting latency, we could think of POST-ing the VC to the MDRepository, when it's not yet inside, so that it can use it for efficient filtering of the actual query. This would require special interface on MDRepository
  Apply VC afterwards::
    In this variant MDRepository could be agnostic of VCs. It would just run the query. MDService would fetch the VirtualCollection and apply it as filter on the result of the MDRepository-query.