Topics Matej@Nijmegen 2010-08

Bringing together the topics which I want discuss + linking to corresponding material.

MDService/Browser

• situation: MDServiceImpl
• next steps: MDServiceImpl
• towards: MetadataBrowser#RepositoryMatrix
• ? Should user be able to search in Components (not just Elements) - yes
  -> ! if user selects a Component - provide subtree contextually
  -> ! 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 ​example queries
  • show counts to Collections - ok
  • show only used Terms (same as above - based on Repository Statistics)
• provide trivial ResourceViewer?
  easy to accomplish in the minimal version (iframe or new window for for audio/video-files) and nice to show;
  -> 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
  

-> reverse OLAC->IMDI-bridge? #5
-> 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. 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:
  24 Profiles in June​
  39 Profiles in August​
  -> 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)
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?)
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..