Dear Matthew and David, (01)
I mostly agree with the points you made in notes from the thread
of the Ontology Summit. They remind me of the split between
theory and practice that has plagued computer science and systems. (02)
I recommend a survey of the issues by Joseph Goguen:
http://cseweb.ucsd.edu/~goguen/pps/tcs97.pdf
Tossing algebraic flowers down the great divide (03)
Excerpt from page 1:
> Computer science is in deep crisis, expanding, fragmenting, and
> specializing faster than any other discipline, faster than anyone
> can understand, let alone predict. Moreover, computer science is
> increasingly seen as marginal to its applications, and this is
> particularly true of theoretical computer science. (04)
Goguen wrote this paper in 1997 as "a diary of a very personal journey"
of his experiences from the 1960s to '90s. Along the way, he moves
"from a mathematical view of computing, through a process of
questioning of why it wasn't working as hoped, to a wider view that
tries to integrate the technical and social dimensions of computing." (05)
Today, the divide is just as great or greater. In the copy below,
I relate the exchange between Matthew and David (shortened by some
deletions) to some of the issues that Goguen discusses. My comments
are prefixed with JFS. (06)
John (07)
-------- Original Message --------
Subject: Re: [ontology-summit] Questions from Session 2
Date: Fri, 28 Mar 2014
From: Matthew West (08)
DP
> People have been told ontology development is very hard and costly. (09)
And this is wrong, at least in relative terms. Ontology development is
always part of some greater project. The example I will give is Shell's
Downstream One project, which was a multi-billion dollar project to
reorient Shell's Downstream business from a devolved to centralised
model using a single set of systems globally. (010)
We developed ... a data model for the downstream business, cost
in the region of half a million dollars. (011)
JFS
> As you note, that ontology is called a data model. It's derived
> from past experience and the new requirements. It may use ideas
> and components based on theory, but the development requires much
> more than downloading and tailoring somebody's predefined ontology.
>
> As Goguen said, the "mathematical view" (some theory of ontology)
> must be integrated with the "social dimensions". (012)
-----Original Message-----
From: David Price
Sent: 27 March 2014 (013)
A lot of these questions depend on the discipline or industry in which
they are created. (014)
On 27 Mar 2014, at 09:59, Matthew West wrote:
> During the last session ... on Bottlenecks in Ontology Engineering,
> we were asked some questions:
>
> 1. What are the lessons learned from in-the-wild ontology
> engineering projects? (015)
Developing an OWL ontology has the same degree of difficulty as any
other data modeling exercise (i.e. RDBs, ISO EXPRESS, E/R, UML and
OWL require language and tool expertise to do anything real). The hard
problems are the same in most cases : understanding the requirements
and generating clear, accurate but concise definitions everyone
agrees. (016)
The big benefits of OWL ontologies are that the more accurately reflect
"what is" than other data models, that the underlying technology is so
flexible that it enables very quick proof-of-concept and/or testing and
it also allows throwing together almost anything and then fixing it up
as you go. (017)
JFS
> Yes, but... The reason why they are so flexible is that they are
> underspecified. The subset of OWL that most people use -- which
> is also the subset that Google et al. adopted for Schema.org --
> doesn't use anything beyond Aristotle's syllogisms. (018)
If you've not tested your ontology against real data, it is definitely
"wrong". If you have tested your ontology against real data, it is less
wrong but still wrong. Plan improvements over time into your project,
even once the apps are operational. (019)
> 2. How do challenges related to cultural and motivational issues
> relate to technical issues, e.g., tool support? (020)
A key issue I see is the separation of ontology and the software apps
that use them, and the skills required to cross that chasm. It's hard
to get software developers to understand ontologies and it's hard to
get ontologists to understand the needs of software developers (e.g
the "human readable URI" discussion). (021)
JFS
> Yes indeed! That is a symptom of the Great Divide. (022)
We are a tool and solution vendor and have chosen the approach of
fitting ontology development tools into a larger IDE for software
development... (023)
JFS
> I strongly agree! Note that this point reflects Goguen's emphasis on
> relating *both* technical and social requirements. That word 'social'
> includes much, much more than just human factors or HCI. (024)
People have been told ontology development is very hard and costly. Once
they have it in their heads, it's very hard to convince them otherwise.
... we run into many situations where short sighted people ignore that
knowledge transfer, thinking they are saving money, and then they pay
the price over and over again as the project progresses. (025)
JFS
> Yes, but. If you want people to be virtuous, make virtue the path
> of least resistance. The social issues are very important. (026)
MW
> 3. How to get community buy-in? (027)
Buy-in of specific organisations is far more important, it is very hard
to directly convince a community of anything. However, convince a few
individual organisations and once they are successful, others will
follow... (028)
JFS
> More social issues. (029)
MW
> 4. What are the tradeoffs between expressiveness vs. pragmatics? (030)
MW explained this concisely. Expressiveness is primary when you don't
know the specific questions to be answered (e.g. in a data integration
app). You can always transform to a less-express form when you finally
do know the questions, but you have lost too much to easily go the
other way if you start with the less-expressive ontology. (031)
JFS
> Yes. A very simple language, such as the Aristotelian subset of OWL,
> is a good starting point. But trying to shoe-horn anything more into
> a highly constrained language is more trouble than it's worth. For
> further discussion, see http://www.jfsowa.com/pubs/fflogic.pdf (032)
MW
> 5. Who will develop all the ontologies we would ideally need? (033)
Apologies, but this is a very naive question. Individual organisations
will develop ontologies *they* need, not what others need. If they
choose to share those openly that's great, but most commercial
enterprises will not do so as they see them as a business advantage
over their competitors. There are, of course, cases where standards
need to be created and I expect most shared ontologies will come from
standards bodies, consortia or national institutes over time. I'd say
that there will eventually be foundations upon which you can build
what you need, but nobody will every "develop all the ontologies we
would ideally need". Focus on identifying and supporting those
foundations is a good first step. (034)
JFS
> I *very* strongly agree. (035)
MW
> 6. What is the role of crowd-sourcing? (036)
None at all in the industries where we typically work like engineering
and life science industries. In life sciences, for example, even the
areas of interest are confidential. I'm sure there are others where it
has an interesting role ... particularly where vocabulary rather than
ontology are primary. (037)
JFS
> I agree. The methods for deriving proto-ontologies automatically
> from NL documents is rapidly becoming cheaper, faster, and more
> accurate than anything a crowd could produce. (038)
MW
> 7. What is the state-of-the art with respect to quality control? (039)
Test, test, test ... exactly as with any other software artefact. (040)
MW
> 8. How is the industry addressing ontology engineering bottlenecks
> and what are the technological solutions available on the market today? (041)
I have found that the more you treat ontology development as part of a
larger software app project, where requirements management, testing,
software change control, etc. are used - the better... (042)
Given that I said ontology development is really a component of software
development, I will add that Jena, github, JIRA, SpiraTest, SOAPUI,
Confluence, Google Docs, MySQL, GoToMeeting and Skype are all
components the larger technical solution for distributed semantic app
and ontology development. (043)
JFS
> I agree. But developers need an integrated platform that lets them
> move seamlessly from one tool to another without even thinking of
> them as separate tools. (044)
MW
> 9. How much (deep) semantics do customers really need? (045)
There is no single answer, it depends on the industry. For example -
Engineering : quite a lot. Life sciences : medium. Publishing : very
little as they focus on vocabularies. (046)
JFS
> I agree. But a single company has different departments that have
> requirements at each of those levels: Engineering, Manufacturing,
> Finance, Inventory, Shipping, Sales, and Management. They talk with
> each other. They use the same terminology. But each department
> may define the same terms with emphasis on different details. (047)
_________________________________________________________________
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 (048)
|