Date: Thu, 28 Mar 2024 14:38:36 -0400 (EDT) Message-ID: <143514857.28646.1711651116749@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_28645_69784424.1711651116749" ------=_Part_28645_69784424.1711651116749 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
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 th=
e Architectural Review here:
ArchReviewDataModel
I take this further and suggest that the "Domain aspect" of this mod= el (I.E. Communities/Collections/Items/Manifestations...) should be an abst= raction modeled within the data and note expressed as a Concrete set of Jav= a 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 servi= ce. For example: an Assetstore will store the Content representation of a D= SpaceObject, 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 Se= ptember 2008 (EDT)