|From:||Amanda Vizedom <amanda.vizedom@xxxxxxxxx>|
|Date:||Thu, 22 Nov 2012 13:22:59 -0500|
<climbs atop a small pile of soapboxes>
(1) Controlling language -- setting and using naming standards, for example, -- is *much* harder than building and using shared ontologies. Why? Because language and naming are things humans do/use constantly, are part of their natural behavior, are intertwined with cognitive and behavioral adaptations in many ways. And standardizing the language people use away from their ever-adapting expert language interferes with that adaptation. If the job needs to be done, the tension here is (correctly) going to resolve in favor of the adaptation and away from the standardization.
(2) It is a central, advantageous feature of ontological representation that it can enable and support shared models, shared metadata, and interoperability *without* requiring controlled and standardized language use. Not all ontology-based projects have staff with sufficient training to understand and use that advantage. Those that don't use it end up bogged down in naming and language debates.
(3) Available out-of-the-box tools (and standard KR languages) need to grow to support and emphasize this feature and ontologies (for example, via built-in support for specifying multiple labels for a concept, with lexical and localization information for those labels, and support for viewing/browsing an ontology with some specific localization used to select display labels. This is pretty easy compared to many other ontology-interaction problems. But it isn't there in the off-the-shelf stuff (in contrast, it *is* there in a range of commercial/proprietary and/or in-house tools that have to deal with multilingual, business vertical, or other localizations.
(4) One reason people don't use ontologies more is because there is no consensus on quality and methodology, and they don't know who to trust. Those who say the have the One Methodology To Rule Them All are at best no better than everyone else at delivering something useful. That's because we *don't* need One Methodology To Rule Them All. We need a good understanding of what ontology features matter to what kinds of projects: that is, an understanding of what it means for an ontology to be suitable for an application, fit for a particular use case.
(5) Until we build that kind of understanding -- at least a start -- some people who could benefit from ontology applications will continue to balk at the lack of clarity, while other people will go ahead but invest in ontology that is mismatched to the requirements. The latter experiences make the climate for ontology adoption worse.
(6) I suggest that it should be very high on our priority list to work on building that shared understanding of the relationships between use case features and suitable ontology features. We can really only do that effectively as a community, sharing experiences and collaborating on the lessons learned. There are enough of us, across industries and sectors, to get going and make progress on this. There are also many who won't share just yet because they aren't sure whether the payoff of sharing outweighs their trained resistance to making in-house knowledge public. We can still move, and try to pick them up as we gain momentum.
(7) A good ontologist can, in fact, come in and build something and make a difference in two weeks. BUT this assumes that it is clear what the ontology is for, how it will be used, what requirements come from downstream, and what sources are to be regarded as authoritative, AND that the ontologists is provided access to those sources. The reality is that the ontologist often walks into a situation in which few or none of those conditions are met. Sometimes it just hasn't occurred to anyone to do them; sometimes it has but no one knows how. Sometimes an experienced ontologist is actually there who knows how, but isn't give the authority or resource access to do this requirements identification. Result: value not delivered. I suggest that (6) is also important because it begins to address this problem by building shared understanding of what use case features are important to identify.
</climbs down from soapboxes to go check on roasting turkey>
On Thu, Nov 22, 2012 at 12:17 PM, David Eddy <deddy@xxxxxxxxxxxxx> wrote:
_________________________________________________________________ Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/ Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx Shared Files: http://ontolog.cim3.net/file/ Community Wiki: http://ontolog.cim3.net/wiki/ To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [ontolog-forum] Webby objects, Ron Wheeler|
|Next by Date:||Re: [ontolog-forum] doing standards [was - Re: Webby objects], Godfrey Rust|
|Previous by Thread:||Re: [ontolog-forum] doing standards [was - Re: Webby objects], David Eddy|
|Next by Thread:||Re: [ontolog-forum] doing standards [was - Re: Webby objects], Obrst, Leo J.|
|Indexes:||[Date] [Thread] [Top] [All Lists]|