Use case for metadata concepts

Let's take the groups and membership scenario in Figure 22 as a case study, which involves hierarchy of projects, subprojects, work packages, and tasks represented by ICOM Space. The hierarchical structuring of spaces is just one of many possible structures needed for diverse use cases. ICOM supports arbitrary, flexible structures not only among the spaces but also among containers and a mix of entities.

First we observe that ICOM communities are hierarchical although spaces themselves are not hierarchical. Since each community can contain a set of spaces, spaces can belong in different levels of hierarchy.

In the scenario in Figure 22, the top level is a project, which is divided into subprojects. Each subproject can be divided into work packages, which in turn can be divided into tasks. Each of these project units is supported by an ICOM space containing several folders. Project tasks are assignable to groups. Conceptually, the smallest units of participation in the project units are groups of individuals rather than individuals who may be supplied by multiple organizations. The organizational hierarchies are determined independently of the project unit hierarchies. Each organization can independently assign individuals to the groups that it contributes to the project units.

The scenario illustrates the use of Category to classify spaces and folders by the taxonomy of project units and the use of Bond for hierarchical structuring of spaces and folders to represent the division of projects into subprojects, work packages, and tasks. ICOM TC Groups and Membership Use Case.jpg

Figure 22 - Groups and membership in the hierarchy of project units.

Using Category to Represent the Taxonomy

Figure 23 depicts the categories representing the taxonomy of project units. Figure 24 illustrates the extensibility of ICOM Category to classify the spaces and heterogeneous folders by the concepts from the project taxonomy, such as "Project Unit," "Main Project," "Work Package," and "Project Task" which are not part of the ICOM specification proper. Taxonomy.jpg

Figure 23 - Categories representing the taxonomy of projects. Classification.jpg

Figure 24 - Classification of project spaces and folders by project taxonomy.

Using Bond to Represent the Predicates

UML model of Bond represents n-ary relationships among a set of n entities. Note that Bond has an attribute called "subject" to distinguish one of the n entities and the "objects" attribute to hold n-1 BondEntityRelation objects (see Figure 25).

Figure 25 - Collaboration diagram of Bond representing n-ary relationships.

We use bonds to represent the division of a project unit into subunits. To represent the division of a project unit into subunits, the "subject" attribute of Bond can distinguish the project unit that is being divided, while the n-1 tuple of BondEntityRelation's can represent the subunits of the project unit.

The following examples show how the triples comprising the n-ary relations can be recast by reification statements. In Figure 26, we defined the project hierarchy in RDF using RDF properties "hasSubUnit" to relate the project unit with the subunits. The RDF triples comprising an n-ary relation associate the same subject and property with n-1 objects. For example, the tertiary relation "Project-SubUnit(Project, SP1, SP2)" between a project and two subprojects is represented by two triples <Project hasSubUnit SP1> and <Project hasSubUnit SP2> that associate the subject "Project" and property "hasSubUnit" with the objects SP1 and SP2. Model of Project Spaces.jpg

Figure 26 - RDF model of project hierarchy.

Triples for the tertiary relation "Project-SubUnit(Project, SP1, SP2)" are

These triples can be reified by the following RDF resource "Project-SubUnit":

ICOM can specify a naming convention for assigning a name to the reification resource, for example one possible naming convention is to concatenate the names of the subject "Project" and predicate "hasSubUnit" to get "Project-SubUnit", stripping off "has" and "is" from the predicate.

In Figure 27, the RDF model from Figure 26 is extended with the reification statements. The reification statements "Project-SubUnit" and "SP1-SubUnit" are instances of Bond. In ICOM, Bond is defined as a subclass of Entity. In RDF representation, Bond is defined as a subclass of rdf:Statement as well as a subclass of Entity. Reification Model of Project Spaces.jpg

Figure 27 - Extending the RDF model with reification statements.

UML collaboration diagram in Figure 28 depicts how one bond is used to divide Project into two subprojects (SP1, SP2) and another bond is used to subdivide SP1 into three work packages (WP1, WP2, WP3). Work Packages.jpg

Figure 28 - Collaboration diagram of project hierarchy.

The RDF reification statement can add the annotation, provenance, and attribution information. For example, in the following reification of the "hasSubUnit" property on the "Project" space, the "Project-SubUnit" is a subject that has provenance information "stipulatedBy" and "stipulatedOn" about the "hasSubUnit" property on the "Project" space.

Provenance properties in the RDF reification, besides the rdf:type, rdf:subject, rdf:predicate, and rdf:object properties of the "reification quad," can be represented by an extensible set of properties in the bond object in the UML model. The range of the provenance property can be specified by the type in the PropertyDefinition, however the domain of the properties are implicitly specified by the bond schema, i.e. the type of the bond subject. For example, the "Project-SubUnit" bond can contain two additional properties for "stipulatedBy" and "stipulatedOn." The property definitions for "stipulatedBy" and "stipulatedOn" in the bond schema for "Project-SubUnit" can specify "Project-Plan" for the range of "stipulatedBy" property and Date for the range of "stipulatedOn" property.


MetadataConceptsUseCase (last edited 2010-07-07 13:59:58 by laura.dragan)