[
https://jira.duraspace.org/browse/DS-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19068#action_19068
]
Joseph Rhoads commented on DS-819:
----------------------------------
Just a couple of updates:
Masking was perhaps not the best word to use. Filtering is more appropriate.
I come from a mathematics and computer visualization background. Masking and
bitmasking, are used in the numpy and various graphics libraries to represent
the idea of covering/exposing select portions of arrays of data. In the world
of search and information exposure, filters are a more appropriate word.
So I'm looking at applying filters or streams of filters to the metadata we get
on items. I'm looking at choosing which filters to apply based on the
community/or collection, and what group a person belongs to.
I've changed my approach from editing MetadataExposure.java to removing
(filtering out) entries in the Array dcvs that we get from item.getMetadata()
I'm using the Predicate/Collection filter approach outlined by "Alan" on
http://stackoverflow.com/questions/122105/java-what-is-the-best-way-to-filter-a-collection
There are some awesome tools in the google collections library
(http://code.google.com/p/google-collections/) now incorporated into Guava
(http://code.google.com/p/guava-libraries/)
that would do this, but rather than adding a new codebase-dependency, I wrote a
couple of classes just to test it out.
Right now I'm testing this in the ItemAdapter in the XMLUI
and I'm using the existing MetadataExposure class as part of my predicate.
I've also tried Predicates based on hard coded strings. A predicate that always
returns true, and a predicate that always returns false.
So far I've been fairly successful at filtering the metadata. I haven't tried
to form a stream of filters yet, but it's in the works.
After that, I can add filters to a filter-stream based on the metadata's owning
collection and the group a person belongs to.
-Joseph
> Metadata Masking
> ----------------
>
> Key: DS-819
> URL: https://jira.duraspace.org/browse/DS-819
> Project: DSpace
> Issue Type: New Feature
> Components: DSpace API
> Reporter: Joseph Rhoads
>
> Dear Dspace community,
> I'm working on a project that needs to have different layers of access to
> metadata fields. (ie. Only certain people/groups should have access to
> certain metadata fields). I'm wondering if any in the dspace community have
> any ideas or experiences with this sort of thing? I'm gonna throw out some
> ideas to see if anyone is interested.
> I know that there are currently a couple of options related to items access,
> + You can let anonymous users view some info in the search/browse results
> + Then approved users/groups can have full-item read access (minus fields
> that are designated for administrators)
> + Administrators can see all fields (including those designated
> metadata.hide..... in the dspace.cfg file.)
> What I'm thinking about includes the following:
> + Adding the ability to create masks or streams of masks that can be applied
> at the community or collection level, and to specific groups.
> + Each mask would simply be a set of (metadata key, boolean value) pairs
> + I think collection administrators should be able to edit the masks though
> the web interface
> + And that the OAI indexing should be viewed as another group or person for
> this purpose.
> I have some questions:
> + Should the mask be on the display end(post SQL request) or the request
> end(pre SQL request)?
> + Presumably these masks would be persistent, where should they be stored?
> This topic is related to the following JIRA issues
> https://jira.duraspace.org/browse/DS-800
> https://jira.duraspace.org/browse/DS-716
> https://jira.duraspace.org/browse/DS-655
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
