This Confluence wiki site, maintained by DuraSpace prior to the recent merger with LYRASIS, will transition from the duraspace.org domain to the lyrasis.org domain on Saturday, Nov 16 beginning at approximately 7pm ET. A period of downtime of 2-3 hours is expected. After the transition, this wiki will be available at https://wiki.lyrasis.org/. All links to duraspace.org wiki pages will be redirected to the correct lyrasis.org URL. If you have questions prior to or following the transition please contact: wikihelp@lyrasis.org.

Page tree
Skip to end of metadata
Go to start of metadata

Technical Specification for DSpace+2.0 Data Model API.

This page should contain a technical drafting of the requirements around the DSpace Data Model drawn from the comparative analysis done in... DSpace+2.0-Comparing_Existing_Technologies

We agree that an anemic data model is most appropriate. That is, a data model that is an API almost entirely devoid of implementation at its base. Initially some concepts concering the look of this API were expressed in the Architectural Review here:
ArchReviewDataModel

I take this further and suggest that the "Domain aspect" of this model (I.E. Communities/Collections/Items/Manifestations...) should be an abstraction modeled within the data and note expressed as a Concrete set of Java Classes. This means that a DSpaceObject is just a URI used to reference a resources that may be stored in various different states within each service. For example: an Assetstore will store the Content representation of a DSpaceObject, while the MetadataService will store a Metadata representation of the object. This means that Service can evolve seperate "non-dominant" data models that are more tailored to interacting with them. --Mark Diggory 15:49, 16 September 2008 (EDT)

  • No labels