Late last year, we introduced some incredibly compelling capabilities that allowed users to collaborate with each other inside of Oracle Endeca Information Discovery (OEID) 3.0. Our collaborative discovery extension allowed users with certain permissions to delete records, edit attributes of records and add attribute values to existing attributes, all from within OEID Studio. It’s an incredibly powerful way to assist in data cleanup, data flagging or grouping certain records together with applicability to almost every data discovery scenario. We’re pleased to announce that we’ve re-launched this functionality and it is now available for licensed users of OEID 3.1. The same great capabilities that have always been there remain, but we’ve given it a bit of a facelift as part of the upgrade, as you can see below.
Deleting Misleading or Invalid Records
Occasionally incorrect or misleading data will find its way into a given application. If it has no business being there or has an unwanted, adverse affect, let’s get rid of it! Hey, this tweet has nothing to do with the Olympics! Bye, bye spammer!
Augmenting Existing Records With More Attribution
In addition, users may find something interesting on a record (or set of records) and want to take action to augment the attribution of the record. Below, two terrorist incidents (from one of our internal applications) have been identified as possibly having links to ISIS based on location: The data can be augmented by selecting the field to hold this additional information (for simplicity sake, we added it to “Themes”)… …adding the additional value (or values):
Replacing Existing Attributes on Records
In the same vein as the first use case, users may find a record or set of records where they want to set a brand new value for an attribute. It could be changing a Status from Open to Closed or from Valid to Invalid or maybe correcting an error during ingest such as a poorly calculated sentiment score. After each change, we update the index upon selection of “Apply Changes”. If you look below, you can see the result in the application reflected immediately: Now, there’s one final piece that hasn’t been mentioned that completely closes the loop. Since an Oracle Endeca Discovery Application is typically not the “system of record”, there’s the possibility that an update sourced from an upstream system could override changes made by users. We’ve accounted for that as well by persisting all changes to a dedicated database store that can be integrated into the update process. For example, if I’ve deleted a record from my application, I can use the “log of deletes” in the database as a data source in any ETL processes that may happen subsequently. Simply filter the incoming data stream using the data stored in the database and you’re good to go. If there are attribute replacements and additions, they work the same way and are tracked and logged appropriately.
If you’re interested in pricing or capabilities or just want to give feedback, drop us a line at product [at] ranzal.com. It’s already been delivered to a customer in Spain last month and we’re looking forward to seeing more and more people in the community get their hands on it.