mto:TransferElement: Tracker Ontology Reference Manual

## mto:TransferElement mto:TransferElement |

## Description

Gives information about the transfer of a single element - typically a file. The properties in this class would need to be changed if it has to handle sync elements as well

This class emits notifications about changes, and can be tracked through the `GraphUpdated` DBus signal.

## Class hierarchy

        rdfs:Resource
        ╰── nie:InformationElement
            ╰── mto:TransferElement

## Properties

### The `“mto:state”` property

    “mto:state”          mto:State

Captures the current state of the transfer element: Pending (not started), In Progress, Paused, Cancelled, Done

Number of possible elements per resource (Cardinality): 1

### The `“mto:completedTime”` property

    “mto:completedTime”          xsd:dateTime

Captures the date and time when the transfer ended. It must be set only when the trasfer element is completed succesfully

Number of possible elements per resource (Cardinality): 1

### The `“mto:startedTime”` property

    “mto:startedTime”          xsd:dateTime

Captures the date and time when the transfer was started

Number of possible elements per resource (Cardinality): 1

### The `“mto:destination”` property

    “mto:destination”          rdfs:Resource

The destination of the transfer. If the transfer is an download, it would be the URI for a file on the device. If the transfer is a (web) upload, it will be a URL, which will be filled once the upload is completed.

Number of possible elements per resource (Cardinality): 1

### The `“mto:source”` property

    “mto:source”          rdfs:Resource

The source for the transfer. If the transfer is an upload, it would be the URI for a file on the device. If the transfer is a (web) download, it will be a URL. Question: Does it make more sense to have two fields: uploadSource and downloadSource?

Number of possible elements per resource (Cardinality): 1

## See also

The upstream documentation for the MTO ontology.