Hi Jose,

all filters are inclusive filters (they are used to include items, not to
exclude them). That is, using that filter XOAI will show those items
with RESTRICTED
on dc.rights.restrict.

If you find it too hard to implement, we do offer XOAI specific project
configuration services, more info at the signature.

Best regards,
João Melo


On 11 April 2013 20:24, Jose Blanco <[email protected]> wrote:

> 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
>



-- 
Thanks, João Melo (My Portfolio <http://www.lyncode.com/m/jmelo/>)
DSpace Department
*Lyncode*: Official
website<http://www.google.com/url?q=http%3A%2F%2Fwww.lyncode.com%2F&sa=D&sntz=1&usg=AFrqEzdV8iS6rMxflxnn138XReuRfUG3OQ>
[image: Follow us on
Facebook]<http://www.google.com/url?q=http%3A%2F%2Ftwitter.com%2Flyncode&sa=D&sntz=1&usg=AFrqEzeDuT3ZqMW5uVIA8AoxtTtAeiCX3Q>
<http://www.google.com/url?q=http%3A%2F%2Fwww.facebook.com%2Flyncode&sa=D&sntz=1&usg=AFrqEzcWXjHa3gKBGLsNVxktapxkiWDnww>
------------------------------------------------------------------------------
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

Reply via email to