= Topics Matej@Nijmegen 2010-08 =
Bringing together the topics which I want discuss + linking to corresponding material.


== MDService/Browser ==
 * situation: [wiki:MDServiceImpl#Currentstatusofimplementedfunctionality]
 * next steps: [wiki:MDServiceImpl#Nextsteps]
 * towards: MetadataBrowser#RepositoryMatrix
 * ? Should user be able to search in Components (not just Elements) - yes[[BR]]
   -> ! if user selects a Component - provide subtree contextually[[BR]] 
   -> ! optimally provide the list of `Terms`  with only Components and Elements used in given collection (with numbers from Repository Statistics)
 * Find the data! (improve (invert) data/click ratio):
   * by providing [http://trac.clarin.eu/wiki/MDService_Example_Queries example queries]
   * show counts to Collections - ok 
   * show only used Terms (same as above - based on Repository Statistics)
 * provide trivial ResourceViewer[[BR]]
   easy to accomplish in the minimal version (iframe or new window for for audio/video-files) and nice to show;[[BR]]
   -> it should be possible to use the `ResourceRef`-handle to get to the resource

== MDRepository  ==

 * ! setup eXist-mirrors (vienna, mpi)
 * ! we need more heterogeneous (test-)data[[BR]]
     -> reverse OLAC->IMDI-bridge? #5[[BR]]
     -> data from clarin.eu/inventory! #6
 * ?How is/should be the MDRecord (instance) to schema/profile referencing done?
     MDRecords should have the usual schema-reference in the root-element. (At least those produced by Avril)
     But there is no guarantee. [wiki:MDServiceImpl#Openquestions some remarks on that]

=== Issues with eXist-implementation ===
 * serve: Collections, Values
 * Boolean-search (progress)
 * count profiles (by what? root-element/Component?) - depends on record->profile referencing
 * OAI-Harvester
 * performance

=== Alternative Implementations ===
At least Until NEERI-October we concentrate on eXist. Still we should investigate especially the Zebra-suite at some point.
CmdiRepository#AlternativeImplementations

== ComponentRegistry ==

 * show Statistics:[[BR]]
   24 Profiles in [source:MDService2/trunk/MDService2/WebContent/static/profiles_stats_20100622.html June] [[BR]]
   39 Profiles in [source:MDService2/trunk/MDService2/WebContent/static/profiles_stats_20100802.html August] [[BR]]
   -> partly identical(?) new profiles! -> How to discourage profile creation?!
 * ! adopt User/AAI-Login

=== Workflow / Curation ===
Proposals for work(flow) within Component Registry, aiming at ensuring the quality of the profiles and encouraging reuse:
 peer review::
  4-eyes principle before publishing, a special `quaranteen-status` for the profiles (between `private` and `published`)[[BR]]
  trac or some forum for discussions of the issues (but keep the process fast and simple) 
  can test peer review informally on profiles: `web applications`, `text-corpus`
 rating::
  after publishing - users: ''"i found this profile useful [0-5]"'' + comment (up to ticket on trac?)[[BR]]
  contra: little users
 deprecate::
  allow status `deprecated` for profiles and components (linking to the new version?)
 remove::
  at some point we may allow removing profiles/components deprecated for a long time (# years),
  probably under the condition, that a mapping/conversion routine is available to transform the metadata instantiating the deprecated profile to a format complying to some active profile. The conversion routines may be provided by the authors or by the registry providers. This shall nevertheless stay an exception, as it actually breaks the contract.

== SemanticMapping / RelationRegistry ==
 * above statistics illustrate '''level1-SM''', ie CompReg-based mapping between Elements and Datacategories
 * We start mapping only datacategories (not Components)
 * But sooner of later the issue of ''Container-Datacategories'' (mapping to Components) seems relevant
 * ? Who cares for other DCR (dublincore, ...)? Every service on its own or shall isocat proxy?
 * In the first step the relations will be added "manually".  
   -> TODO: define mapping dc -> imdi (or whatever is in the Repository) to be able to use dublin-core for searching
 

== Server security ==
get experience/know-how regarding / check configuration of linux-servers/apache/tomcat...

== Other ==
 * ! we shall create a commons-package in subversion - for shared xsl-stylesheets and stuff..