• User Guide
  
  
• Contents
• Raw import
• Natural import
• OWL option
• Export to RDF(S)

Contents

Import from RDFS
Export to RDFS

Import from RDF(S)

Cogui is able to import RDF(S) documents. The first translation is sound and complete from a reasoning view point but is not visual nor a representation in the spirit of Conceptual Graphs (CGs). The second translation has the advantage of being natural and fully exploiting the CG features, but, on the other hand it does not apply to the whole RDF(S).

RDF imports can be placed inside a new project or can populate an existing project.The most common way is to import a vocabulary and then add one or more data files based on this vocabulary . But it is also possible to import several vocabularies and combine them in a same project.

Input file format

RDF is a model, several serialization formats exist to represent it. Cogui can parse 3 formats:

• RDF/XML: the syntax defined by W3C.
• Notation 3 (N3): a simplest non xml format
• Turtle: closely related to N3

The xml:base attribute is not always specified in input file, or you could want to change it and specify another base URI for your imports. Enter the URI in the import dialog.
 

The xml:base attribute specified by user will not force the base URI. It is used only if the attribute is not defined in the data file.

if you choose the first option, the file format will automatically be selected depending on the file extension. if file extension is not recognize, RDF/XML is the default.

Otherwise you'll probably receive this message:

Namespaces

When input files are parsed, namespaces and their prefixes are registered into the project properties. Namespaces can be accessed and updated by menu option 'File/Properties'.
If several ontologies are combined or if user want to integrate new types and individuals before exporting to RDFS, it can be useful to manipulate namespaces. Recovered namespaces and/or new namespaces can be used to transform type and individual identifiers to build correct URIs.

Note that existing references to the modified identifier are updated into the whole knowledge base.

Graph options

Factual knowledge is expressed by fact graphs added to the project. All knowledge resulting on importation can be placed in a unique graph or splitted by connected components. One fact graph for each connected component of the graph is the default. Each facts is named with a given prefix and an automatic number.
After

Raw Mode

This translation simply translate each triple RDF in a ternary relation where each of the concept nodes of the relation will represent the RDF triple elements. It ensures soundness and completeness of homomorphism. However, this translation is not visual or in the spirit of Conceptual Graphs as such (the support is flat).

To be used to find homomorphisms, this mode requires to add RDF and RDFS axioms as facts and to apply several RDF and RDFS rules. This facts and rules can be automatically created during importation. Check corresponding boxes on raw mode dialog:

This mode is interesting to demonstrate some properties but in practice, it cannot be used with big graphs because the application of all rules on the sum graphs of imports plus rdf(s) axioms quickly increases the graph size.

Natural Mode

This translation is more intuitive and doesn't need rules to be applied because most of them are implicitly expressed in the support. The main idea behind it is to try to exploit as much as possible the separation between background knowledge and factual knowledge. Several options are available.
If support completion option is checked, support is enriched by the imports
Uncheck the box to preserve current vocabulary and only take factual knowledge into account.

When support completion is allowed two ways exist to express rdfs:range and rdfs:domain semantic. The default is to define relation type signatures but it can be expressed by range rules and domain rules, depending on the purpose. Do the user want to correct future factual imports or to have a way to verify imports with signature.

For example a property can be translated as a CG relation type with its signature or with rules

signature

domain rule

range rule

Note that the generated rules can be considered as positive constraints which is very similar to signature checking. Just drag rules from rule set to the constraint set on the project tree.

OWL Option

The semantics of rdfs is taken into account almost entirely. This is not the case with OWL. However, many ontologies are defined with OWL. In practice the processing of anonymous classes and the treatment of most used properties of OWL allows to recover a significant part of the semantics of these ontologies. Thus, cogui offers an option that takes into account including anonymous classes, that are used during the processing of import. Some deductions were made using property restrictions, intersections and unions of classes and are expressed on the support. By default, after treatment all anonymous classes are removed from the type hierarchies, check option box to keep these classes.
The owl:disjointWith property is used to defined banned type in the concept type hierarchy.
In addition, some OWL properties are also expressed by rules, see below examples from importation of wine.owl ontology:

owl:SymmetricProperty	owl:inverseOf
owl:TransitiveProperty	owl:allValuesFrom

Export to RDF(S)

Cogui is able to export projects to RDF with RDF/XML or N3 formats. For now only type hierarchies and facts can be exported. Rules , constraints and type disjunctions are ignored. But domain and range constraints induced by relation type signature are translated. All namespaces defined in the project are declared in output. By default, a multilingual version is produced, a monolingual version is also available with current selected language.

©2011 Cogui Documentation

GraphIK Team.