Drupal Content Guidance

Object Name:
This is the name of the class in the model, and should follow the naming rules for elements, capitalized first letter. Object names should be unique.

ProcessingEvent, Concept

Is Abstract:
An abstract class is one which exists only to provide common properties and relationships to a group of related sub-classes, which inherit all properties
and attributes of the parent abstract class. The sub-classes are extensions of the abstract class, but the abstract class itself only ever has existence
through one of its sub-classes.

ControlConstruct is abstract, because it would be manifested as an If Then Else, a Question Construct, a Statement Item, etc.

This field should contain the name of an object which functions as a parent object, from which the extending class will inherit all properties and
relationships. An extending object may modify its parent object by adding properties and relationships, altering cardinalities on inherited properties and
relationships, etc. The children of abstract objects will always extend their parent abstract object, but non-abstract objects may also act as the parent
objects of extending ones.

The IfThenElse object extends the abstract ControlConstruct object

This is the version number of the object, using a two-part version number. The first number designates the “version” of the DDI model, and the second is a
counter for each reviewable iteration of the object definition. Currently, the model version is “0”.

0.1 [The first reviewable iteration of the model for the October 2013 Dagstuhl Sprint]

This field should be a list of all the people who have materially contributed to the definition of the object, so that people continuing the work later
will know who to ask for explanations, etc. when questions arise.

This is a non-circular definition of the object, which may include references to other objects in the model, but should also permit users
to understand how to distinguish such an object in reality. This field is not a description, but a definition, and if taken from another source, the
citation of that source should be provided.

An IfThenElse object describes the conditional logic in the flow of a questionnaire or other data collection instrument, where if a stated condition is
met, one path is followed through the flow, and if the stated condition is met, another path is taken.

This field should contain one or more examples which illustrate what the real-world might be. If possible, a link or citation to the actual objects should
be provided.

An example of the Survey Instrument is the print form administered by the Flinders University of South Australia Centre for Aging Studies, to collect data
for Wave 6 of the Australian Longitudinal Study on Aging – see www.alsa.wavesix.survey.pdf

A list of alternate terms by which the object is typically described, including the citation of the source of such names if relevant. This field is useful
when different terms are commonly used for the same object, and agreement among group members of the formal name is difficult to reach.

For the SurveyInstrument object, a synonym would be “Questionnaire”.

These are the attributes of the object which take a literal value. The property is ascribed several characteristics:

Name: The name of the property. camelCase should be initial lower case

This is a description of the property which allows people to understand the semantic associated with the property. For the property “local ID”, the
description might say “The identifier of the object within a local system, as indicated by the system property of the same object.”

This field should indicate the type of the property, using one of a set of terms taken from a controlled vocabulary based on the allowed representation
types for variables found in DDI Lifecycle: “String” (indicate if structured and/or international), numeric (indicate if Integer, Big Integer, Long, Short,
Decimal, Float, Double, Count, Incremental) , Date, Time, DateTime, Identifier, URN, Entity. Indicate if a value is coded. Ranges are allowed where
applicable (for numerics and dates).

The allowed numbers of this property for an instance of the object, notated as 0..1, 1..1, 1..n, 0..n, etc.

Relationships are directional, and are described as part of the object which is the source (thus, if a Variable references a Question, the
property is described in the description of the Variable object, and not in the description of the Question object.) In a case where the object being
described is an extension of another object, inherited properties do not need to be repeated unless one or more of their characteristics is being changed,
in which case the relationship must be repeated with the altered characteristics stated. Relationships are described using a set of characteristics:

The name of the relationship. For example, a Variable having a relationship with a Population will name the relationship “measures”, where the Variable
object is the source, and the Population object is the target. The name of the relationship should be camelCase, initial lower case

Relationship Type:
The type of the relationship, taken from a standard list, including:

  • Aggregation:
    A relationship in which the target is a component part of the source object, but has an existence independent of the source object
    (i.e. if the parent is deleted, the child still exists). The relationship between a Variable and a Question is an aggregation.
  • Composition:
    A relationship in which the target is a component part of the source object, and whose existence depends on the existence of the
    parent object. The relationship between a Person object and a Passport object is a composition. (i.e. if the parent is deleted, the child is also
  • Simple Association:
    an otherwise described relationship

Target Object:
The name and ID of the object within the DDI model with which acts as the target of the relationship.

The description of the relationship, to be used in the documentation of the model.

Source Cardinality:
The possible number of SOURCE instances with which the TARGET object may have the stated relationship.

Target Cardinality:

The possible number of TARGET instances with which the SOURCE object may have the stated relationship.


A Person may have many “owns” relationships to Passport objects, but a Passport object will have an “owns” relationship with only one Person.

When the Person is the source and the Passport is the target, the source cardinality will be “1..1” and the target cardinality will be “0..n”.
Class: Person
Relation: Name="owns" TargetObject="Passport" Description= "The passports related to this person" SourceCardinality="1..1" TargetCardinality="0..n"

When the Passport is the source and the Person is the target, the source cardinality will be "0..n" and the target cardinality will be "1..1".
Class: Passport
Relation: Name="isOwnedBy" TargetObject="Person" Description= "The person who owns the passport" SourceCardinality="0..n" TargetCardinality="1..1"

RDF Mapping:

NB: This is PROVISIONAL ADVICE This has three columns: Label should be a single word label; Type is the RDF type; URI is the relevant URI for the RDF object