Difference between revisions of "ESciDoc Logical Data Model/SurrogateItem"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 17: Line 17:


==Implementation==
==Implementation==
*SurrogateItem handling implementation is in progress. For more details on concrete implementation see [[Surrogate_Items|Surrogate Items Implementation Concept]]. Respectively, this model is subject to change.
*SurrogateItem handling implementation is in progress. At present, surrogate items can only be created for eSciDoc Content Resources.
*For more details on concrete implementation see [[Surrogate_Items|Surrogate Items Implementation Concept]]. Respectively, this model is subject to change.


==Examples==
==Examples==
Line 62: Line 63:




====TEI Demonstrator====
*referencing external objects, see [[User:Meichau/TEI_Demonstrator|DARIAH TEI Demonstrator]] (still in progress)


 
[[Category:ESciDoc_Logical_Data_Model|SurrogateItem]]
 
[[Category:Faces|Surrogate Item]]
[[Category:ESciDoc]]

Latest revision as of 09:39, 10 November 2011

Introduction[edit]

This page provides general overview on the SurrogateItem resources within the eSciDoc repository. General introduction available at eSciDoc Logical Data Model page.

Model description[edit]

A surrogate item is an Item resource that references another eSciDoc content resource (e.g. another Item or Container) or an external resource (that is resolvable via the identifier used for reference). Referenced resource is thus "origin" of the surrogate item resource.

As being an Item, surrogate item has the same data model as the Item (not represented in the diagram below for simplicity reasons) i.e.

  • at least one MetadataRecord i.e. one or more metadata descriptions of the overall content of the item
  • zero or more Component - the actual (or externally referenced) content and at least one metadata description

Surrogate items are useful mechanism for allowing users to enrich the information around existing resources e.g. for particular purpose of the research, aggregating data from various sources into a container, bridging authorization policies etc. A surrogate item guarantees that the reference to the origin is not lost.

UML Diagram[edit]

SurrogateItemModel.jpg

  • For simplicity reasons properties of the objects are not represented on the diagram. Properties are managed by the escidoc repository itself and may change during time. For more information on the properties and ther usage please check the documentation available at eSciDoc Item Service.

Implementation[edit]

  • SurrogateItem handling implementation is in progress. At present, surrogate items can only be created for eSciDoc Content Resources.
  • For more details on concrete implementation see Surrogate Items Implementation Concept. Respectively, this model is subject to change.

Examples[edit]

Scenarios[edit]

Working with image collections[edit]

Start content

A research institution publishes several collections of images from their research domain. Collections are created as an eSciDoc Container resource, while images are created as eSciDoc Item resources. A collection aggregates a set of images. Both collection and aggregated images are administered within a single Context (Collection Context) .

Scenario

Users may create their own collections (albums) containing subset of these images. They may additionally annotate and enrich these images with information related to their research domain. Further more, they may publish their albums along with the images and relate them to a e.g. publication.

Set-up

As the start content and the collections initially created do have their owners, these can not be modified directly by the users who would like to use the content for their research purpose. Therefore, user-created collections (albums) are administered in a separate Context (Album Context). These users have authorization to view and retrieve the start content (in Collection Context), but they can create own content (own albums) in Album Context only.

Actors

  • Kristina is owner of the start content and she has all privileges to modify and enrich the collections and images from the start content. Kristina is therefore given highest privileges in Collection Context.
  • Bastien is a user who would like to create own collections for the purpose of his research. He has privileges to view and retrieve all collections and images from Collection Context (start content). He has additionally privileges in Album Context to create own albums and add images from the start content as members of those albums.

SurrogateItem use

  • When Bastien creates an album and would like to add some images, he would also like to comment or tag these images for the purpose of his research.
  • When Bastien adds an image from Collection Context as member of his album, the system will create a SurrogateItem resource for that image. This surrogate item resource would contain a reference to the original image item. Bastien is owner of the newly created SurrogateItem and therefore he is able to add some more metadata (e.g. comment, tags).
  • If Bastien would like to remove a member from his albums, the system would only remove the SurrogateItem resource. The original resource is kept and is not modified at all.
  • When adding the item as a member of the album, Bastien may decide to actually reference particular version or always the latest version.


Surrogate-item-concept.PNG


Benefit

  • no mixture of authorization rights
  • publishing of the album would publish the album and the SurrogateItem (i.e. content additionally provided by Bastien)
  • Link to the original is always present
  • If original is eSciDoc resource: Changes made on the original may automatically be visible in the SurrogateItem resource (if user decided to reference always the latest version of the original resource)
  • If original is eSciDoc resource: Changes made on the original will not affect user's work (if user decided to reference the exact version of the original resource)
  • Note: the latter two can certainly not be guaranteed for an external resource. It would simply depends on the underlying system that manages/publishes the external resource.


TEI Demonstrator[edit]