A lot of these questions depend on the discipline or industry in which they are
being created. (01)
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. (02)
On 27 Mar 2014, at 09:59, Matthew West <dr.matthew.west@xxxxxxxxx> wrote: (03)
> 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? (04)
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. (05)
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. (06)
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. (07)
>
> 2. How do challenges related to cultural and motivational issues
> relate to technical issues, e.g., tool support? (08)
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. (09)
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. (010)
>
> 3. How to get community buy-in? (011)
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). (012)
>
> 4. What are the tradeoffs between expressiveness vs. pragmatics? (013)
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. (014)
>
> 5. Who will develop all the ontologies we would ideally need? (015)
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. (016)
>
> 6. What is the role of crowd-sourcing? (017)
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. (018)
>
> 7. What is the state-of-the art with respect to quality control? (019)
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. (020)
In every app that will go operational, we obviously have the "production"
deployment and a separate "testing" deployment environment. (021)
>
> 8. How is the industry addressing ontology engineering bottlenecks and
> what are the technological solutions available on the market today? (022)
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). (023)
Addressing ontology engineering bottlenecks can be approached in several ways.
We think the following are important for RDF/OWL development. (024)
- 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. (025)
- 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). (026)
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. (027)
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. (028)
>
> 9. How much (deep) semantics do customers really need? (029)
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. (030)
Cheers,
David (031)
>
>
>
> 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/ (032)
_________________________________________________________________
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/ (033)
|