• LarkcProject
• WP1
• D1.1.3
• SummaryOfDiscussion

Summary of the discussion

Points of agreement on minimal knowledge representation formalism seem to be:

• Syntactic form should be based on RDF.

• Expressiveness should go beyond RDF --> RDFS + slight extension.

• We need meta-vocabulary to indicate concrete syntax used by a plugin.
• We cannot enforce minimally required semantics implemented by plugins.
• We can give recommendation on minimally implemented modeling primitives and semantics (as baseline for: unsoundness, incompleteness).
• We cannot recommend minimal functional requirements for non-reasoning plug-ins.
• We need meta-vocabulary to indicate semantics and modeling primitives supported by a plugin (language profiles, extensibility).
• Plugins are obviously allowed to implement functionality beyond the basic language.

Open issues:

• What is the intended purpose of the "LarKC minimal knowledge representation language"?
  • What does it mean to have a "LarKC minimal knowledge representation language" (conformance of plugins, benefits, ...).

    • Defintion of syntax and semantics?

    • Every LarKC plugin should be able to minimally read that syntax?
    • Every reasoning plugin should be sound and complete wrt to this semantics?
• What should this language be?
  • Modeling primitives (RDFS, ....).
  • Syntactic form extends RDF (Quads, 3 + n Tuples, ...)?
  • How to specify the semantics
• How do we specify the meta-vocabulary required?

Existing viewpoints:

A chapter in D1.1.3 (http://svn.larkc.eu/wp1/larkc113/) is concerned with the definition of a minimal representation language. This language obviously has to meet certain requirements in LarKC, i.e. inherent tractability in the face of large scale reasoning, existing Web standards, ... There are two (seemingly) conflicting design goals:

1. Maximise interoperability between LarKC plugins by fixing a single representation language.
2. Maximise the variety of applications for which LarKC can be used by enabling a flexible representation language.

One solution is to "define a minimal representation language and define meta-vocabulary for semantic extensions" + define "language profiles" which allow different representational extensions and restrictions w.r.t. to the mandatory representational language. Practically very relevant work in this direction is being carried out in the OWL2 working group via the definition of distinct "profiles": http://www.w3.org/2007/OWL/wiki/Profiles This would define both syntax + semtantics for a minimal language and define a well-behaved and normative meaning wrt to possible inferences on top of the language. In this way such a solution would enforce a minimally required semantic interpretation and also impose minimal functional requirements on (reasoning) plugins. There is currently a outline of this available: Chapter 4 outline.

A follow up proposal by Frank and Annette, that would require certain changes to the previous outline, proposes to fix syntactic format only (RDF based), and have no minimal normative semantics, only a meta-vocabulary for semantic extension. This proposal includes several conclusions that form basic discussion points.

1. Syntactic form: Should be RDF or light extension (quads, ...)
2. We need a meta-vocabulary to indicate the concrete syntax (N3, RDF/XML, ...)
3. There is no need to enforce minimally required semantic interpretations.
4. We cannot define minimal functional requirements for plug-ins (beyond REASONing plug-ins).
5. We need a meta-vocabulary to indicate the semantic interpretation a plug-in supports.

Several points raised by Dieter are summarized following:

1. Formal semantics by itself of limited value (discussion with Frank, 1993, Bonn).
2. Semantics implemented by a plug-in should be flexible (e.g. interpretation of range/domain restrictions: inferring or as constraints).
3. Start with RDF.
4. Starting with RDF does not mean to start only with syntax: It already is a specific conceptual model.
5. We should go slightly beyond RDF. I.e. a language that is close to RDFS + extensions and is still practically tractable (by avoiding OWL-Lite's pitfalls).
6. For this we could add consensual modeling primitives that account for both multiple models versus minimal model semantics.
7. Such a definition of tractable profiles is also promoted by the OWL2 WG (see the link above).
8. LarKC should not stay behind the state-of-the-art.

Dieter's conclusions wrt to plug-ins:

1. Plug-ins should support a common core set of modeling primitives.
2. Plug-ins should subscribe to a common meaning for these core primitives.
3. Plug-ins may provide proprietary extensions (in terms of more modeling primitives).