[Dspace-general] Data-centric repository

[MacKenzie Smith]

Hi Hilmar,
> The repository we are aiming to establish is primarily going to be  
> for digital data, not documents (more specifically, data associated  
> with publications). In recollection, most or all of the DSpace-based  
> repositories that were presented were concerned with documents, not  
> data (or so it appeared to me)
>   
I think that's a safe characterization of the bulk of content in DSpace 
repositories today.
> I was wondering to what extent this is a false observation, and  
> whether or not this contains a message. Based on a superficial look  
> at the DSpace data model there seems to be no restriction or bias as  
> to what the digital object may be.
True. MIT is currently taking some datasets, usually of the simpler 
variety (e.g. statistical
datasets like https://dspace.mit.edu/handle/1721.1/18175 ) and we don't 
promise to
always render them on the web... sometimes we just hand the user the 
file and let them
work with it locally (in the example above, the dataset only works in a 
particular desktop
statistical package, so it's not web-native no matter how nice the UI is).
> I learned from one of you that in  
> the DSpace data model I have no way to represent hierarchical and  
> typed relationships between the individual bitstreams that constitute  
> the parts of a 'dataset', which I found a very helpful comment.
>   
The DSpace data model is at a higher level than this (i.e. it covers the 
organization's structure
into communities and collections rather than the item's structure per 
se). If the "item" qua
"dataset" has multiple bitstreams, as does, for example, a complex web 
site, then they way
we recommend handling that in DSpace is to have the item contain
-- all the content files
-- another file with the structural metadata for the data, whether that 
be METS, IMS CP, MPEG-21 DIDL,
or pick-your-favorite-complex-object-model

The most common scenario is then to write a custom UI that will get the 
structural metadata file
and work its magic to create the end user interface to the data. The 
reason this is so vague is
that every type of data requires a different UI to help users interact 
with that data. The notion
that one repository could 'do it all' seems like hubris to me... the 
default (DSpace) UI would just
index the metadata for the dataset and list one or more content files, 
or a link to the custom UI.

We do something like that for the archive of OpenCourseWare websites in 
DSpace at MIT
(e.g. https://dspace.mit.edu/handle/1721.1/34949) although this isn't a 
dataset of course.
> Thanks in advance for any comments, links, or other pointers, and BTW  
> if anyone has comments or suggestions on our digital data repository  
> project as outlined above, please don't hesitate to send those my way  
> too, I'll forward them to the project team.
>   
Hope this helps,

MacKenzie

-- 
MacKenzie Smith
MIT Libraries