This 'Open Ontology' requirement has been sitting on my desktop for a few days now, me thinking, how should I best publish this?
Write to the OSI foundation?
Wait for the next journal deadline? (could take months)
I have a couple of research papers underway, but admittedly I have not been coherently following a Journal Publication strategy in my research, nor in any other area of my life.
Also, now I am really urged to make a statement, cause I am already discussing this issue with peers, and there are so many perspectives, and I have not yet heard any doubts as to the validity of the proposed construct, on the contrary.
And also, let's admit it, the Times are achanging.
It could take months before the article is published.
We should bring this issue out in the open as soon as possible, and get it working.
So here it is.
What is an Open Ontology
With the term 'open ontology' we refer to a given set of agreed terms, both in terms of conceptualization and semantic formalization, that has been developed based on public consultation, that embodies and represents and synthesizes all available, valid knowledge that is deemed to pertain to a given domain, and is necessary to fulfill a given functional requirement.
Phew.
An Oont must be publicly documented, and accessible and with minimal barriers to adoption.
Among the barrier to adoption for Ontology, research identifies not only different linguistic, conceptual and cultural differences, but also knowledge and point of view differences that set apart academics – who generally develop ontologies and related tools and methodologies – from experts – who understand lingo and the dynamics - system developers – programmers, systems designers and end users at large.
By 'open' we indicate 'perfectly flexible', extensible, and with adaptive boundaries that dynamically adjust to constantly changing parameters and also 'open as opposed to 'closed', whereby an ontology is developed internally by an organization or consortium, with the purpose of imposing a single view of the world, without a public consultation process and no public deliverable is available that can be used and referenced as guidelines by system developers for the purpose of third party integration.
Research confirms that there are tangible barriers to use and adoption of ontology modeling tools and techniques, in particular the absence of a clear set of structured deliverables, the lack of a structured methodology for ontology engineering.
Among the barriers to entry is also an extremely high level of technical expertise required to decode and apply guidelines.
Open Means Collaborative
'Collaboration' is happening everywhere, thanks mainly to the Internet and 'Web 2.0' type tools that are populating desktops, although few organisational policies and practices are keeping up to speed in leveraging the potential of collaboration.
Open source communities have been early adopters of online collaboration environments, although increased abstraction and complexity and increased geographical and cultural distribution challenges effective online cooperation even among open source communities. It is argued by some that t ‘Open source’ is not suitable to Emergency Response projects, yet initiatives spontaneously emerged during recent disasters point towards the emergence of a possible model, that needs to be defined and refined before it can be evaluated and tested.
An important emerging research area is 'Collaborative ontology development'.
As put by Farrukh Najmi, Engineer at Sun, "Ontologies often need to be developed collaboratively by a group of geographically dispersed Domain Experts within a certain domain. Each Domain Expert builds a different sub-graph (network) of the ontology, may review the ontology sub-graphs produced by others, may edit ontology sub-graphs that they or another Domain Expert created with appropriate access control ".
Plural and Collaborative ontology development models are emerging, and among the core attributes identified is the flexibility in incorporating new concepts and/or languages .
A wealth of related work is becoming available to witness the shift towards open collaborative environments. Pinto describes collaborative ontology environments as:
• Highly distributed: Anyone can contribute more knowledge.
• Highly dynamic: Several contributors may be changing knowledge at the same time, with high change rates.
• Uncontrolled: There is no control over what information is added, and the quality and reliability of that information. In this case, there will be a lot of noise (positive and negative contributions), and not everybody contributing to the ontology will be focused on the same task or have the same purpose. (Pinto and Martins 2002)
GENERIC REQUIREMENTS FOR AN OPEN ONTOLOGY
Referring directly to a) the nature of the collaborative environments that is typical of open web based environments and b) the emergence of novel ontology engineering methods, it is becoming mandatory to make a clear case for an ‘Open Ontology’
In summary, we propose that an initial outline of requirement for an Open Ontology that can be referenced universally, including by open source teams, should have the following characteristics.
• Should be licensed under GPL, or similar public license
• It should declare what high level knowledge (upper level ontology) it references,
• It should declare what kind of reasoning/inference supports/it is based on,
• It should support queries via natural language as well as machine language,
• It should be visible, searchable and support queries via a Web based interface that does not require any plug-in and API for users to download,
• It should allow users to provide feedback that should be taken into account in subsequent iterations,
• It should be documented and annotated, and available in different file formats including Open Document,
• It should be 'easy to understand' by generic users without specialized skills and guidelines should be provided as how it can be used to support development practices,
• It should include instructions on how to relate such 'high level knowledge' to standard knowledge representation artifacts used in software and systems engineering, such as entities, attributes, classes, objects, properties, sub-properties, values and relationships,
• It should be implementation independent; this means not only usable by OWL/DAML model but also reusable by alternative ontology languages
• it should support one view of the world if required, and allow for simultaneous multiple views, meaning that it should aim to be perfectly elastic, flexible and adaptable,
• it should take into account language and cultural diversity, and corresponding different value systems and knowledge representation requirements,
• it should be supported by tutorials and educational materials at different levels of specialization.
The requirements above need further discussion and a public consultation.
In addition to the generic requirements above, more conventional system requirements should be specified depending on the target system and goals.
To add your requirement, Sign up to this wiki
More about Paola Di Maio

Comments
Post new comment