DFDF Core Ontology

URI: http://dfdf.inesc-id.pt/ont/core

Editors:

Xiaoshu Wang (xiaokdbio.inesc-id.pt)
Jonas S. Almeida (jalmeidamdanderson.org)
Arlindo L. Oliveira (amlinesc-id.pt)

Abstract

This document describes the core language of DFDF , which further refines the meaning of part of DFDF vocabulary. The RDF definition of this ontology can be accessed with the same URI via HTTP content negotiation or using this specific URI. As all other DFDF documents, the notations and special syntax of this document is defined at DFDF Terms.

Table of Content

1. The Conceptualization

1.1. InfoSpace and Transformation

2.1.2. Transformation

1. The Conceptualization

1.1. InfoSpace and Transformation

Data format is a structure that organizes data. In DFDF , the structure is modeled as a df:InfoSpace and data as the items residing in the df:InfoSpace. Df:about, an owl:ObjectProperty ranging over an rdfs:Class, describes the kind, whereas df:size - an owl:DatatypeProperty - describes the number, of items resided in a df:InfoSpace (See Figure 1).

Figure 1 - DFDF Core Ontology

The semantics of df:about should not be mistaken as an "instance of" kind of relationship. A statement with df:about does not suggest that the subjected df:InfoSpace or its contained information items are instances of the described rdfs:Class. It would be wrong, for instance, to conclude from Listing 1 that either _:aPointSpace or the lone item in the _:aPointSpace, is a cce:Point.

#Listing 1 _:aPointSpace a df:InfoSpace; df:size 1; df:about cce:Point.

What df:about describes is a complex relationship between an df:InfoSpace and an rdfs:Class with multiple intermediate concepts involved. As shown in Figure 2, a df:about statement suggests that the information items of a df:InfoSpace describes some domain objects, which type is indicated by the df:about. However, neither the nature of the contained information item nor its relationship to the domain object is modeled in this ontology. The reason for such an omission is for pragmatic purpose. The primary interest of DFDF user is the domain semantics stored in a df:InfoSpace as opposed to the semantics of df:InfoSpace itself. Although the conceptualization of the information item contained by a df:InfoSpace and its relationship to a domain object is helpful during the modeling process, explicitly modeling them in the ontology would unnecessarily increase the complexity of the ontology without any practical gain in return.

Figure 2 The semantics of df:about. What is defined in the ontology is drawn with solid outline. What is implied is drawn in dotted outline and gray text.

Another reason that we should be clear about the meaning of df:about is to avoid being trapped into some philosophical paradox. If, for instance, instead of using the df:about semantics described above, we use an "of" semantics to describe the relationship. We will easily bypass the conceptualization of the information item and suggest that a df:InfoSpace is a structure that holds a direct relationship to the domain objects. Such a conceptualization, on its surface, appears simpler and more straightforward. And, instead of thinking that _:aPointSpace is a df:InfoSpace talking about a cce:Point, we can think it as a df:InfoSpace containing a cce:Point. Such line of thought would lead us to define a Byte as a df:InfoSpace of eight bit, which, at first glance, is very appealing because it would enable us to reason about the df:InfoSpace. But the problem is: when we start to ponder whether a df:InfoSpace of bit is a bit, we are immediately trapped into the Russell's paradox.

A df:InfoSpace, in essence, is an information source[a]. But as a source, a df:InfoSpace by itself is unable to release the withheld information because different agents can extract different information from the same source. Take the df:InfoSpace - _:aPointSpace - described in Listing 1 as an example. Knowing that it is a df:InfoSpace about cce:Point does not, in fact, tells us more about the cce:Point in question. We do not know, for instance, if the information held in _:aPointSpace is about the cce:x-position, or the cce:y-position, or both, of the cce:Point. To extract information form an information source, therefore, requires us to establish a relationship between the df:InfoSpace and some other entity. In DFDF , such a relationship is established by the notion of a df:Transformation. A df:Transformation relates two df:InfoSpaces: one source space and one destination space, respectively described by the df:src and and df:dest. The nature of the established relationship is further described by a df:for property, which ranges over a rdf:Property (See Figure 1).

With this conceptualization, we can extract information from a df:Infospace. For instance, assuming there exists another df:InfoSpace - _:aFloatSpace - that stores the value about a floating point number as defined follows.

_:aFloat a df:InfoSpace; df:size 1; df:about xsd:float.

A df:Transformation, therefore, is able to take the stored number and transform it into the cce:x-position of a cce:Point with the following description.

_:x a df:Transformation; df:dest _:aPointSpace; df:src _:aFloatSpace; df:for cce:x-position.

Please note that the semantics of a df:Transformation is directional vis à vis the rdf:Property described by the df:for. For a given df:Transformation, the rdfs:domain of the rdf:Property described by its df:for, if present, must correspond to the rdfs:Class described by the df:about of its destination space. And similarly, the rdfs:range of the rdf:Property must correspond to the rdfs:Class for the source space. If the direction is misplaced, the semantics would be completely wrong. For instance, if the source and destination space are switched in the above description, it would suggest that an xsd:float have a cce:x-position over a cce:Point. It is helpful to remember that the direction of a df:Transformation (from df:src to df:dest) is always the reverse direction of its df:for property (from domain to range).

1.2. dataSource

Df:dataSource is used to indicate the source of data for a domain object. For instance, if we know that _:aPointSpace stores the information about a particular cce:Point, say _:aPoint, we can then use the following description to establish the link between them.

_:aPoint a cce:Point; df:dataSource _:aPointSpace.

The semantics of df:dataSource, however, is only defined for the one-element df:InfoSpace due to the undefined structure of a df:InfoSpace. For a df:InfoSpace of size 1, the structure of the df:InfoSpace becomes irrelevant because there is no ambiguity as to who is carrying the information for the subjected domain object. But for a df:InfoSpace of multiple items, the structure of the df:InfoSpace is required to establish association between domain objects and information items of the df:InfoSpace. All subclass of df:InfoSpace, however, can define a sub-property of df:dataSource to link one objects to a multi-element df:InfoSpace.

2. Definitions

2.1. Classes

2.1.1. InfoSpace

URI: http://dfdf.inesc-id.pt/voc/df#InfoSpace

Type: owl:Class

Constrains: none

2.1.2. Transformation

URI: http://dfdf.inesc-id.pt/voc/df#Transformation

Type: owl:Class

Constrains:

Must have one df:src property
Must have one df:dest property
Can have at most one df:for property

2.2. Properties

2.2.1. about

URI: http://dfdf.inesc-id.pt/voc/df#about

Type: owl:ObjectProperty

Domain: http://dfdf.inesc-id.pt/voc/df#InfoSpace

Range: rdfs:Class

[a] It would be beyond the scope of this project to define the nature of information. But in here, we can consider it as an entity that is distinct from any of normal domain objects that we will describe with DFDF .