ESciDoc Content Relations
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
- Why is "isParentOf" a structural relation and "isPredecessorOf" a content relation? The nature of this relations are quite similar to me --Inga 22:06, 5 December 2007 (CET)
- "hasParent" is a relation/predicate that is used in eSciDoc to state the hierarchy of OUs and can not be explicitly set by the solution. Note: That is not true for "isParentOf". Frank 08:38, 6 December 2007 (CET)
- isn't "isParentOf" is the opposite direction of "hasParent"? We need to think of how to make certain that it is not reused for other purposes i.e. for "content relations" --Natasa 18:33, 7 December 2007 (CET)
- I think that is done by defining an ontology (explicit or implicit). The relation "hasParent" has a particular "namespace". If the inverse relation "isParentOf" is valuable/importent it should be defined (in the same namespace) and marked as inverse of "hasParent". Someone else may define a relation "isParentOf" for another purpose in another namespace and we really don't care. For example: The usage of <http://example.de/ontologies/escidoc-content-relations/isParentOf> does not collide with the usage of <http://escidoc.de/ontologies/structural-relations/isParentOf>. Maybe we should be more formal in the usage of "relation-names"; if someone says "has parent" and later "is parent of" i recognize it as different directions of the same thing but that depends on the spoken words. In a formal system the semantic should not depend on words (better: not on the semantic of words as they are used in a natrual language) but on formal definitions. Therefore "isParentOf" is NOT the opposite of the structural relation "hasParent" because it is not defined formally. As i understand, in your proposal such a definition for content-relations may be done by the relation-type-object. Frank 19:12, 7 December 2007 (CET)
- i really don't get, why one would need a relation "isParentOf" - which should be "inverse" of "hasParent", if the "hasParent" relation is already defined. that seems simply redundant. the only additional information is the naming, which may simply be handled by a presentation layer. Robert 20:22, 7 December 2007 (CET)
- As I understand the inverse is primary meant to be able to communicate a relation in the other direction. E.g. in the item xml all relations are listed in which the item is "source". If the inverse of "isRevisionOf" is defined as "hasRevision" and there is a relation <x> <isRevisionOf> <y> it would be possible to list <hasRevision target="x"/> in the xml representation of y. For query purposes the inverse is indeed not necessary. Frank 11:29, 10 December 2007 (CET)
- To avoid more discussions my understanding (and the concept given on relations) is that <http://example.de/ontologies/escidoc-content-relations/isParentOf> is different from <http://example.de/ontologies/external-content-relations/isParentOf>; in addition <http://example.de/ontologies/escidoc-content-relations/isParentOf> as a relation type has the label "isParentOf" and the "inverse direction" label "hasParent" (nice to have for display to the end user - that is what is actually described with Relation type - the query still uses $subject "isParentof" <thisobject> - to get the information from the data). So yes - it is a single relation type for relations which state A is parent of B (and in case when relations are not separate resources)! --Natasa 15:22, 10 December 2007 (CET)
- We need better to understand what actually happens when relations are separate resources and act as objects on their own (which is actually the reason for relation handler proposed in here) :). But maybe then we need to really use some more comprehensive example - let's take for example the use case for create new revision for item. Users starts from Item1 and would like to create a new revision of Item1. That would mean that user creates Item2, creates a relation object (containing the revision comment, and the date when this relation is created). The relation object contains the link to Item1 and the link to Item2. The relation object in this case represents the relation "isRevisionOf-hasRevision" . The relation object is the source for both directions and Item1 and Item2 are targets. Now, if we do not want to loose the semantic of the relation then we need to really name both directions as they are labeled respectively. --Natasa 15:30, 10 December 2007 (CET)
- i really don't get, why one would need a relation "isParentOf" - which should be "inverse" of "hasParent", if the "hasParent" relation is already defined. that seems simply redundant. the only additional information is the naming, which may simply be handled by a presentation layer. Robert 20:22, 7 December 2007 (CET)
- I think that is done by defining an ontology (explicit or implicit). The relation "hasParent" has a particular "namespace". If the inverse relation "isParentOf" is valuable/importent it should be defined (in the same namespace) and marked as inverse of "hasParent". Someone else may define a relation "isParentOf" for another purpose in another namespace and we really don't care. For example: The usage of <http://example.de/ontologies/escidoc-content-relations/isParentOf> does not collide with the usage of <http://escidoc.de/ontologies/structural-relations/isParentOf>. Maybe we should be more formal in the usage of "relation-names"; if someone says "has parent" and later "is parent of" i recognize it as different directions of the same thing but that depends on the spoken words. In a formal system the semantic should not depend on words (better: not on the semantic of words as they are used in a natrual language) but on formal definitions. Therefore "isParentOf" is NOT the opposite of the structural relation "hasParent" because it is not defined formally. As i understand, in your proposal such a definition for content-relations may be done by the relation-type-object. Frank 19:12, 7 December 2007 (CET)
- isn't "isParentOf" is the opposite direction of "hasParent"? We need to think of how to make certain that it is not reused for other purposes i.e. for "content relations" --Natasa 18:33, 7 December 2007 (CET)
- "hasParent" is a relation/predicate that is used in eSciDoc to state the hierarchy of OUs and can not be explicitly set by the solution. Note: That is not true for "isParentOf". Frank 08:38, 6 December 2007 (CET)
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
- 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.
Use cases[edit]
- PubMan: relations with comments isRevisionOf, hasRevision, see Create new revision of an item
- Faces: relations between person models and face images, see Faces content model (in progress)
- VIRR: translations, transcriptions for images, see ViRR Specification (in progress)
- OrganizationalUnit: create relations to express history of organizational units History of OrgUnits examples (SVN access needed)