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

Deana Pennington dpennington at lternet.edu
Thu Jan 11 09:35:16 PST 2007


Hi Ferdinando,

In looking at this and the links Sergei sent, it's clear I'm in over my 
head technically :-)  I think for the purpose of this particular call 
for papers (copied below), we should separate the "needs assessment" 
from the technical solutions.  I think Josh and I could work together on 
a paper using SEEK as a case study in collaborative ontology development 
and setting up the need for this kind of system, focusing on the items 
in blue below.  Once we have a draft, we could send it to you and other 
coauthors for review and editing.  Then, a second paper could be written 
focusing on the technical solutions, led by you.  I can't contribute 
anything solid to that, but would like to be included as a co-author in 
"reviewing and editing" mode.  This could either be the 4 page demo 
paper as we discussed, or it could be a second research paper -- depends 
on how much you want to take on.  If you do a second research paper, 
then you could also do a demo (if you have that much time and energy).  
My main point is that I think that Josh and I have enough material we 
can contribute to a case study paper that drives technical requirement 
without going into the technical solutions, and the solutions should be 
separate.  What do you think?

I think that going from Topic Maps to OWL and vice versa is part of the 
problem.  We'll have to also think about going from Concept Maps to 
Topic Maps, and how we can effectively constrain the structure of the 
concept map so that it at least approaches a topic map.  I tried to 
constrain the associations used by the scientists doing the niche 
concept maps, but wasn't very effective at it.  But, I think it's 
do-able with some more effort on thinking about categories of 
associations they might want to map and ways to deal with those that 
will be manageable.

Deana


# *collaborative construction of structured knowledge and ontologies*:

    * collaborative creation and editing of structured knowledge
      /(different approaches we've tried in SEEK)/
    * requirements for collaborative tools /(as a high level synthesis
      of the solutions you are going to present)/
    * user-specific views of ontologies /(as a need established by our
      SEEK case study)/
    * extracting structure and ontologies from tags and annotations
    * evaluation of collaborative tools
    * collaborative evaluation of ontologies /(as a need established by
      our SEEk case study)/
    * user interfaces for collaborative tools for creating structured
      knowledge
    * trust in collaborative construction of knowledge
    * case studies of collaborative ontology-development project. /(The
      SEEK example)/

 

Ferdinando Villa wrote:
> 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
>
>   


-- 
********

Deana D. Pennington, PhD
Long-term Ecological Research Network Office

UNM Biology Department
MSC03  2020
1 University of New Mexico
Albuquerque, NM  87131-0001

505-277-2595 (office)
505-249-2604 (cell)
505 277-2541 (fax)



More information about the Seek-kr-sms mailing list