Open yarikoptic opened 6 years ago
I am even thinking that may be (some) extractors should provide a minimal set of harmonized fields, eg shortdescription (authors etc are too varying in formats). May be something from biocaddie effort could be reused to expand
@mih What do you think about the need to harmonize just a few (well -- short description atm) fields?
Properly marked up metadata with substantially improved possibilities for harmonization are available via reporting and extractors in the metalad extension. It was decided to keep this out of 0.12, hence removing milestone association.
What is the problem?
0.9.x version relies on harmonized metadata of the dataset, which it includes in the "metadata" of the webui (ATM separate from "regular datalad metadata" - provides information about sizes for this particular instance of git/git-annex etc) : https://github.com/datalad/datalad/blob/master/datalad/interface/ls_webui.py#L127 so then https://github.com/datalad/datalad/blob/master/datalad/resources/website/assets/js/main.js#L482 includes that dataset metadata record into the the row information so users could do a simple search using the searchbar on the page and extracts harmonized (in 0.9.x) "title" field within metadata to provide description within the table: https://github.com/datalad/datalad/blob/master/datalad/resources/website/assets/js/main.js#L472
With master version there is no harmonization of metadata across extractors attempted whatsoever.
ls_webui.py
referenced above). I think this would be the easiest/most reasonable thing to dopossible additional pros/cons to consider /decide upon
datalad_unique_content_properties
, if we do not strip them for web ui view, it would allow to search within those (only within the view of the dataset level, i.e. could search at ///openfmri level among those values). but it might blow up amount of data to be transferred/cached on client side while initially browsing the collectionWhat do you think @mih and @bpoldrack ?