Mark, I have understanding you opinion but I'm not really sure that the owning collection is a relationship in the actual model or that we need a similar relationship in future development. At the moment we need owning collection only for keep simple some presentation (display style, bread crumbs) & authorization choice, looking forward I think that all collections where the item is mapped really own the item, the item mapper feature should check not only for ADD permission on the target collection but also for ADMIN permission on the item self. Presentation issue should be resolved in their domain: bread crumbs should show the path used by the user for get the item, display should be based only on the item metadata & so. I propose to rename OwningCollection in SubmittedCollection to keep live this info (as for submitter) also after that the inProgressSubmission became an Archived Item. With this approach SubmittedCollection has to be considerate an item attribute and not a relationship... (the SubmittedCollection could be also not an own of the item after some time) Andrea
Mark Diggory ha scritto: > On Nov 20, 2007, at 3:55 AM, Andrea Bollini wrote: > > >> Larry Stone ha scritto: >> >>>> Collection * - * Item >>>> >>>> >>> It's worth noting that while an Item may be a member of multiple >>> Collections, it still refers to only one of them as its "owner"; >>> it is >>> returned by getOwningCollection(). >>> >> true but IMHO this is not really needed... >> > > Well, what I've suggested in my previous email is not wether it is > needed or not, but where it should correctly reside in relational > terms, "owner" is a relationship, not an attribute of Item and > Collection, thus the more appropriate location would be in the > container or relationship tables. I.E. > > rather than: > > >> ------------------------------------------------------- >> -- Item table >> ------------------------------------------------------- >> CREATE TABLE Item >> ( >> item_id INTEGER PRIMARY KEY, >> submitter_id INTEGER REFERENCES EPerson(eperson_id), >> in_archive BOOL, >> withdrawn BOOL, >> last_modified TIMESTAMP WITH TIME ZONE, >> owning_collection INTEGER >> ); >> > > >> ------------------------------------------------------- >> -- Collection2Item table >> ------------------------------------------------------- >> CREATE TABLE Collection2Item >> ( >> id INTEGER PRIMARY KEY, >> collection_id INTEGER REFERENCES Collection(collection_id), >> item_id INTEGER REFERENCES Item(item_id), >> ); >> > > instead have > > >> ------------------------------------------------------- >> -- Item table >> ------------------------------------------------------- >> CREATE TABLE Item >> ( >> item_id INTEGER PRIMARY KEY, >> submitter_id INTEGER REFERENCES EPerson(eperson_id), >> in_archive BOOL, >> withdrawn BOOL, >> last_modified TIMESTAMP WITH TIME ZONE >> ); >> > > > >> ------------------------------------------------------- >> -- Collection2Item table >> ------------------------------------------------------- >> CREATE TABLE Collection2Item >> ( >> id INTEGER PRIMARY KEY, >> collection_id INTEGER REFERENCES Collection(collection_id), >> item_id INTEGER REFERENCES Item(item_id), >> owning_collection BOOL >> ); >> > > Ownership is a relationship and not a attribute and the dependency is > one way. This also is an example that enforces third normal form > because you cannot have a owning collection for which the item is not > a member. (Although you can have multiple owners). > > > >>> When an Item is accessed directly, >>> by itself without the navigational context of one of the >>> Collections it belongs to, it consults the owning Collection for >>> display style >>> >> this is only one possibility and it is not the most useful (see >> MedataStyleSelection in 1.5) >> > > Very true and we will see that Manakin will mix this up even more. > > >>> and policies (e.g. access control by Collection admins). >>> >>> >> the auth system need a lot of work, in my path "community admin" that >> introduce some hierarchy control I have used the owning collection as >> the only real parent i.e. if I want modify the item but I have not >> direct permission I check for ADMIN right on owning collection... >> this is not optimal, if we have an item mapped in an other >> collection I >> think that only directly authorized people or ADMIN of both collection >> should manage it >> For Daniele works I recommend to keep ownCollection in place but I >> think >> that we need to remove it in future version. >> >> PS:the concept of owning collection is used also in workflow and >> submission system but there is a main difference: the data are >> stored in >> inProgressSubmission object not in the item object. Also in this >> case I >> hope that we can introduce a more modular way to select workflow >> process >> and submission process then simply use the "owning collection". >> Andrea >> > > Andrea, that is another example of what I speak of above. At least in > this case, we see that inProgressSubmission (or WorkspaceItem) is > really a "container" like collection and we've attached the item to > that rather than attaching it to the item. I just think this is much > cleaner and actually does not require altering the item table to move > an item between WorkspaceItem and WorkflowItem when it is moved from > Submission to Management Workflows. > > I would support moving/or removing owning_collection if it improved > the model and the ability to work with tools. I think we would want > a path of deprecation however, and using the above "relationship" > approach could more easily give us that. > -Mark > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > > -- Dott. Andrea Bollini Responsabile tecnico sviluppo e formazione applicativi JAVA Sezione Servizi per le Biblioteche e l'Editoria Elettronica CILEA, http://www.cilea.it tel. +39 06-59292831 cel. +39 348-8277525 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
