KnowledgeStore Core Data Model ontology 0.2

Namespace Document 09 Jan 2014

Document URL:

http://dkm.fbk.eu/ontologies/knowledgestore.html (HTML, PDF)

Vocabulary URL:

http://dkm.fbk.eu/ontologies/knowledgestore.owl (RDF/XML, TURTLE, Manchester Syntax)

Authors:

Marco Rospocher, Luciano Serafini (FBK-Irst)
Francesco Corcoglioniti

Copyright © 2014 FBK-Irst

Abstract

Status of This Document

Table of Contents

• Overview
• Core concepts
• Extending the model
• Data representation using Named Graphs
• Terms reference

Overview

The following UML class diagram informally presents an overview of the ontology. Classes are rendered as UML classes, datatype properties as attributes and object properties as UML relations; minimum and maximum cardinalities and expected datatypes are also shown. The components of the ontology are detailed in the following sections.

The vocabulary namespace is http://dkm.fbk.eu/ontologies/knowledgestore. The suggested prefix for referencing the vocabulary is ks:.

A list of classes and properties is reported below, with links to their reference documentation:

Core concepts

The KnowledgeStore Core Data Model ontology is organized in the three resource, mention and entity representation layers.

The resource layer (red part in the UML diagram) stores unstructured content in the form of information objects called resources. A Resource is a self-contained piece of unstructured content, such as a news article or a multimedia object, having some descriptive metadata (e.g., from the Dublin Core Terms vocabulary and a digital Representation (attribute storedAs). Representations encode the actual bytes realizing a resource, and are associated to a builtin set of metadata that comprise the file name (attribute nfo:fileName), the size in bytes (attribute nfo:fileSize), the date and time the representation was created (attribute nfo:fileCreated) and the MIME type (attribute nie:mimeType). Information stored in the resource layer is typically noisy, ambiguous, and redundant, with the same piece of information potentially represented in different ways in multiple resources.

The entity layer (blue part in the UML diagram) is the home of structured content, and consists in formal entities' descriptions made with contextualized axioms. An Entity is anything identifiable with a URI, such as persons, organizations, locations and events. Entities are described (property describedBy, inverse describes) by Axioms. An axiom is a logical formula (e.g., that "Barack Obama is president of USA") that is encoded (property encodedBy) with one or more <subject, predicate, object> RDF triples and that possibly holds in (attribute holdsIn) a specific Context (e.g., the time period 2009-2016); axioms may be annotated with additional metadata (e.g., to encode their provenance), while contexts are specified by a number of properties called contextual dimensions (they are defined in extensions of this ontology). Both axioms and contexts are identified with URIs automatically assigned by the system based on the RDF statements and context of the former and the contextual attributes of the latter. The entity layer builds on Knowledge Representation and Semantic Web best practices and, differently from the resource layer, it aims at providing a formal and concise representation of the world, abstracting from the many ways it can be encoded in natural language or in multimedia, and thus allowing the use of automated reasoning to derive new statements from asserted ones.

Between the aforementioned two layers is the mention layer (green part in the UML diagram), consisting of mention descriptions. A Mention is a snippet of a resource (property mentionOf, inverse hasMention), such as some characters in a text document or some pixels in an image, that may refer to some entity of interest (property refersTo, inverse referredBy) and/or can express a number of axioms (property expresses, inverse expressedBy). Mentions can be automatically extracted by natural language and multimedia processing tools, that can enrich them with additional attributes about how they denote their referent (e.g., name, qualifiers, 'sentiment'). Therefore, mentions present both unstructured and structured facets not available in resources and entities layers alone, and are thus a valuable source of information on their own.

Extending the model

Being embodied in the implementation, the KnowledgeStore Core Data Model ontology is kept as small as possible in order not to sacrifice flexibility. Therefore, relevant information such as resource types and metadata, contextual dimensions, mention types and linguistic attributes are not defined in this ontology, due to the fact that a stable, exhaustive and cross-domain characterization of them cannot be drawn. Instead, this information is supplied in an extension ontology (such as the NewsReader one) that is specific to a KnowledgeStore deployment and extend the ontology here specified.

• The subclass hierarchy of Resource and Mention (entities excluded as described via axioms); subclasses are not assumed to be disjoint.
• The additional attributes of Resource, Mention, Axiom, Context and their subclasses. Context attributes define the contextual dimensions for a particular scenario and are used by the system to generate the context URI. In case of objects belonging to multiple subclasses, their description can make use of all their combined attributes.
• Additional relations among resources or among mentions (but not between the two).
• Enumerations and classes used as attribute types (similarly to Representation).
• Restrictions on the domain and range of fixed-part relations.

Data representation using Named Graphs

While axioms are just bunches of triples that can be encoded with plain RDF, axiom metadata and contextual information are more complex to represent in RDF; still, their RDF representation is a requirement for enabling import and export of RDF entity data and thus making the KnowledgeStore compatible with existing RDF datasets. This issue is addressed using named graphs, an extension of RDF supported by the majority of tools and by several RDF syntaxes, and following and extending the CKR approach. Using named graphs, an axiom together with its context and metadata can be represented as shown below.

@prefix ckr: <http://dkm.fbk.eu/ckr/meta#> .

<module_uri> { ... axiom triples ... }

ckr:global {

  <module_uri>  <metadata_property_1> <metadata_value_1> ; ... ;
                <metadata_property_N> <metadata_value_N> .
              
  <context_uri> a ckr:Context ;
                ckr:hasModule <module_uri> ;
                <contextual_dimension_1> <contextual_value_1> ; ... ;
                <contextual_dimension_M> <contextual_value_M> ;
}

Triples encoding the axiom are stored in a graph called module, which in turn is associated to the axiom metadata inside a special ckr:global graph; contextual information is also encoded in ckr:global, and attached to the axiom module via a ckr:hasModule triple. While seemingly verbose, this representation allows putting multiple axioms in the same module in case they share the same context and metadata (this is often the case for axioms coming from the same source), thus limiting the number of triples in ckr:global and making the associated overhead negligible. A concrete example of this representation is reported below.

# ckr, ks, nwr, sem, dbo, ex, dbpedia, dbo, xsd prefix definitions omitted

ex:mod01 { dbpedia:Barack_Obama dbo:birthPlace dbpedia:Honolulu }  # the axiom

ckr:global {

  ex:mod01 nwr:crystallized "true"^^xsd:boolean ;        
           nwr:confidence 1.0 ;
           nwr:source dbpedia:DBPedia ;                  # comes from DBPedia
           ks:expressedBy ex:mention15 , ex:mention127 . # but also extracted from
                                                         # two mentions
  ex:ctx01 a ckr:Context ;
           ckr:hasModule ex:mod01 ;
           sem:hasTimeValidity ex:any-time ;  # open interval, definition omitted
           sem:hasPointOfView ex:common-pov . # express common POV without particular 
                                              # authority, definition omitted
}

Terms reference