Dear John, (01)
> MW
> > I have developed an integrated "upper ontology" for all of Shell's
> > downstream business, which covered what you describe and more.
>
> That would be an excellent example.
>
> MW
> > My experience at Shell confirms your [MFU's] experience of between
> > 1000-2000 concepts for an upper ontology with the scope you describe.
>
> Can you post that ontology on the wiki or other web site? If it has
> some proprietary features, could you remove them before posting it? (02)
MW: I am more than 4 years out of Shell now, and the Downstream Data Model
was certainly Shell Confidential. However, my book "Developing High Quality
Data Models" http://store.elsevier.com/product.jsp?isbn=9780123751065
provides a further development of some parts of that work. The data model
(but not the explanation) from that is also available on the web at:
http://homepages.rya-online.net/matthew-west/hqdm_framework/ (03)
>
> JFS
> >> The sales model, the engineering model, and the manufacturing model
> >> will require very different upper ontologies...
> >> They would also require very different detailed layers.
>
> MW
> > More interesting (and important) is what they share.
>
> Both are important, but we need examples. Can you provide them? (04)
MW: Well Person and Organization turn up in all aspects of a business, and
Assets turn up in Manufacturing as do products. Finance is also of course
pretty ubiquitous. Procurement has links to both assets and products (but
now other peoples) and Sales is just procurement viewed from the other side.
>
> MW
> > When Shell first tried to develop common data about the performance
> of
> > its UK downstream business it found more than 100 different coding
> > systems for its products.
>
> That is typical of most enterprises. (05)
MW: Of course. (06)
> The problem is even more serious
> when independently developed software at different companies must
> interoperate. That is why the Amazon.com example is important. (07)
MW: It is not clear to me that lots of companies using Amazon means that
they are interoperating with it. I would not be surprised if many companies
(especially smaller ones) were just using it as their sales system, and not
connecting it to anything else. Equally, I can imagine that many accounting
systems might find it appropriate to develop an Amazon interface for their
software.
>
> JFS
> >> I agree that systems analysts have a lot to learn about ontology.
> >> But most academic philosophers and logicians are totally clueless
> >> about how to design a working system. Both kinds of skills are
> >> important, and very few people have much, if any experience with
> both.
>
> MW
> > And that is one of the biggest problems.
>
> JFS
> >> We desperately need good tools that bridge the gap between the two.
>
> MW
> > No, we need education. A fool with a tool is still a fool.
>
> The domain experts or SMEs are not fools.
> They have years of practical
> experience, and many of them have an MS, PhD, or MD. (08)
MW: The Dilbert Principle states "We are all idiots some of the time!" And
in any case just because (and perhaps especially because) we are expert in
one thing that we have studied, does not mean we are expert in something we
have not. (09)
> It would be more
> foolish to waste their time in a course on philosophical jargon. (010)
MW: I thought we already established that it was principles that were
important, not jargon, so please don't keep going on about it. (011)
> It's
> far better to design tools based on the notations and terminology that
> they use to communicate among themselves. (012)
MW: Tools are of course important, but they aren't a substitute for
ontological principles. Just because you need one, does not mean you don't
need the other.
>
> JFS
> >> The ontology tools are woefully inadequate for system design and
> >> development, and the tools for systems analysis don't provide any
> >> guidance about ontology design and use.
>
> MW
> > Nor should they. In my view it is important for tools to be
> > ontological commitment neutral.
>
> I agree that the tools themselves and the logic that supports them
> should be as neutral as possible. But you need to load the tools with
> a particular ontology, the words that express it, and the mappings to
> and from the notations that the domain experts use. As soon as you do
> that, the tools are ideally adapted to what the domain experts know. (013)
MW: Of course! But this is the work that people who are ontologically
trained need to do, not domain experts, unless they are also ontologically
trained.
>
> JFS, quoting and modifying an article on Big Data
> >> What if domain experts could directly encode their ideas and
> >> representations of their domains into the system, bypassing the data
> >> scientists [ontologists] as middleman and translator?
>
> MW
> > As I recall, that was the claim made for SQL..., and for COBOL as the
> > "end of programming".
>
> COBOL was designed over 50 years ago. SQL was designed nearly 40 years
> ago. I won't claim that they're perfect. But they certainly got far
> more practical use than any notation for ontology or the Semantic Web. (014)
MW: Yes, but not by end users.
>
> MW
> > You are extremely unlikely to produce a good ontological model
> without
> > a good working knowledge of ontological principles and problems.
>
> The people who design the tools certainly need that knowledge. (015)
MW: Yes, but mostly so as not to make accidental ontological commitments by
just assuming the way they saw the world was just the way it is. (016)
> But it
> is possible to extract a proto-ontology directly from documents written
> by the domain experts in ordinary NLs. Then the domain experts can
> update and correct the proto-ontology using only terminology and
> notations that they prefer. (017)
MW: You can certainly do something to support the development of an
ontology, but I have yet to see a document set that could be analysed
accurately without asking questions. So there are limits to what can be
automated.
>
> We've developed such tools at VivoMind, and the users love them.
> But we're not the only ones who are working on these issues. For an
> overview see
>
> http://www.jfsowa.com/pubs/futures.pdf
> Future directions in semantic systems (018)
MW: Yes, I have supervised EU funded projects that looked into this area. It
was hard to know whether to be impressed by what could be achieved by
semi-automation, or frustrated at the limitations and need for manual
intervention. (019)
Regards (020)
Matthew West
Information Junction
Tel: +44 1489 880185
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
http://www.matthew-west.org.uk/ (021)
This email originates from Information Junction Ltd. Registered in England
and Wales No. 6632177.
Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
Hertfordshire, SG6 3JE. (022)
_________________________________________________________________
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/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/ (023)
|