Archived / Obsolete Documentation

Documentation in this space is no longer accurate.
Looking for official DSpace documentation? See all documentation

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.