On May 2, 2011, at 11:30 AM, Mark H. Wood wrote:

> [tangent alert!]
> I'd like to hear why we have the "owning collection" concept at all.
> We would need a convenient way to find unlinked Items and operate on
> them (link, delete, edit).
> 
> -- 
> Mark H. Wood, Lead System Programmer   [email protected]
> Asking whether markets are efficient is like asking whether people are smart.

Not only that, is the behavior the same regardless of ordering if  I removed 
the item from one collection and added it to another in one Context commit?  I 
actually do not think so and that doesn't sound good.

Context c = new Context();

Collection c1 = Collection.find(123);
Collection c2 = Collection.find(124);
Item i = Item.find(125);

// CASE 1
c1.removeItem(i);
c2.addItem(i);

// vs.

// CASE 2
c2.addItem(i);
c1.removeItem(i);

// ....

c1.update();
c2.update();

c. commit();

Will I still have an item in the first case?

TBH, from this dialog, having a Collection be a requirement for an Item really 
has few benefits other than forcing items to be in collections so they don't 
get orphaned...

So there are a few benefits from a business service standpoint (per Richard 
Rodgers Comments).  But, the shackling of the item to have at least one 
collection seems to look somewhat restrictive if we want DSpace to be more 
flexible and customizable, We shouldn't "need" an item to have a collection,  
as it forces us to be bound to strictly Collection centric services.  At the 
moment, the only reason, is to assure those business services (workflow and 
admin) that are bound to the collection don't break when an Item doesn't have 
one...

We are rapidly approaching a need to be able to move items somewhere thats "not 
a collection", for instance, we are working on Versioning Items, and to get 
them out of the Search and Browse (but still allowing them to be viewed)  we 
are removing them from the collection and attaching them into a VersionHistory 
"container".  

In this regard, a Collection is just "state", DSpace should be "Item" centric, 
As Fedora is "FedoraObject" centric, a Collection is just a state the Item is 
in. A state that informs the application of the UI about the services that 
should be allowed to execute on the item by the current user. Fedora doesn't 
attempt to remove all the objects that are members of a container object when 
the container object is removed.  It the responsibility of the application to 
maintain that consistency. 

Finally,  as we advance the configurable submission (and type based 
submission), we should be looking at liberating those workflows from having to 
be bound to the collection and actually have it be the other way around, where 
Workflow is the first class model and collections are just a "view" on a set of 
items.

Mark

-- 
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Technologielaan 9 - 3001 Heverlee - Belgium


------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to