[seek-kr-sms] Ideas for discussion: shared development of ontologies

[Ferdinando Villa]

Hey all, 

continuing the discussion of last week on approaches to enable collaborative
ontology development, Banff paper and all. Here are a few thoughts from last
week's explorations - hope you can make sense of them. I'm prototyping some
of these things for Thinkcap (see below). Obviously we want something simple
for the first cut we've been discussing, but it's good to agree on a
consistent strategy before. See what you think and please send feedback! If
you have urgent points please share before end of the week - I'll be
traveling 1/14 to 1/27.

Cheers ferdinando

---

* Considerations on choice of "substrate" data structure for shared
knowledge development:

Ontologies are "distilled", minimal statements whose success depends on lack
of redundancy and very exact logics. Such crystalline structures are a very
suboptimal substrate for group discussion.

Concept maps are just at the other end: very flexible, free association,
therefore good for collaborative brainstorming with appropriate interfaces;
but lack of "direction" make conceptual drift a risk and there is no
built-in mechanism for either ensuring that topics are appropriately handled
and to ease the merging of the discussion back into the ontology.

Topic maps (TM: http://www.topicmaps.org) have several advantages:

   1. a little more structured than concept maps: topics, associations and
occurrences, with roles and scopes. Not much, very intuitive, but quite
powerful. Good info also at www.ontopia.com. 
   2. relatively formal and with an ISO standard, but much simpler and
without the logical constraints of OWL; supported by several tools and APIs
(can be loaded in cmaptools, JAVA interfaces available, serializers into XML
and text languages, permanent storage engines available).
   3. have a notion of type for topics, associations and roles of topics in
associations, allowing to constrain the pathways of the discussion into
useful tracks.

* Proposal:

   1. define an ontology of association roles and types that is optimal to
guide generation and analysis of TM that represent formal knowledge domains.
   2. identify a pathway to define an initial topic map from a conceptual
space defined as OWL (can cross ontology boundaries within knowledge base
and define arbitrary boundary concepts). This can happen using profiles that
map relationships and restrictions into topics and associations, with
relative documentation. The structure of the ontology can be relaxed and
documented selectively (only documented and relevant concepts/relationships
become part of the TM). The only constraint is that all topic are associated
to exactly one formal concept.
   3. define a search/edit/add process over the TM and not over the
ontology. New topics associated by users must use the association types and
roles predefined in the ontology that informs the TM process.
   4. Topics can be added by users to represent restricted or generalized
versions of concepts, documentation including URLs, documents, papers,
examples (see below). The core TM ontology informs a wizard to make adding
topics and associations intuitive and meaningful.
   5. Define a process to preprocess the collaboratively edited concept maps
and collect direction of the discusssion into likely changes to the
ontology, to inform an administrative interface. Facts about the desired
direction of the conceptualization in the community are collected as RDF
during editing, using listeners for topics and associations.
Reasoner-mediated process classifies these facts and prepares a set of
suggestions and key points for the administrators' attention. Analysis of
topics and editing process also constantly redefines weights of concepts in
search engine.
   6. The TM is stored permanently on server and becomes the reference for
the community process. All text searches (thinkcap-like) are done on the
topic map and related addressable resources, not on the ontology any more;
results always point to an OWL class as well as the related topics.

* Example taxonomy of association roles that can be used by system and users
to inform association interface and OWL <-> TM translation (very
preliminary, to be discussed):

AssociationRole
    AnnotationRole
        Comment
        Criticism
        DocumentationResource
        Example
        Explanation
        SourceIdentification
    ConceptualRole
        Generalization
        Restriction
            CanBe
            IsAlso
            MustBe
    ContainmentRole
        PartOf
    ContextualizationRole
        DisciplinaryLocation
        SpatialLocation
        TemporalLocation
    IncarnationRole
        InstanceOf
    OntologyModificationRole
        LinearConceptOperation
            AddConcept
            MergeConcepts
            ModifyConcept
        RestructuringOperation

* Action points:

   1. define TM ontology for translating OWL <-> TM and to guide the shared
collaboration (prototype available
http://www.integratedmodelling.org/ks/topicmaps/tm.owl).
   2. define initial process to translate a bounded portion of a concept
space (ontology or other, using boundary concepts) into TM using TM ontology
and optional translation profile (XML). Being prototyped in Thinklab as we
speak.
   3. define strategy for indexing and browsing of TM in similar way as
ThinkCap does now; TM substitutes the current direct indexing of ontology.
Each topic always links to a concept.
   4. define UI to enable collaborative editing of TM. Relatively major, but
can start small - two screen panes, find or create one topic in each,
association wizard uses TM ontology to guide associations.


--
Ferdinando Villa, Associate Research Professor, Ecoinformatics
Ecoinformatics Collaboratory, Gund Inst. for Ecol. Economics and Dept. of
Botany
University of Vermont           http://ecoinformatics.uvm.edu