Contextualized Attention Metadata (CAM)

CAM allows to monitor user interactions with learning environments. The Contextualized Attention Metadata (CAM) schema allows modelling a user's handling of digital content across system boundaries. As CAM was developed to describe as many types of attention metadata as possible, CAM records of a user cannot merely describe the user's foci of attention but rather his entire computer usage behaviour. CAM can be analysed to provide an overview about where (i.e. with which application) and when an action takes place and what happens in the environment. CAM analyses enable the discovery of popularity, usage bursts and trends of tools. It can also uncover patterns like applications becoming unpopular, rising stars and new applications taking over older applications. Information about when an action takes place can be useful in controlled environments such as formal learning environments where activities are usually scheduled. It is also quite useful in less controlled or more blended environments,
to understand when learners are actually active.

Source Code

Some source code for the collection of CAM within widget environments (coming from the ROLE project) is available on sourceforge:

General Information:

The Entrypoint to a CAM Instance is the Event element. The Event element describes one user action.
  • An Event can have several EventEntities which represent the related "stakeholders" (Persons and/or Items). Each Event must have at furleast one EventEntity which represents the User who is performing the action.
    Further an Event can (not required) have Context Information like information about the Location (physical), the Environment (virtual), tasks which are related to this Event or Entities which are no directly connected with the Event. An Example for this is writing a Message in a Forum. The Writer and the Message are EventEntities but the Thread and the Forum are ContextEntities
  • Additionally an Event links to a Session Element which comprises information about the IP Address or sessionId.

Latest Version: (CAM Core extraction)

What has changed:
  • removed Metadata from CAM Schema
  • changed "entity" attributes
    • removed attribute type
    • renamed reference to entityId
    • added attributes metadataId and metadataReference
  • CAM focusses on usage information (CAM Core), not on information about the resources
    • Split metadata from CAM Core definition
  • removed type because of practical redundancy with role & mimetype
  • metadataId & metadataReference to refer to external table the resource is stored in

 RDB Mapping:
  • removed metadata and entity-metadata table

4) CAM Schema: changed Event - Session relation

What has changed:
  • changed N:1 relation of Event-Session to N:M relation
  • We experienced the case, that sometimes more sessions could be relevant
  • e.g. Starting a Linux Shell (shell-session) and in this shell starting the debugger (debug-session). Each debug step is a CAM Event connected to the shell-session and the debug-session

 RDB Mapping:
  • additional EventSession table to manage the N:M relation
  • removed sessionfk attribute from Event

Vocabulary / Valuespaces of attributes
Please note that, due to the simple schema, a lot of knowledge has moved to the role attributes. These need to be defined, with a starting point being values {sender, receiver, context, writer, message, forum, thread}.

Rules and Constraints
Also, the simple schema requires rules to be enforced on the instances that go beyond simple cardinality restrictions. Minimum, the cardinality depends on the type of the value of role. For example, if the role attribute is "receiver", there needs to be exaclty one related entity with the role attribute "sender". If the role attribute is "context", there needs to be exactly one related entity with the role attribute "sender". If rhe role attribute is "forum", there needs to be exactly one related entity with the role attribute "writer" and at least one with the value "message". (True, these rules have to be made more clear, but for understanding, they should be fine...)

Some further reading on modelling roles: 
An article outlining the various possible ways of modelling roles, by Francis G. Mossé: http://www.objectdiscovery.com/solutions/publications/roles/index.html  A Conceptual Modelling Pattern for Roles Ruth Raventós and Jordi Cabot

3) Further reduced CAM Schema

 What has changed:
  • Moved Elements
    • ContextEntities are now represented as normal entities having the respective role (e.g. context, environment, location, ...)
    • Since the Context element after this change only comprised the Session element we removed the Context for sake of simplicity and directly connected the Session information with the Event
  • Added Attributes
    • We put a SharingLevel attrbute to the Event to control data access rights, e.g. public --> everybody is allowed to see this EamInstance
  • simplify the schema
  • reduce complexity for queries
  • remove meaningless Context Element

 RDB Mapping
  • Event
    analogue to ER Diagram
    • Session
      analogue to ER Diagram
    • eventrelatedentity
    • to map the m:n relation between Event - Relatedentity
      • Relatedentity
        comprises all general attributes
        • RelatedentityMetadata
          more detailed information
          metadata: the original metadata
          metadataBinding: e.g. XML
          metadataHash: HashValue of the original Metadata for performant identification and duplicate-detection
          metadataType: e.g. LOM or DublinCore


2) CAM Schema as proposed in the Meeting (2010-11-16)

What has changed:
  • Moved Elements:
    • Environment is now seen as a ContextEntity
    • Task is now seen as a ContextEntity
    • Location is now seen as a ContextEntity
  • Deleted Attributes
    • the role attribute of the ContextEntity relation has been removed
Why we did the changes:
  • Location was too strict defined.
  • Task and Environment were quite similar to the Entity Definition.
  • The Role for a ContextEntity made no sense

1) CAM Schema first draft:

The Event represents the central entry point and is the most granular element. An Event is defined by:
  • name: the type/name of the event, e.g. send - for sending a message (required)
  • datetime: when the event happened (required)
  • contextid: a reference to a Context (not required)
  • EventEntities: An Event can be connected with several Entities that represent the participants of this event, like the Person performing the efent or all directly related Items. The connected Entity can be further specified with a Role, e.g. by monitoring the event "User1 sends a Message to User2" we have two connected users, User1 has the role sender, User2 has the role receiver
The Context element comprises all further information which are related with the event. A Context is defined by:
  • name: to give the Context a name... (not required)
  • description: to give the Context a description... (not required)
  • Environment: complex type (not required)
    The Environment describes the domain (the virtual location) where the event took place, e.g. a PortalSite like MACE
    • description:
    • name:
    • reference: URL of the domain.
  • Location: complex type (not required)
    Describes the physical location where the event took place, e.g. Fraunhofer Institute
    • description:
    • name:
    • reference:
    • longitude:
    • latitude:
  • Session: complex type (not required)
    Further information about the session where the event took place
    • domain:
    • ipAddress:
    • sessionId:
  • Tasks: complex type (not required)
    Describes the tasks which are connected with the event
    • description:
    • name:
  • ContextEntities: complex type - Entity (not required).
    A ContextEntity describes all Objects which are not directly connected to the Event. For Example the Forum and the Thread Information when a user writes a new Message inside a Forum.

An Entity represents persons, documents, applications, devices and further stakeholders. Entities can be part of an Event or a Context. For each Event: An Entity which is directly connected to the Event (so we call it an EventEntity) can not be connected with the Context (then we would call it ContextEntity) at the same time. But an Entity which is an EventEntity in Event_1 can be a ContextEntity in Event_2.
An Entity has the following Attributes:

  • mimetype:
  • name:
  • reference: The reference represents a unique identifier of the Entity. If we have something like a GUID we use this as the referencge (e.g. in MACE we would use the MACE internal IDs) otherwise we use the Url/Path of the Entity.
  • type:
  • EntityMetadata: Each Entity can be represented in different Metadata Formats like LOM or DublinCore. So an Entity contains a list of EntityMetadata, one EntityMetadata per representration.
    • metadata: The original Metadata like the original LOM. If we have no MetadataRepresentation (e.g. for a chat message) we could store the messagetext in this field by using the MetadataBinding "Plain/Text"
    • metadataBinding: LOM, DublinCore, FOAF, ...
    • metadataHash: HashValue of the original metadata for faster comparison if the MetadataEntry is already existing.
    • metadataType: XML, PLAIN, JSON, ...