Dear David, (01)
Thanks for those comments - very helpful. A comment. (02)
DP: People have been told ontology development is very hard and costly. (03)
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. We developed (I lead, DP was part of the
team) a data model for the downstream business, cost in the region of half a
million dollars. The guy running the project was indeed concerned about how
much it would cost, but when he heard what it would actually cost, didn't
even want to hear the justification - he said "just do it". (04)
Regards (05)
Matthew West
Information Junction
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
https://www.matthew-west.org.uk/
This email originates from Information Junction Ltd. Registered in England
and Wales No. 6632177.
Registered office: 8 Ennismore Close, Letchworth Garden City, Hertfordshire,
SG6 2SU. (06)
-----Original Message-----
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Price
Sent: 27 March 2014 12:01
To: Ontology Summit 2012 discussion
Subject: Re: [ontology-summit] [Bottlenecks] Questions from Session 2 (07)
A lot of these questions depend on the discipline or industry in which they
are being created. (08)
I had hoped to present at the session, but in the end could not so I've
responded below in more detail as my contribution to the exercise. (09)
On 27 Mar 2014, at 09:59, Matthew West <dr.matthew.west@xxxxxxxxx> wrote: (010)
> Dear Colleagues,
>
> During the last session Track C session on Bottlenecks in Ontology
> Engineering, we were asked some questions. I repeat these below to
> solicit your answers to these questions, and I provide some of my own
> where I have some.
>
>
>
> Here are the questions:
>
> 1. What are the lessons learned from in-the-wild ontology
engineering
> projects? (011)
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. (012)
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. (013)
If you've not tested your ontology against real data, it is definitely
"wrong". If you have testing your ontology against real data, it less wrong
but still wrong. Plan improvements over time into your project, even once
the apps are operational. (014)
>
> 2. How do challenges related to cultural and motivational issues
> relate to technical issues, e.g., tool support? (015)
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). We are a tool and solution vendor and have chosen
the approach of fitting ontology development tools into a larger IDE for
software development. Our view is that building ontologies is nice, but
delivers very little business value compared with building complete Semantic
Applications. (016)
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. In
any engineering or science discipline, what they've learned to do their job
is orders of magnitude harder than ontology development. This adds to the
challenge of making very robust tools that are simpler to use. They key is
to make people understand that *with knowledge transfer* they can pick up
enough to be productive quite quickly ... 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. (017)
>
> 3. How to get community buy-in? (018)
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 if
only because of a fear of being left behind. Some large organizations (e.g.
DoD have a community that follow them so orgs like that are great candidates
to be the lead). (019)
>
> 4. What are the tradeoffs between expressiveness vs. pragmatics? (020)
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. (021)
>
> 5. Who will develop all the ontologies we would ideally need? (022)
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. (023)
>
> 6. What is the role of crowd-sourcing? (024)
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. (025)
>
> 7. What is the state-of-the art with respect to quality control? (026)
Test, test, test ... exactly as with any other software artefact. Therefore,
the state of the art is automated testing driven by robust requirements and
testing tools. We do not manage to do this properly for every app, but we do
set up our ontology projects exactly as if they are normal software
development projects and build in test cases, testing processes and
validation/QA infrastructure even if we don't use it everywhere. In our best
case of this set up completely, we can literally push a button and have a
dashboard go green when all the automated test cases pass, which for our
customer that means "acceptance test" is successful and we're ready to
deploy to production. (027)
In every app that will go operational, we obviously have the "production"
deployment and a separate "testing" deployment environment. (028)
>
> 8. How is the industry addressing ontology engineering bottlenecks
and
> what are the technological solutions available on the market today? (029)
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. In 90+ percent of cases
where project problems/delays have occurred it's been a lack of clear
requirements, changed requirements or customer-lack of understanding their
requirements that have been the root cause. The "work" is not that hard if
requirements are complete. The work is hard if you're given an undocumented
XML Schema as the data requirements for your app (and that does happen). (030)
Addressing ontology engineering bottlenecks can be approached in several
ways. We think the following are important for RDF/OWL development. (031)
- Everything is triples. That means we can apply Semantic Web tech to
everything. XML and XML Schema are triples, spreadsheets are triples, RDBs
are triples, SPARQL queries, SPIN rules/constraints and stored SPIN/SPARQL
templates are triples ... you get the picture. (032)
- Innovate but be standards-based. For example, we built a rules engine as
an extension to SPARQL, called SPIN, which has been made a member submission
back to W3C. Innovating over an existing standard means there's already a
large number of people who know 75% of the technical solution, because they
know SPARQL. We do a lot with SPIN and I'd say that SPIN/SPARQL are far more
important than OWL itself as far as addressing ontology engineering
bottlenecks (e.g. quick testing, access to real data). (033)
Being a software company I guess it's obvious that I'll add that the
TopBraid Suite is a technical solution available on the market today.
TopBraid sits over eclipse so they should be mentioned as well. (034)
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. (035)
>
> 9. How much (deep) semantics do customers really need? (036)
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. (037)
Cheers,
David (038)
>
>
>
> I'm going to pick a couple of these:
>
> What are the tradeoffs between expressiveness vs. pragmatics?
>
> Two kinds of ontology I find have different requirements.
>
> The first sort I would call a descriptive ontology, where the purpose
> is to as accurate as possible to how some domain is, not so much for
> reasoning, but for documentation. In this situation expressiveness is
> everything. If you cannot say something that is true, then that is a
severe limitation.
>
> The second sort is aimed at solving a specific problem. This is likely
> a subset of some descriptive ontology (if such exists) where some
> specific constraints apply, which may enable more efficient reasoning
> to take place, or indeed make reasoning possible/practical.
>
> There is only a problem, in my view, if we try to insist that there is
> only one type of ontology for a domain, rather than potentially more
> than one, with relationships between them.
>
>
>
> Who will develop all the ontologies we would ideally need?
>
> For any domain, there ought to be an identifiable authoritative
> source. I would hope that those authoritative sources would eventually
> understand their responsibility to develop these ontologies. In many
> cases these authoritative sources will be public administration
> bodies, or standardisation bodies. This would at least be better than
> several bodies developing, say, Unit of Measure ontologies, as is the case
at present.
>
>
>
> What is the state-of-the art with respect to quality control?
>
> There are some things that tools can help with, like logical
> consistency, but overall fitness for purpose is a human endeavour, and
> likely will be for some time. I hope with increasing computer assistance.
>
>
>
> How much (deep) semantics do customers really need?
>
> Not much. The priority is identity (same name (ID) for the same thing
> across those that need to share information).
>
>
>
> Regards
>
>
>
> Matthew West
>
> Wandering Glider
>
> <http://www.matthew-west.org.uk/wandering-glider>
> http://www.matthew-west.org.uk/wandering-glider
>
> Hon Sec MOCRA
>
> <http://www.mocra-sailing.co.uk/> http://www.mocra-sailing.co.uk/
>
> +44 750 338 5279
>
>
>
>
>
> _________________________________________________________________
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config:
> http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
> Community Wiki:
> http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
> Community Portal: http://ontolog.cim3.net/wiki/ (039)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/ (040)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/ (041)
|