I see what you are going for here, but there are really only 2 things in play for many events (hence the reason there are 2 major aspects in the event system: name (action), resource (subject)) "site user login" is really just user and login since there is only one site for example Every event captures the user (or anon) so anything associated with users has only 2 parts remaining The last bit is that in DSpace 2, I can add an item without putting it in a collection (or by putting in 3 collections) so we are not limited. I think we could add in an optional field to hold the "parent thing" for the cases where it makes sense. But forcing this to be set for all events seems problematic. -AZ
On Fri, Jul 17, 2009 at 3:43 AM, Mark Diggory<mdigg...@atmire.com> wrote: > Developers, > > I'm looking at the 2.0 Event model in comparison to the 1.x Event > model and I am seeing some discrepancies that I think need addressing: > > DSpace 1.x events provide a triple of event object, event action and > event subject so that, for instance, the following can be recorded > easily: > > dspace:collection/1234.5/1 Action.REMOVE dspace:item/1234.5/2 > > See: > https://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/event/Event.java > > And this is stored within the Event because later in the event > processing the detail that the item was part of the collection has > already been lost. Its also almost always the case that the events in > dspace have this nature of activities that are recordable as triples. > > site add community > community add collection > collection add item > item add resourcepolicy > group add user > user update name > item update field > collection update field > user login site > user view item > > I think it is very important we retain this in 2.0 but I do not see > this in the 2.0 event api at the moment. > > See: > https://scm.dspace.org/svn/repo/dspace2/core/trunk/api/src/main/java/org/dspace/services/model/Event.java > > I propose we make sure to get the DSpace 2.0 Event to explicitly > capture the same state in the same model so that we can retain the > explicit detail we need throughout DSpace 2.0 to properly record > events in their context. I do notice that properties can be attached > to the event, but I consider this an very important aspect of an event > that is always required and should be expressed within the API. > > thoughts? > Mark > > -- > Mark R. Diggory > @mire - http://www.atmire.com > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Dspace-architecture mailing list > dspace-architect...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-architecture > -- Aaron Zeckoski (azeckoski (at) vt.edu) Senior Research Engineer - CARET - University of Cambridge https://twitter.com/azeckoski - http://www.linkedin.com/in/azeckoski http://aaronz-sakai.blogspot.com/ - http://tinyurl.com/azprofile ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
