ESciDoc Content Relations Concept
Concept: Content Relation Linking and Tagging with eSciDoc
Requirements (see also ESciDoc_Content_Relations)[edit]
It should be possible to link between two resources, whereas the link has to carry meta data. Furthermore is a tagging mechanism required to add meta data and/or comments to an existing resource. It is important that this functionality is not restricted to the owner/modifier rule of the related resources (with exception of the relation resource itself). Relation could be set to whole resources, specific versions as well as from version number X.
Functional Overview[edit]
Linking and tagging within eSciDoc Core could be provided by Content Relations. An eSciDoc Content Relation is a resource that created a relation to one related resource (Item, Container, Context, etc.) or between two or more resources. The relation to or between resources is/are expressed through source and target elements. Multiple resources can be linked or tagged with one Content Relation Resource. If multiple resources are linked/tagged than contains the Content Relation resource multiple entries of source and target elements. The type of resource is not restricted. A tag consists only in one direction to resources, in contrast to links where at least two resources related to each other.
- include figure 1: Linking
- include figure 2: Tagging
The Content Relation resource will have a Content Model reference. The Content Model is currently not finally specified, therefore some now described details could change in the finalization process. Which and how many of resources could be referenced by one resource is configurable through the Content Model. The Content Model contains the reference to an ontology, where structure and restrictions are expressed. Additionally restrictions, which may not expressible through an ontology could placed within the Content Model resource. One Content Model could, for example, restrict the Content Relation to exact one Item as source and one Container as target. Content Relations (links and tags) are named. The name is a predicate and derived from the selected ontology. The used content model or the solution/user dictates which ontology is to use for one Content Relation. Multiple ontologies be used, stored and extend with/though the infrastructure, but each Content Model use only one ontology.
A Content Relation is directed, whereas the name of the relation should inspire the meaning of the direction. A Content Relation could, for example, be named as isSomethingOf. Name qualifies the direction from left side (source) to the right (target). An automatically inverse relation will not be given. This restriction does not exclude effective search requests ala “Which resource points to Resource Y with following relationName …?”.
Content Relations are not part of the resource(s) which it is linked on, it is to discover by a separate request. Furthermore are it not related to any Context and can therefore set resources over context borders in relation.
Versions and Relation Types[edit]
Content Relations are aware of versions of source and target. This means that a link or tag could be set to a certain version. This means not that older versions of a modified Content Relation could be retrieved. The Content Relation resource is non-versioned. According the requirements extends Content Relation the both -well known- framework internal references (fixed and floating). References could be set for one certain and all following versions, or from and until certain versions of the resources.
A fixed relation is a reference to or from a certain version number of the resource. E.g. A relation between the version 3 of an Item X and the version 1 of the Item Y, whereas both sides of the relation are fixed references.
A floating relation is a reference which has the whole resource (with all versions) as source and/or target. The resource(s) can be developed further and the relation still reference to the newest version. E.g. A relation between version 2 of Item X and the resource Item Y. The reference to Item Y is a floating reference. Version 3 of the Item X is continuously reference the newest version of Item Y, even if Item Y is updated in the meantime.
A hybrid type of fixed and floating could be used to define a number version from where the relation is valid. This means that a relation could be defined between version number 2 of an Item and is valid for all further versions but not for version 1. It is also possible to define a range of version between the relation is valid.
Searching for Content Relations[edit]
Content Relations are not part of the tagged or linked resource. That’s why it is not to expect to find all relations to a resource via search. Depending on search index could Content Relations itself be found with the search.
Searching for Content Relations will be handled through a filter interface of the Content Relations handler. This search index is synchronal with the resource status and base on TripleStore. Solutions/users are not provided with a direct access to the TripleStore.The handler provides method to retrieve list with selected parameters to filter and returns lists with resource references.
A Content Relation has same states and public-status workflow as Item or Container. Public-status rules has to be the same than by Item and Container.
Meta data sets are handled different to Item and Container. Content Relation will not have a meta data section as required. Md-records are complete optional. If a md-record with the name of the default md-records is set, than tries the core an automatically mapping to DC.
Content Relation Resource XML Representation[edit]
Three major sections structure the Content Relation resource. Section one contains the resource properties, which describes –like in all other resources- the resource itself. Values of this section are: creator, modifier, creation-date, content-model, … The second section contains the relations to resources with optional elements for version restrictions. The third section contains descriptions about the relation of the specified resources. This includes beside the type of the Content Relation a general description element and an optional set of meta data.