In this paper, we describe a mapping language for converting data contained in arbitrary spreadsheets into the Web Ontology Language (OWL). The developed language overcomes shortcomings with existing spreadsheet mapping techniques, including their restriction to well-formed spreadsheets reminiscent of a single relational database table and verbose syntax for expressing mapping rules when transforming spreadsheet contents into OWL. We additionally present an implementation of the mapping approach, Mapping Master, which is available as a plug-in for the Protégé ontology editor.
However, existing mapping approaches suffer from a variety of limitations. First,
many mapping techniques assume very simple data models within spreadsheets [
Class: sales1 SubClassOf: SalesAmount and forDrug some Zyvox and forDate has 2008 and amount has “1,115” (Ex. 2) To encode the OWL class axioms in Ex. 1 & 2 in RDF, 10s of triples are required because the RDF serializations for owl:intersectionOf, owl:hasValue and owl:someValuesFrom require multiple triples. Therefore, using state-of-the-art mapping techniques, even simple mapping rules can be extremely verbose. To overcome these limitations, we propose a new declarative OWL-centric mapping language that supports arbitrary spreadsheet-to-OWL mappings. The language also supports syntactic transformations of cell contents, as well as inline OWL axioms involving classes, properties and individuals extracted from cell contents. In the end, the mapping language enables mapping information from arbitrary spreadsheets to OWL using a compact, user-friendly syntax. 1 Source: Pfizer 2008 Financial Report: http://media.pfizer.com/files/annualreport/2008/financial/financial2008.pdf 2 A philosophical discussion regarding whether this information should be modeled as classes or individuals is out of the scope of this paper. However, a class-based representation is consistent with modeling conventions used in widely accepted biomedical ontologies.
A variety of systems have been developed to map spreadsheet content to RDF. The
earliest systems include Excel2RDF [
As discussed previously, the primary goal is to address the limitations of existing mapping tools by developing a new declarative OWL-centric mapping language. Importantly, this domain-specific language (DSL) should support complex and arbitrary spreadsheets that do not conform to the entity-per-row assumption. To ensure the mapping approach is compatible with the workflow familiar to users of spreadsheet tools, the language must also allow mappings of data spread over multiple sheets. A related requirement is that is should support mapping of data that may be distributed non-uniformly in individual sheets (for example, multiple disconnected tables in a sheet representing the same underlying information). Additionally, it should allow the selective extraction of data from within cells.
Full coverage of all OWL constructs is also a primary goal of the mapping language. In addition to supporting the definition of simple OWL entities such as named classes, properties, and individuals, class expressions and potentially complex necessary and sufficient declarations should be expressible. While an RDF triple-based mapping mechanism can in principle generate arbitrary OWL constructs, such an approach is not practical in general because of OWL’s complex RDF serialization. This approach would also not be compatible with the goal of producing a concise language. Additionally, the language should not only be concise but also simple to learn for users familiar with both OWL and spreadsheet tools. An additional usability difficulty when developing custom languages is providing debugging support. The typical levels of complexity when mapping from spreadsheets to OWL make this support particularly crucial. An important language design goal is thus to support instantaneous preview of mapping results before they are executed and to allow those previews to be updated dynamically when underlying data are changed.
Rather than design a DSL from scratch, the proposed language is built upon the
Manchester Syntax [
M2 extends the Manchester Syntax to allow references to spreadsheet content in
expressions. It introduces a new reference clause to support these references. This
clause can indicate one or more cells in spreadsheet. In this DSL, any clause in a
Manchester Syntax expression that indicates an OWL class, OWL property, OWL
individual, data type, or data value can be substituted with this reference clause.
References clauses are prefixed with the character ‘@’ and are followed by an
Excelstyle cell reference. In the standard Excel cell notation, cells extend from A1 in the
top left corner of a sheet within a spreadsheet to successively higher columns and
rows, with alpha characters referring to columns and numerical values referring to
rows. For example, a reference to cell A5 in a spreadsheet is written as follows:
The above cell specification indicates that the reference is relative, meaning that if a
formula containing the reference is moved then the row and column components of
3 A full description of the language can be found on the MappingMaster wiki [
This reference clause can then be used in M2 expressions to define OWL constructs using spreadsheet content. For example, an M2 expression to take the name in cell A5 of the spreadsheet in Figure 1 and declare an OWL named class that is a subclass of an existing Drug class can be written: This expression declares an OWL class named by the contents of cell A5 (‘Zyvox’ in this case) and asserts that it is a subclass of class Drug. If the class has previously been declared and it is not already a subclass of Drug then that relationship will be asserted. Using this approach, any OWL axiom can be declared using the appropriate Manchester Syntax clause, with references used in these clauses to specify spreadsheet content. For example, an M2 expression to instead declare an individual of type Drug using the contents cell A5 as its name can be written: Ambiguities may arise regarding the type of the entity being referenced. In the above drug class declaration example, it is clear that @A5 refers to an OWL class. However, the type can not always be inferred. Explicit entity type specifications are provided to deal with this case. To support this specification, a reference may be optionally followed by a parenthesis-enclosed entity type specification to explicitly declare the type of referenced entity. This specification can indicate that the entity is an OWL named class, an OWL object or data property, or an OWL individual or a data type. The M2 keywords to specify the types are: Class, ObjectProperty, DataProperty, Individual, and any XSD type name (e.g., xsd:int). Using this specification, the above drug declaration, for example, can be written: In many cases, specifying the super class, super property, individual class membership, or the data type of referenced entities is also desired. While these types of relationships can be defined using standard Manchester Syntax expressions, this approach will often entail the use of multiple mapping expressions. To concisely support defining these types of relationships, a reference may optionally be followed by a parenthesis-enclosed list of type names. Using this approach, the above drug declaration, for example, can be written as follows: These type specifications can themselves be cell references and can be nested to arbitrary depths, though excessive use of nesting may make expressions difficult to understand and debug. Super properties, individual class membership, and data types can be specified in the same way.
A variety of name encoding strategies are supported when creating entities from spreadsheet content. The primary strategies are to either use direct URI-based names (equivalent to using rdf:about or rdf:ID clauses in an RDF serialization of OWL) or to use rdfs:label annotation values. The default naming encoding uses the rdfs:label annotation property. The default may also be changed globally (discussed in Section 5). Using rdfs:label encoding, the OWL entity generated from a cell referenced is given an automatically generated (and non meaningful) URI and its rdfs:label annotation value is set to the content of the cell.
A name encoding clause is provided to explicitly specify a desired encoding. As with entity type specifications, this clause is contained in parenthesis after the cell reference. The M2 keywords to specify the three types of encoding are rdf:about, rdf:ID, and rdfs:label. Using this clause, a specification of rdf:ID encoding for the previous drug example can be written: The default M2 behavior is to directly use the contents of the referenced cell when encoding a name. However, this default can be overridden using an optional value specification clause. This clause is indicated by the ‘=’ character immediately after the encoding specification keyword and is followed by a parenthesis-enclosed, comma-separated list of value specifications, which are appended to each other. These value specifications can be cell references or values. For example, an expression that extends the earlier reference to specify that the entity created from cell A5 is to use rdfs:label name encoding and that the name is to be the value of the cell preceded by the string “Sale:” can be written as follows: Value specification references are not restricted to the referenced cell itself and may indicate arbitrary cells. More than one encoding can also be specified for a particular reference so, for example, names and annotation values can be generated for a particular entity using the contents of different cells.
A similar approach can be used to selectively extract values from referenced cells. A regular expression capture group clause is provided and can be used in any position in a value specification clause. This clause is contained in a quoted string enclosed by square parenthesis. For example, if cell A5 in the previous example contained the string “Pfizer:Zyvox” but only the text following the ‘:’ character is to be used in the label encoding, an appropriate capture expression could be written as:
Class: @A5(Drug rdfs:label=(“Sale:”, [“:([a-zA-Z][a-zA-Z0-9]*)”])) Note that parentheses around the sub-expressions in a regular expression clause specify capture groups and indicate that the matched strings are to be extracted. In some cases, more than one capture group may be matched for a cell value, in which case they are extracted in the order that they are matched and appended to each other. To deal with missing cell values, default values can also be specified in references. A default value clause is provided to assign these values. This clause is indicated by the keyword mm:default and is separated from a value specification clause by a comma. It is followed by a parenthesis-enclosed, comma-separated list of value specifications. For example, the following expression uses this clause to indicate that the value “Unknown” should be used as the created class label if cell A5 is empty:
Class: @A5(rdfs:label, mm:default=(“Unknown”) Drug) Each value specification clause can be followed by a default, so different default values can be used for rdf:ID and rdfs:label encodings. This clause can also be used for data values and may itself contain M2 references.
Finally, a filter clause may be used to indicate that cells that do not meet particular criteria should be ignored. This clause is indicated by the keyword mm:filter and, like value and type specifications, is enclosed in parenthesis after a cell specification. This keyword is followed by the ‘=’ character and a quoted condition, which is specified using Excel-style Boolean condition notation. Using this clause, a variant of the previous expression that skips cells with the value ‘Zyvox’ can be written:
Class: @A5(mm:filter=“A5<>Zyvox” Drug) Excel-style conditions are very expressive and allow almost arbitrary filter criteria.
The M2 mapping process takes a source spreadsheet, a set of M2 expressions, and a target ontology. The mappings are processed in three phases. In first phase, every expression is preprocessed and the relevant content specified by references in these expressions is retrieved from the source spreadsheet. This content, which will either specify a data value or the name of a data type or an OWL entity, is substituted for each reference in an M2 expression to generate a valid Manchester Syntax expression. The second phase declares all referenced OWL entities that are not already declared in the target ontology. The type specification for each reference is used to generate the appropriate declaration clause. Any super class, super property, individual class membership, or data type specifications in the reference are also declared in this phase. Once the entities have been declared, the third phase involves sending the final Manchester Syntax expression to a Manchester Syntax processor. This processor will populate the target ontology with the OWL axioms specified by the expressions. At the end of phase one, the generated expressions can be checked for syntactic correctness. They can also be previewed at this stage if desired, allowing users to see the final entity names expanded within their enclosing M2 expression. M2 supports several preprocessing directives to specify configuration options for the mapping process. These directives include the ability to declare both a default namespace for generated entities and to specify prefix-to-namespace mappings. The latter option allows M2 to deal with cells that contain both prefixed and fully qualified URI entity names. An option is also supported to indicate that cell values refer to OWL entities using annotation values. In the default case, these names—be they prefixed, fully qualified, or annotated—are assumed to either refer to existing OWL entities or to name entities that are to be declared during the import process. M2 supports a pair of options to modify this behavior. The first option can be set to indicate that an error should be thrown if a name refers to an existing entity in the target ontology; the second option indicates that an error should be thrown if the name foes not refer to an existing entity. A related option deals with the possible ambiguity introduced by the use of annotation value references. It can be set to produce an error if more than one existing OWL entity could be named by the value.
A final set of options is designed for dealing with missing values. Three behaviors can be specified: (1) throw an error if any referenced cell contains a missing value; (2) skip the affected mapping expression for a missing-value cell and continue to other cells; and (3) attempt to generate an expression by conservatively dropping only the sub-expressions that reference the missing-value cell.
M2 provides an option specification clause for each option type. The general form of this option specification clause is a keyword followed by a value. For example, the default name encoding for all mappings can be written:
mm:DefaultNameEncoding = rdfs:label It is noted that OWL axioms generated during the mapping process may cause inconsistencies in the target ontology. Further, since users have full control over M2 expression authoring, the expressions can also generate axioms that are inconsistent with each other. To immediately detect such inconsistencies, an ideal implementation would invoke an incremental reasoner after each expression is executed. 4
A parser, editor, and execution engine for the M2 DSL have been written. The parser
currently supports core Manchester Syntax OWL entity declarations plus arbitrary
class expressions, though full coverage is anticipated soon. Additionally, a
development environment has been released as an open source plugin to the
ProtégéOWL editor [
This research was supported in part by STTR Award #0750543 from the National Science Foundation. We would also like to thank Peter Moore and Natasha Noy.