Hi all,
I'm writing to underline some differences between the data model shown in the
dspace site
(
http://www.dspace.org/index.php?option=com_content&task=view&id=149#data_model
) and the actual code present in the /trunk (
http://dspace-sandbox.googlecode.com/svn/mirror/dspace/trunk/ ).
Th
There are some acknowledged discrepancies between the data model, the
API, and the capabilities afforded by the UI. I'm not well placed to
discuss the decisions made in the early development of DSpace, but I
think the idea was to allow for many-to-many relationships in the model,
while being more r
The mismatch is very old...
I think that the API is the most right source of info, I assume that
all of us are happy with many-to-many associations for communities (also
with themselves), collections & items. I'm not sure if we want keep a
many-to-many for item-bundle-bitstream. In my opinion these
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...
> When an Item is a
> 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(). When an Item is accessed directly,
by itself without the navigational context of one of the
Collections
I throw up a flag of caution. I think there are concerns with
unpredictable behavior of authorization/policies when such a behavior
is allowed (many to many) and we see that in the the database schema
where we have added a column to "Item" pertaining to its "owning
collection". We should
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().
>
This is really getting out of scope for dspace-tech, but I'd just like
to make a plea to look at the data model in the abstract rather than
at the implementation level: the way it appears in database tables *doesn't*
*matter* at this stage of thinking about it, and I think it muddies the waters
eve
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)
On Nov 21, 2007, at 2:44 AM, Larry Stone wrote:
> This is really getting out of scope for dspace-tech,
But its important to discuss direction transparently, so I do not
consider it out of scope.
> but I'd just like
> to make a plea to look at the data model in the abstract rather than
> at th
10 matches
Mail list logo
