|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
I completely agree that what should count as indexable is fairly open-ended. We were deliberately *very* conservative in the first implementation because the impression we got from GS was that they favored precision/accuracy over volume. Remember, this isn't Google, but Google Scholar, who have a much more constrained 'content model'. I can see that a Word file or the like could make sense as 'pdf_url', but a website, a CSV dataset, etc? (These are things that we have in ORIGINAL bundles, and much more). I grant that they can likely be indexed, but am unsure if GS wants them swimming in the same pool as scholarly articles...
Having said all this, if Scholar is signally that they want want more content (types), let's relax the constraints and see what happens.
Andrea, as to configurability, you put your finger on the issue: we could put an interface up that would allow plug-in code, but that would raise the bar pretty high for local customization. We didn't get the time to work on it, but I can share what my thinking was at the time, if I can remember ;-)
I was playing with path-like specification strings, such as:
1721.1/23/ORIGINAL/*.pdf, 1721.1/34/CONTENT/*.*, */*/*.pdf
etc where the first part of the path was collection handle (or '*' or 'default' etc, for the default case), the second part was bundle name, and the third part was the bitstream filename with standard 'globbing' rules.
One could have any number of these (including 1), and they would be applied where your patch code would be. There may a be bit of work to make this efficient, so I'm not saying we should drop in something like this quickly
Richard