The Mobile Computing in a Fieldwork Environment (MCFE) project
addresses issues in the application of mobile and context-aware computing
to fieldwork training and research in higher education. We are developing
applications to support data collection, resource creation and access to previously
recorded information using hand-held computers in the field. In contrast to some other
projects that seek to bring the fieldwork indoors by the development of 'virtual
reality field courses', our approach is to take the data outside and so to provide
'enhanced reality field courses'.
The main components of the project are:
- MCFE Field Notes
- Mobile context-aware applications for hand-held computers
- Field note management tools for desktop computers
These are a development of Peter Brown's Stick-e notes. Notes carry an
embedded description of the physical or logical context in which they should be
activated. Current implementations concentrate on text notes but the concept can be
extended to cover any passive or active object. Whereas Stick-e notes are
defined by an special-purpose SGML DTD, MCFE Field Notes are prepared in HTML format.
Each note is represented as a single HTML document.
Context-aware applications monitor input from environmental sensors and allow users
to select from a range of physical and logical contexts corresponding to their current
interests or activities. Perhaps the most generally applicable physical sensor is the
computer's own internal clock. This is widely used to provide a simple form of
context-awareness in 'personal scheduler' programs.
Most basic MCFE applications use input from a GPS receiver to provide location and
accurate time data. For other, more specialised, activities we might employ sensors
to monitor air temperature, humidity or incident light level. Logical contexts might
include broad or narrow subject categories such as 'archaeology' or 'earthwork', a
required temporal coverage such as 'medieval' or '1914-1918', or the name of a person
or group responsible for creating a set of data.
Information derived both from the sensors and from user input is used to tag newly
authored notes. This information is held in HTML <META> tags in each note, and
is then available for applications to use as selection criteria for retrieving stored
notes.
The desktop management tools will include a central repository for collections of field
notes, together with authoring and editing tools. Sets of notes covering a range
of activities will then be downloaded from the PC to the hand-held machine as required,
and collected data can be uploaded to the desktop on return from the field. Data import
and export facilities will be required so that data can be exchanged with databases, GIS
and other analytical tools.
Using HTML rather than a special purpose SGML DTD to encode MCFE Field Notes has
a number of benefits. Firstly, many members of the target user community have some
degree of familiarity with HTML, whereas they might be reluctant to learn a DTD.
Familiarity with the encoding language may lead to more rapid acceptance of the
Field Notes and interest their further development. Secondly, the availability
of HTML browsers and editors, and users' familiarity with them, reduces the need
to develop special purpose software for many of the basic note authoring and
management tasks.
The HTML <META>
tag has a rather restricted syntax, but nevertheless, can be used to embed contextual
metadata in documents. Following the initial decision to use HTML, it seemed that we
would have to define a special syntax for embedding notes in the NAME and
CONTENT fields of the META tag. However, it soon became apparent that
there was a close similarity between the needs of context-aware applications and the
task of resource discovery. This led to an examination of existing and emerging metadata
standards aimed at resource discovery. Most existing standards are either too
detailed or too specialised for our purposes, but the emerging Dublin Core standard
appears to offer both simplicity and sufficiently general coverage for many context
aware applications.
The Dublin Core consists of fifteen
core metadata elements,
intended primarily for high-level resource discovery.
The simple fifteen element structure clearly cannot satisfy all metadata requirements.
The Warwick Framework proposals provide a method of extending the
Dublin core to include special-purpose metadata 'packages'. Using this approach,
the basic Dublin Core elements are grouped into a single high-level package and
further packages are added to contain the specialised metadata.
Initially, it appeared that a Warwick Framework package would be needed to deal
with the particular requirements of MCFE Field Note metadata. In practice, most
of the project's needs can be satisfied using the basic Dublin Core element set.
Indeed, with the exception of the spatial and temporal coverage elements, MCFE
metadata is a restricted subset of the current Dublin Core.
The Dublin Core is still evolving. The semantics of some elements are still only
loosely defined, and the syntax of the HTML representation has yet to be finalised.
Rather than facing the need for multiple revisions of the format of the MCFE
metadata during the lifetime of the project, a simple package specification
based on the fifteen element Dublin Core has been developed. This approach should:
- provide a reasonable degree of stability
- ensure a relatively smooth transition to 'pure' Dublin Core at a later date
- avoid confusion by not claiming to be 'real' Dublin Core metadata.
The sixteen MCFE metadata elements are shown in the following table.
| Element name | Element Description |
| Identifier |
Unique identifier of the note |
| Title |
The title or name of the note |
| Subject |
One or more keywords describing the content of the note |
| Description |
Free text description of the note |
| Creator |
The person(s) who created the note |
| Contributor |
Other person(s), such as editors and translators, who have made a
significant intellectual contribution to the note |
| Publisher |
The agent or agency responsible for making the note available |
| Date |
Date of creation or modification |
| Type |
The type of the note, normally "MCFE field note" |
| Format |
The data representation of the note, normally "text/html" |
| Source |
|
| Language |
Language of the intellectual content |
| Relation |
Relationship to other resource |
| Spatial |
The spatial coverage of the note |
| Temporal |
The temporal coverage of the note |
| Rights |
Access rights governing the note |
The Spatial and Temporal elements are
particularly important in defining the context of a field note. They are often more
complex than the other elements, having many different types and subtypes.
We have therefore decided to treat them as separate elements, rather than following
the Dublin Core approach of using a single
Coverage element.
If it becomes necessary to include other contextual information from environmental
sensors (e.g. temperature or humidity), new elements will be added following the pattern
of Spatial and Temporal.
- The Identifier element is required in all MCFE Field Notes.
- No other elements are mandatory but, to be of use to a context aware application,
at least one of the following would normally be expected:
- The Creator, Contributor
and Publisher elements may be used
where the identity of the author of a note or of others involved in its production
and dissemination is likely to be of interest. For example, it may be necessary to
distinguish the notes created by different authors, or published by different
organisations.
- Source might be used in a similar way to
discriminate between notes whose contents are derived form alternative sources.
- Date is particularly useful for applications where data
may have been collected during several repeat visits to a site.
- Language can be used to distinguish between alternative
versions of notes written in different languages.
- Relation may be used to maintain track of the
inter-relationships within a collection of notes that are grouped together for
a common purpose, e.g. a 'guided tour'.
- The main use of the Title and Description
elements is expected to be in note indexing and management applications.
- Rights may be used by a context-aware system to determine
whether the current user is permitted to access the information, or whether a charge
is levied for access.
- Type and Format are largely redundant
for context awareness and can be ignored by most applications. They are only relevant
where notes were stored amongst a collection of other, more general, HTML documents.
However, future develops may include notes encoded using alternative
MIME types.
Each MCFE Field Note is formatted as a single HTML 'page' with the metadata embedded
in <META> tags in the
<HEAD>...</HEAD>
section of the page. The typical syntax of a metadata element is as follows:
<META NAME = "MCFE.element[.qualifier]"
CONTENT = "[(scheme=scheme_name)]element_value">
Within each field note, all MCFE metadata elements appear as a 'package' enclosed
within a single pair of package.begin and package.end entries:
<META NAME = "package.begin" CONTENT = "MCFE Version 0.1">
<!--# MCFE elements in here -->
<!--# The order of elements within a package is free -->
<META NAME = "package.end" CONTENT = "MCFE Version 0.1">
Each MCFE package should also contain a
<LINK...>
tag referencing the URL of this page:
<LINK REL="schema.MCFE"
HREF="http://www.cs.ukc.ac.uk/research/infosys/mobicomp/meta/mcfemeta.html">
Individual element definitions may be located by appending #element_name to this URL.
Some MCFE elements permit the use of other schemes. If any are used, additional
LINK elements must be added to reference the appropriate scheme definition.
<meta name="package.begin" content="MCFE Version 0.1">
<meta name="MCFE.identifier" content="MCFE134530908">
<meta name="MCFE.title" content="An MCFE stick-e note">
<meta name="MCFE.creator.name" content="Nick Ryan">
<meta name="MCFE.date.creation" content="1997-04-07 01:41:00">
<meta name="MCFE.type" content="MCFE stick-e note">
<meta name="MCFE.format" content="text/html">
<meta name="MCFE.spatial.point.3D" content="(scheme=OSGB) TR 13562 58591 47m">
<link rel="schema.MCFE" href="http://www.cs.ukc.ac.uk/research/infosys/mobicomp/meta/mcfemeta.html">
<meta name="package.end" content="MCFE Version 0.1">
The following sections describe each of the MCFE elements in detail. Similarities
with and differences from the current understanding of the Dublin Core elements are
also discussed.
Element Name: Identifier
Usage: MCFE.identifier identifier
Example: <META name="MCFE.identifier" CONTENT="MCFE1234567890">
Notes:
- A unique identifier for the object.
- All MCFE applications are required to generate a unique string for each note
(typically beginning "MCFE...").
- The DC.identifier element may be given as the "address" of the file containing the
object (e.g. a URL or URN), or it may contain an ISBN, ISSN or other identifier.
See also: DC.identifier,
Table of Contents
Element Name: Title
Usage: MCFE.title resource_title
Example: <META NAME="MCFE.title" CONTENT="MCFE Metadata Elements">
Notes:
- The main title of the document.
- Although DC.Title may be repeated to provide different forms of the title (main,
subtitle, alternate, etc.), MCFE field notes should provide at most one (main) title.
- If this element is absent, the title must be supplied between
<TITLE>...</TITLE> tags in the HTML header.
See also: DC.Title,
Table of Contents
Element Name: Subject
Usage: MCFE.subject [scheme] subject_keywords
Example: <META NAME="MCFE.subject" CONTENT="(SCHEME=RCHME) excavation">
Notes:
- A comma-separated list of keywords describing the resource.
- MCFE.subject is used in the same way as DC.subject, except that the absence of a
specified scheme indicates use of the default MCFE keyword list.
- Subject is a repeatable element. Normally, only one subject element should be used and
this should contain all necessary keywords. However, where more than one SCHEME is
required, multiple subject elements must be used.
- Keywords within a subject element must be drawn from only one SCHEME, and any
SCHEME other than the default should be referenced by including an appropriate
<LINK...> element in the metadata package.
See also:DC.subject,
Table of Contents
Element Name: Description
Usage: MCFE.description text
Example: <META NAME="MCFE.description" CONTENT="An informal definition of the MCFE metadata elements">
Notes:
- A free text description or abstract of the resource.
See also:DC.description,
Table of Contents
Element Name: Creator
Usage: MCFE.creator[.n][.type] creator
Example 1: <META NAME="MCFE.creator" CONTENT="Nick Ryan">
Example 2: <META NAME="MCFE.creator.e-mail" CONTENT="N.S.Ryan@ukc.ac.uk">
Example 3: <META NAME="MCFE.creator.2" CONTENT="Jason Pascoe">
Notes:
- The creator or author of the resource.
- MCFE.creator may be repeated as necessary to list all the creators or
authors, or to provide extra information such as their e-mail addresses.
- Where multiple creators are cited, they should be ordered/distinguished by using the
".n" qualifier pattern as in example 3.
Valid type qualifiers include:
- name (default)
- e-mail
- agency (i.e. the work has no named creator, but is published by an agency)
- postal
- phone
- ...
See also: DC.creator,
Table of Contents
Element Name: Contributor
Usage: MCFE.contributor[.n][.type[.subtype]] contributor
Example: <META NAME="MCFE.contributor.funder" CONTENT="JISC">
Notes:
- Other contributors to the production of the note
- Uses include describing editors, illustrators, those who transcribed non-digital
records, etc.
- MCFE.contributor is a repeatable field, and may be used as many times
as necessary to describe all relevant contributors to the current resource.
- Where multiple creators are cited, they should be ordered/distinguished by using the
".n" qualifier pattern as in the MCFE.creator element.
- Additional information such as e-mail or postal addresses may be added by using
the subtype qualifier.
- In the absence of a subtype, the content is assumed to be the name of the
contributor.
Valid type qualifiers are:
- Editor
- Illustrator
- Sponsor
- Principal
- Compiler
- Funder
- Composer
- Cataloger
- Translator
Valid subtype qualifiers include:
- name (default)
- e-mail
- postal
- phone
- ...
See also: DC.contributor,
Table of Contents
Element Name: Publisher
Usage: MCFE.publisher[.type] publisher
Example: <META NAME="MCFE.publisher" CONTENT="MCFE Project, UKC">
Notes:
- The person or organisation responsible for publishing the note.
- Additional information such as e-mail or postal addresses may be added by using
the type qualifier as in the MCFE.creator element.
- In the absence of a type, the content is assumed to be the name of the
publisher.
Valid type qualifiers include:
- name (default)
- e-mail
- postal
- phone
- ...
See also: DC.Publisher
Element Name: Date
Usage: MCFE.date.type date | datetime
Example: <META name="MCFE.date.creation" CONTENT="1997-04-22 18:32">
Notes:
- MCFE.date refers to the history of the note.
- The temporal applicability or relevance of the note's content is given in
the temporal coverage element.
- MCFE.date must be qualified by either "creation" or "modified", and
the content should always be expressed in the following format:
- yyyy[-mm[-dd]]
- yyyy-mm-dd hh:mm[:ss[.sss]]
See also: DC.date,
Table of Contents
Element Name: Type
Usage: MCFE.type resource_type
Example: <META name="MCFE.type" CONTENT="MCFE field note">
Notes:
- The category of the resource.
- At present this is always "MCFE field note", but other categories may be created
in the course of the project. For this reason, and to aid migration of notes to
DC metadata form, thetype element should always be present.
See also: DC.type,
Table of Contents
Element Name: Format
Usage: MCFE.format form
Example: <META name="MCFE.format" CONTENT="text/html">
Notes:
- The delivery format of the resource.
- Typically, a DC format refers to an
Internet Media Type (IMT),
but MCFE notes are always generated in HTML form, so the format will always be
"text/html".
- This element is optional, but it is recommended that it is included for consistency
and ease of migration of notes to DC metadata form.
See also: DC.format,
Table of Contents
Element Name: Relation
Usage: MCFE.relation.type related_object
Example: <META NAME="MCFE.relation.childof" CONTENT="(identifier)MCFE1234567889">
Notes:
- A repeatable field, used to define the relationship between
the current resource and other closely related resources.
Valid type qualifiers include:
- parent.of
- child.of
- sibling.of
- contained.in
- supersedes
- continues
- continued.from
- superseded.by
- cites
- extracted.from
- is.part.of
- contains
- is.index.of
- glossary.of
- predecessor
- successor
- is.derivative.of
See also: DC.Relation,
Table of Contents
Element Name: Source
Usage: MCFE.source[.type] source
Example: <META NAME="MCFE.source.ISBN" CONTENT="1-85032-115-9">
Notes:
- A repeatable field used to point to the original source of the note content.
- Multiple instances of MCFE.source may be used where an online record amalgamates
several originals.
Valid {type}s include;
See also: DC.Source,
Table of Contents
Element Name: Language
Usage: MCFE.language [scheme] language
Example: <META NAME="MCFE.language" CONTENT="en">
Notes:
- Defines the language in which the resource is presented.
- In the absence of an alternative SCHEME the language should be indicated by
an ISO 639 code.
See also: DC.Language,
Table of Contents
Element Name: Spatial
Usage: MCFE.spatial.type[.subtype] [scheme] spatial_coverage
Examples:
<META NAME="MCFE.spatial.point
CONTENT="(SCHEME=OSGB)TR 13558 58585">
<META NAME="MCFE.spatial.point
CONTENT="(SCHEME=OSGB)613558 158585">
<META NAME="MCFE.spatial.point.3D
CONTENT="(SCHEME=UTM)31U 512558 4125850 480">
<META NAME="MCFE.spatial.line
CONTENT="(SCHEME=OSGB)TR 13558 58585, TR 13610 59930">
<META NAME="MCFE.spatial.bbox
CONTENT="(SCHEME=OSGB)TR 13558 58585 TR, 13610 58662">
<META NAME="MCFE.spatial.facing CONTENT="NW">
<META NAME="MCFE.spatial.datum CONTENT="OSGB-1936">
Notes:
- The spatial coverage of the note.
- A repeatable field. The total spatial coverage is given by the
union of all of MCFE.spatial records.
- The types, subtypes, schemes and formats suggested here are
experimental and subject to change.
Valid types are:
- point - a single point
- line - a polyline expressed as a comma-separated list of two or
more point coordinates.
- polygon - a polyline specifying the boundary of a closed shape.
If the first and last points are not equal, they are assumed to be
joined by an additional line segment.
- circle - expressed as the centre point coordinates followed by
the radius in metres.
- bbox - a bounding box aligned on the current grid (see
scheme). Expressed as the coordinates of the lower-left and
upper-right corner points
- facing - a direction expressed either as a string, such as "NW"
or "ESE", or as a bearing in integer degrees.
- datum - a record defining the geodetic datum (ellipsoid and
transformation parameters) that applies to all spatial
coordinates in the current metadata package.
Point, line, polygon and bbox types may be further qualified by the
subtype "3d", indicating three-dimensional coordinates. A 3d coordinate
is represented by a 2d coordinate, followed by altitude in metres (see
spatial schemes below for details of coordinate formats).
Question: should we allow circle.3d? If so, do we assume
the plane of the circle is horizontal, or do we require an extra parameter
.
The datum type content is a name as found in the Datum list.
This list contains ellipsoid and datum transformation parameters.
Valid schemes for point, line, polygon, circle and bbox types are:
- UTM - Universal Transverse Mercator coordinates expressed as zone east north
where zone is a string containing the zone number, optionally followed by
the band letter, e.g. "31U 515200 4255299".
- OSGB - Ordnance Survey of Great Britain's National Grid coordinates. Expressed as either:
- gg east north where gg is the 100Km square letters and east north
are numeric coordinates within this square, or
- east north using the full numeric coordinates representing
the offset from the false origin of the National Grid.
- LLD - Latitude and Longitude expressed as decimal degrees: ddd.dddd
- LLDM - Latitude and Longitude expressed as degrees and decimal minutes: ddd:mm.mmm
- LLDMS - Latitude and Longitude expressed as degrees, minutes and seconds: ddd:mm:ss[.sss]
- ECEF - Earth-centred, earth-fixed Cartesian coordinates x,y,z.
Schemes other than the default should be referenced by including an appropriate
<LINK...> element in the metadata package.
Geodetic datum content:
- UTM coordinates in Europe often refer to the European-1979
datum. This is the assumed default value in the absence of a spatial.datum record.
- The default datum for Latitude and Longitude is WGS-84.
An alternative datum may be specified using a spatial.datum record.
- OSGB coordinates always refer to the OSGB-1936 datum, so a
separate spatial.datum record is not required.
Note that although spatial coverage will often be derived from a GPS receiver, there
is as yet no defined mechanism for representing raw measurement data for later use in
post-processing, or for recording the accuracy of these or other locations. Further
thought is needed to decide whether it is appropriate to store this information as
metadata and, if so, how it should be represented.
See also: DC.Coverage,
Table of Contents, MCFE.temporal,
Datum list.
Element Name: Temporal
Usage: MCFE.temporal[.type[.subtype] [scheme] temporal_coverage
Examples:
<META NAME="MCFE.temporal.date" CONTENT="1792">
<META NAME="MCFE.temporal.date"
CONTENT="1997-04-22 14:35:05.550">
<META NAME="MCFE.temporal.date" CONTENT="C4q3">
<META NAME="MCFE.temporal.period"
CONTENT="1792-03-12 ~ 1997-04-22 14:35:00">
<META NAME="MCFE.temporal.period"
CONTENT="C18 ~ 1997-04-22 14:35:00">
<META NAME="MCFE.temporal.period.name"
CONTENT="(SCHEME=xxx)Carolingian">
Notes: MCFE.temporal is a repeatable field. The temporal coverage of the note
content is given by the union of all of its MCFE.temporal records. The types, subtypes,
schemes and formats suggested here are experimental and subject to change.
Acceptable type qualifiers are:
- date - the content applies to the given date.
- period - the content applies at all times between the given dates.
- period.name - the content applies to the named temporal period. Period names will
be derived from a thesaurus specified by the scheme. Thesauri should contain
period name, start and end calendar dates.
Acceptable content formats for date and period types are:
- Date: [-]yyyy[-mm[-dd]]
- Timestamp: yyyy-mm-dd hh:mm[:ss[.sss]]
- Century date: Cnn[BC][q1 | q2 | q3 | q4 | h1 | h2 | e[arly] | m[id] | l[ate]]
Periods are expressed as their start and end points separated by a '~' (tilde).
Start and end may be a date, timestamp or century date, and need not be of the same
format or granularity. Incompletely bounded periods, before or after
a single date, are represented by omitting the start or end date: 'before 1500' is
expressed as "~1500", after 1900 as "1900~".
Note that these formats support variable granularity time, but do not allow for
uncertainty or expressions of confidence. For example, the date "1997" has a granularity
of one year and implies a single event located somewhere during the specified year.
This event occupies a single chronon, a duration of time that is less than or
equal in length to the the granularity of the date. Events that have a known start and
end should be expressed as a period, e.g. "1997-01-01~1997-12-31".
Valid schemes for date and period types containing timestamp values are:
- UTC - Universal Coordinated Time (default, assumed if scheme is absent).
- GMT[+|-n] - Greenwich Mean Time, optionally with timezone offset.
- GPS - timestamp derived from Global Positioning System. Arguably, this could be
expressed as wwww:d:hh:mm:ss[.ssss], where www is the GPS week number.
Valid Schemes for date and period types containing date values are used to
define the calendar:
- Gregorian - default, assumed if scheme is absent.
- Julian - must be present for Julian calendar dates.
Valid schemes for period.name types include:
- MCFE - default, assumed if scheme is absent.
- to be defined
Schemes other than the default should be referenced by including an appropriate
<LINK...> element in the metadata package.
See also: DC.Coverage,
Table of Contents, MCFE.spatial,
period name list.
Element Name: Rights
Usage: MCFE.rights rights
Example: <META NAME="MCFE.rights" CONTENT="restricted">
Notes:
- Details of access rights to the material contained in the note.
- May be used by a context-aware system to determine whether the current user
is permitted to access the information, or whether a charge is levied for access.
- As with the current DC.rights element, the absence of this element does not
imply that their are no restrictions on access.
See also: DC.Rights,
Table of Contents
Nick Ryan
Computing Laboratory, University of Kent at Canterbury, UK
N.S.Ryan@ukc.ac.uk
