Dear Matthew and William, (01)
JFS
>> The philosophical jargon is irrelevant to that task. (02)
MW
> The jargon is but the ideas aren't. (03)
Yes. I have a very high regard for *good* philosophy, and a very
low regard for tossing around jargon for the sake of jargon. (04)
See, for example, my tutorial on "knowledge design patterns", which
I presented at the Semantic Technology Conference in June: (05)
http://www.jfsowa.com/talks/kdptut.pdf (06)
I cited philosophers from the Presocratics to the present, and I try
to relate their ideas to current issues with a minimum of jargon.
I won't claim that my presentation is crystal clear, but I try to make
it historically accurate while showing its relevance to current issues. (07)
WF
> I seem to find that if one starts with a theory, the examples provided
> somehow wind up fitting it. Easy peasy. But collecting everyday
> knowledge and then analysing it is a different kettle of fish. (08)
I strongly agree. Those are toy examples. Any methodology based
on toy examples sprinkled with philosophical jargon is worthless for
any practical application. (09)
WF
> I have found that software designers always just throw away what
> does not fit their tools, 'hard coding' the rest. (010)
Yes. The field of ontology desperately needs tools that can be used
to build complete applications. There were AI projects in the 1990s
that were successfully used to build applications, but the later tools
were a step backwards -- primarily because the developers ignored the
requirements of mainstream IT. (011)
MW
> Requirements are rarely adequately specified, so without a good
> framework to help you fill in the missing bits, you are not likely
> to be very successful in translating English into FOL that will
> stand the test of time. (012)
I agree. That is the challenge: develop a framework that can
support industrial-strength application development. (013)
MW
> So particulars can be universals then when you use the term. I had in
> mind the definition in Wikipedia: "In philosophy, particulars are concrete
> entities existing in space and time as opposed to abstractions." (014)
Delete the word 'particular'. Use words from the application domain,
the KR language in which the ontology is implemented, and the computer
system that the application will run on. (015)
MW
> Yes, and logic is not much help in that as a framework for analysis.
> Great for stating the results once you've got them, but not for the
> analysis itself. (016)
I agree. My recommendation for the analysis is to adopt, extend, and
refine the methods that systems analysts have been using for decades.
Whenever possible, use terminology that they already know. (017)
JFS
>> Ontology is over two millennia old. For implementing ontologies,
>> we've had FOL for over 130 years. (018)
MW
> Neither of those facts makes ontology mature. You know an area of study
> is mature when people have stopped arguing about it, and moved on to
> other topics. (019)
Yes. That's my point: stop using terminology that even philosophers
continue to argue about. Use terminology that is well established
in systems analysis. (020)
MW
> That there is vague jargon and that students are confused is precisely
> an indication of immaturity. (021)
I agree. Throw out words that are confused and confusing. (022)
JFS
>> Just teach students how to translate English spec's to FOL. (023)
MW
> But only after you've taught them how to analyse those specs to find
> what's missing, for example using an upper ontology with patterns
> that help you to fill in the blanks. (024)
I strongly agree. Those patterns are far more important than any
philosophical jargon. The kdptut.pdf tutorial comes from the first
chapter of a book I'm writing. That was a 3-hour tutorial I presented
last June. In March, I'm expanding that to a 10-hour tutorial that
I'll present in Malaysia. All of it will come from or go into the book. (025)
JFS
>> For interoperability, you do not need agreement at the top level, which
>> is only "a framework for focusing the discussion." (026)
MW
> It is a lot more than that. Especially when the mid-level ontology is
> being developed by a large team (tens to hundreds). (027)
I strongly agree. But your example is more detailed than the mid-level.
As an example of the mid-level, I was thinking about the Amazon.com
database schema, which every vendor that wants to sell anything
through Amazon must adapt to. The terms in that schema are defined
at the level of Schema.org or the GoodRelations ontology. (028)
MW
> When you have a team approach you need to have a development paradigm
> that consists of commitments, rules, and choices that as far as possible,
> and this is what the upper ontology needs to provide. It defines the
> paradigm so that the mid and lower level ontologies are developed
> consistently. (029)
Now you are talking about specifying a large application. That is the
level of detail that systems analysts have been working on for the
past half century. That is a mature community that has a great deal
more experience about how to design a system than most people who
claim to be ontologists. (030)
The primary reason why mainstream IT ignores ontology is that the
professional systems analysts and developers know a lot more about
designing applications than the ontologists can teach them. The
terminology about systems design and development is what ontologists
should learn and use -- not some half-baked terms they picked out of
a philosophy book. (031)
John (032)
_________________________________________________________________
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 (033)
|