ESciDoc Content Relations

From MPDLMediaWiki
Revision as of 12:42, 10 November 2008 by Natasab (talk | contribs) (Removing comments)
Jump to navigation Jump to search

Definition[edit]

A content relation in eSciDoc is a resource that relates two other resources. A content relation can relate:

  • Content item with another content item
  • Content container with another content container
  • Content item with a content container


Note: content relations are binary and bi-directional relations i.e.

  • a content relation can be established only by two content objects
  • a content relation a->b also assumes a content relation b->a
  • directions a->b and b->a may have different labels (e.g. isRevisionOf, hasRevisions) that are expressed with a specific relation ontology

What content relations are not[edit]

Content relation should in general not be mixed with structural (isMemberOf, hasMembers) and administrative relations (isContextFor, hasContext) as they are reserved in the present architecture for relations that describe:

  • relations between Items or Containers and a Context
  • relations between Containers and members of Containers
  • relations between parent and child organizational units

Relation types[edit]

  • defines the meaning of how two resources (e.g. items, container) are related. This meaning is expressed with an ontology (such as Fedora relation ontology, eSciDoc relation ontology) and labels for both directions of the relation
  • defines the versioning rules for relation i.e. floating or static relation type
    • floating-versions relation type is valid for all versions of two related resources which were created after the time the relation was created
    • exact-versions relation type is valid only for explicitly related versions of two related resources. Previous and later versions than those related with the relation are not considered as participants in the relation.
  • (optionally) relation type can define which resources can be related (by use of cmodel property) and in which cardinality they can be related e.g.

Examples for content relation types[edit]

  • Annotations (isAnnotationOf, hasAnnotations)
  • Revisions (isRevisionOf, hasRevisions)
  • History (isPredecessorOf, isSuccessorOf)
  • Translation (isTranslationOf, hasTranslation) [ulla]
  • WALS Project:
- hasFeature/hasLanguage (between Language, LanguageFeature); 
  • Format (isFormatOf, hasFormat) [ulla..still not sure on the semantics. what i mean is eg the scenario, that an article is related to a talk at event, where the same content is presented, but in different media/format/mimetype and maybe for different target group]
This requirement is not clear for me, i.e. how to distinguish this from "isRevisionOf". Could we agree to postpone this content relation type? --Inga 22:06, 5 December 2007 (CET)

Example definitions of a relation type[edit]

  • Type (SourceToTarget label): isRevisionOf
  • TargetToSource label: hasRevisions
  • Versioning rule: floating

(Optionally can be defined)

  • Source CModel: PubItem
  • SourceToTarget cardinality: 0..M
  • Target CModel: PubItem
  • TargetToSourceCardinality: 0..M

Relation[edit]

A relation (object) is a resource with following structure:

  • Relation properties (mandatory)
    • relation type
    • date of creation
    • date of last modification
    • user who created the relation
    • status (pending, submitted?, released) (TBD)
    • visibility (public, organizational unit, private) (TBD)
  • Relation metadata (TBD) (optional)
    • relation comment
    • persistent identifier

Note: relation metadata are dependent on the relation type in general

  • Component(TBD) (optional)

Note: not yet clear if one would like to enrich the relation also with a component content. Annotations are such resources

Unlike content items and containers the relation resources are not limited within a context, their virtual "context" is rather the relation type associated and the resources they relate.

Resource handler interface[edit]

Below is a proposal for Resource handler interface of the Content Relations. Not certain if we need to make another interface within the same resource handler that deals with the Relation Ontologies or this should be separate handler. My vote is for simply having a separate interface with same handler and relation Ontologies.

Relation ontology methods[edit]

  • createRelationOntology(relation-ontology.xml*)
    • Description: creates a relation ontology (together with all types of relations)
  • retrieveRelationOntology(relation-ontology-id*)
    • Description: retrieves a relation ontology (together with all types of relations)
  • updateRelationOntology(relation-ontology.xml*)
    • Description: updates a relation ontology (together with all types of relations) (in case when the relation-ontology.xml is released, this should actually mean only allow for creation of new types of relations)
  • deleteRelationOntology(relation-ontology-id*)
    • Description:deletes a relation ontology if not in status "released"
  • releaseRelationOntology(relation-ontology-id*)
    • Description:releases a relation ontology if in status "created" - After a release a relation ontology and its relation types can be used to relate items in the system
  • withdrawRelationOntology(relation-ontology-id*)
    • Description:withdraws a relation ontology if in status "released" - After a withdrawal a relation ontology and its relation types can not be used to relate items in the system (existing relations are however still valid?).
  • retrieveRelationOntologies()
    • Description: retrieves a short list of all relation ontologies available in the system (short list to be defined)
  • retrieveRelationTypes (relation-ontology*)
    • Description: retrieves a list of relation types (and their definition) available for a specified ontology
  • retrieveRelationTypesForModel(cmodel-id*)
    • Description: retrieves a list of relation types (and their definition) available for a specified content model (if any)

Content relation methods[edit]

Note: As this is only a conceptual work, is subject to change until agreed (* for mandatory parameters, ? for optional parameters)

  • create (relation.xml*)
  • retrieve(relation-id*)
  • update(relation-id*, relation.xml*)
  • delete (relation-id*)

To discuss(1)[edit]

Task methods below to be discussed (otherwise, standard task-params)

  • submit(relation-id*)
  • release(relation-id*)
  • withdraw(relation-id*)

To discuss(2)[edit]

  • retrieveRelatedResourceRefs(resource-id*, relation-ontology*, relation-type?, direction<target, both>?)
    • Description: retrieves a list of Id of resources related to specified resource-id and specified relation-ontology, (optionally) specified relation-type and (optionally) specified direction.
      • If a relation-type is not specified retrieves a list of Id of all resources related to specified resource-id within the given relation-ontology (i.e. the resource-id is either target or source of the relation).
      • If direction is specified as "target" it retrieves relations where the resource-id is the source for the relation of (optionally) specified relation-type
      • If direction is specified as "both" it retrieves relations where the resource-id is both the source and target for the relation of (optionally) specified relation-type
      • The output should contain the relation type for each related resource within a relation-ontology and the exact direction

Use cases[edit]