Changes between Version 1 and Version 2 of MDCuration

Timestamp:

01/08/14 08:58:03 (10 years ago)

Author:

vronk

Comment:

--

MDCuration

@@ -25 +25 @@
 The processing should ideally be encapsulated as a service, that can be called both by the data providers (the metadata editors) directly, during the process of metadata creation and by the harvester of repositories post-processing the collected data.
 
-The output of the quality check could be fed into VLO (as some recommendation/ranking widget for in the individual md-record view), but should primarily be available (as a report) to the content providers, so that they can see, what needs to be fixed with their data.
+The output of the quality check could be fed into VLO (as some recommendation/ranking widget for in the individual md-record view), but should primarily be available (as a report) to the content providers, so that they can see, what needs to be fixed with their data. As such, it has ties to the ''monitoring'' work package.
 
 
@@ -52 +52 @@
 See also [[http://www.clarin.eu/node/3775|CMDI Interoperability Workshop]] (with presentations to DC/OLAC, TEI, METASHARE).
 
-One tool to explore and inspect the profiles is the [[clarin.oeaw.ac.at/smc-browser|SMC-browser]]. It compiles the information from the Component Registry and ISOcat into a graph, visualizing the reuse of components and data categories. It is planned to hook it with the instance data, which would allow to see where which profiles, components, data categories are used.
+One tool to explore and inspect the profiles is the [[http://clarin.oeaw.ac.at/smc-browser|SMC Browser]]. It compiles the information from the Component Registry and ISOcat into a graph, visualizing the reuse of components and data categories. It is planned to hook it with the instance data, which would allow to see where which profiles, components, data categories are used.