helix84,
I'm trying to restrict some items from appearing in oai and it's not quite
working. This is the filter I added to the xoai.xml:
<Filter id="driveraccessFilter2">
<Class>org.dspace.xoai.filter.DSpaceAtLeastOneMetadataFilter</Class>
<Parameter key="field">
<Value>dc.rights.restrict</Value>
</Parameter>
<Parameter key="operator">
<Value>contains</Value>
</Parameter>
<Parameter key="value">
<Value>RESTRICTED</Value>
</Parameter>
</Filter>
On Mon, Apr 8, 2013 at 11:58 AM, Jose Blanco <[email protected]> wrote:
> Great. Thank you!
>
>
> On Mon, Apr 8, 2013 at 11:54 AM, helix84 <[email protected]> wrote:
>
>> On Mon, Apr 8, 2013 at 5:33 PM, Jose Blanco <[email protected]> wrote:
>> > 1. In the old oai we used to put the dc values associated with a
>> particular
>> > format in crosswalks dir (say we wanted to add a particular dc value, or
>> > remove one from the response). I think in this version of oai, if we
>> want
>> > to change anything from the out-of-the-box, we go to
>> > crosswalks/oai/metadataFormats and change the xsl, right?
>>
>> That's correct. You will also need to run "[dspace]/bin/dspace oai
>> clean-cache" to get rid of the pre-cached OAI responses.
>>
>> > 2. I'm going to try using the solr instance for oai in production, if
>> the
>> > oai setup hiccups or I have to stop it because performance is bad on our
>> > instance, this will not mess-up the solr index used by our instance,
>> right?
>>
>> If you mean your Solr index used by Discovery, then no it will have no
>> effect. Discovery uses a Solr core (Solr terminology for index) called
>> "search". OAI uses its own core called "oai".
>>
>> If you interrupt "oai import -c" or "oai import", you should be simply
>> able to resume where you left of by running "oai import".
>>
>> Generally speaking, if something goes horribly wrong, either with the
>> "search" or "oai" core, it is trivial (although time-consuming) to
>> recreate them from the DB. The only data you don't want to lose is the
>> "statistics" core (if you're using Solr statistics).
>>
>> > 3. Presently when a search/browse is done against solr, items that have
>> > READ access to a particular group will not be exposed, unless the user
>> is a
>> > member of that group. So I would expect that users of oai would fall
>> under
>> > the Anonymous category and so no items with READ permission set to a
>> group
>> > should be exposed in oai. This may be a question for Mark Diggory, but
>> > wanted to check if you knew the answer.
>>
>> No, I don't think OAI 2.0 respects that and I'm not sure the old OAI
>> did, either. Moreover, it doesn't respect items marked as "private"
>> (discoverable=false) because private items and the new OAI were 3.0
>> features developed in parallel, so they don't work together just yet.
>>
>> But it is relatively simple to configure a "filter" in XOAI
>> configuration which will filter out items based on any metadata value.
>> Read more here:
>>
>> https://wiki.duraspace.org/display/DSDOC3x/OAI+2.0+Server
>>
>>
>> Regards,
>> ~~helix84
>>
>> Compulsory reading: DSpace Mailing List Etiquette
>> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>>
>
>
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
