Biomedical Engineering Reference
In-Depth Information
•
Dublin Core Terms (dublincore.org/documents/dcmi-terms).
•
Timeline Ontology (purl.org/NET/c4dm/timeline.owl).
•
Foundational Model of Anatomy (sig.biostr.washington.edu/projects/fm).
•
Relation Ontology (www.obofoundry.org/ro).
•
Cardiovascular Research Grid ECG Ontology (www.cvrgrid.org/?q= Ontologies).
•
Sleep Domain Ontology (www.bioontology.org/sleep-ontology).
Concepts from the abstract model have been realised as a set of objects and methods
in an Application Programming Interface (API) and software library. This library
allows signals and their metadata to be created and accessed in a format independent
way and forms the basis of a web-accessible biosignal repository.
BioSignalML repository
Biosignal recordings are usually stored as files on a computer system in whatever for-
mat they were recorded in. Exchanging recordings with colleagues will often involve
file copying and possibly format conversion. The emphasis is usually on obtaining
signal data for processing and analysis without accompanying metadata, this being
kept and exchanged in the form of laboratory notes.
As an alternative to simply working with recordings as computer files, BioSig-
nalML provides a repository application in which metadata is treated as a first-class
component of a biosignal. The repository has been designed as an easy to use, exten-
sible, cross-platform resource that integrates with existing signal processing work-
flows. The repository stores BioSignalML resources -
Recordings
,
Signals
,
Anno-
tations
and
Events
. Each resource has its own URI; a request for a resource returns a
representation of it. This could be actual signal data in some format; an HTML web
page describing the object; or an RDF description of the resource complete with
metadata links to other resources; the particular representation is determined by the
request. The repository provides a HTTP interface and may be accessed using stan-
dard web-browsers.
Signal recordings submitted to the repository are kept in their original format.
Metadata about BioSignalML objects contained in the recording are extracted into
an RDF triplestore. Each recording has a Named Graph (Carroll et al., 2005) holding
its metadata, so that all metadata from the recording can be referenced by a single
resource allowing statements to be made for provenance and access control. Domain-
specific metadata is mapped to ontological terms in a user extensible way, allowing
future refinement as ontologies are developed.
Signal recordings are either exchanged with the repository as files or as a teleme-
try stream. File formats currently supported include EDF/EDF+, WFDB, SDF, an
HDF5 based format, and a proprietary one; adding new formats requires a software
module for conversion into the BioSignalML abstract model along with mapping
statements for domain-specific metadata.
The use of URIs to identify biosignals is fundamental to the repository and its in-
terfaces. In line with Linked Data guidelines (Berners-Lee, 2006), the BioSignalML
repository uses the “http” scheme for URIs, except for local filesystem resources.
Because full “http” URIs can be unwieldy for users, the API and user tools allow
base prefixes to be given and used to construct relative URIs. Temporal segments of
