Leo,
Yes, I suppose what I am talking about is “conceptual models”, BUT “conceptual models that are stated in a language that has a formal logic interpretation,
such that the models enable inferences.”
Now, if other participants restrict the term “ontology” to “attempts to model objective reality”, fine, but frankly, I think that is a purely philosophical
task. It is my personal philosophy that “objective reality” is unknowable and therefore cannot be modeled. It is possible to model theories of reality, but we have to accept that they are theories. What most of us model is “commonly perceived reality”,
and the only question is which stakeholders are involved in determining what is “common perception”.
Yes, it is a terribly pragmatic viewpoint. As I said, I’m an engineer. I make “ontologies” to solve particular problems. A statement only has to be true
of all the things the stakeholders want to talk jointly about. It is this problem-specific restriction of the universe of discourse that makes the pragmatic ontologies useful. (And it is often the only possible basis for reconciling some participant views.)
David Price is right that the modeler (knowledge engineer) brings his own perspectives into the process of creating the ontology. But it is a bit like practicing
law – your job is to represent the clients’ views, and restrict your contribution to how best to perform that representation. Knowledge of unifying theories is useful in finding ways to reconcile views, yes. But at the same time, you don’t want to *force*
view pegs into theoretical holes. You want rather to import a theory that provides holes in which the view pegs comfortably fit.
I have watched too many failures of engineering activities that were based on forcing an untested theory onto an industrial knowledge engineering problem.
It is bad enough that the ontology languages are often insufficiently expressive to capture some aspects of the real stakeholder intent, without further impeding their use by demanding adherence to a theory that has not been proven to apply to the case(s)
at hand. YRMV.
-Ed
P.S. After many years, I have concluded that the real problem with knowledge engineering is that the discipline requires insight, wisdom, and serendipity,
and you can’t teach any of those. And somehow when we teach students how to use a particular set of resources and approaches, we have to ensure that they don’t come to believe that what they have been taught was “divinely revealed”, because that seems to
be a predilection.
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Obrst, Leo J.
Sent: Wednesday, July 1, 2015 3:02 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Is Philosophy Useful in Software Engineering Ontologies?
I think Ed is primarily talking about a conceptual model (conceptual schema). Local semantics are certainly important for these, and may contravene objective
(realist) reality. This is why I think the latter, and ontologies (which support/represent that), is such a useful advance over the former.
Thanks,
Leo
Ed,
Not sure this is going to get us far, but I still cannot make much sense of "But the point is that none of it is about objective reality or objective truth.
It is about the world as seen by the people and software that have to communicate." Don't we see/sense the same world?
I think maybe we are talking about different senses of "objective reality or objective truth". My notion of objective reality is that some kind of fit
between world and words is needed to get words to do what they are meant to do. If a stakeholder says she is talking about a particular widget, in most cases, the ontologist has the option of going with them to see it and checking they are talking of the same
thing. And in the cases, where there is a lack of clarity, this may be the best option. Are you expecting something more? And how does someone check things if they do not have this as an option?
On 24 June 2015 at 18:10, Edward Barkmeyer <ebarkmeyer@xxxxxxxxxxxx> wrote:
Chris,
Most or all of what you say is true, but it wasn’t my point. Of course, getting a model that all
or even most of the stakeholders can work with is a major effort. The knowledge engineer writes down what was said, asks questions, eliminates misstatements and attempts to align statements from other experts, identifies contradictions, asks more questions,
and so on. All part of the job. But the point is that none of it is about objective reality or objective truth. It is about the world as seen by the people and software that have to communicate. If there are aspects that they can’t agree on, there will
necessarily be a corresponding area of mutual interest for which communication will be difficult – if the areas of disagreement are critical, the purpose of the engineering project may not be fulfilled!
What they all agree on can sometimes be contradicted by your own observations, yes. “there
is a reasonably obvious way the system can fail to work - that seems to be based upon a belief-independent world”. No, it isn’t. What is “reasonably obvious” to you might not be either obvious, or even relevant, for reasons you may not understand.
As Aldous Huxley said of Pope’s “a little knowledge is a dangerous thing”, “who is so rich in that commodity as to be out of danger?” The best the knowledge engineer can do is ask the proper pointed question, and heed the answer(s).
“X cannot happen because A will do Y, which prevents it.
Question: A WILL do Y or A SHOULD do Y?
Oh! Well, A is REQUIRED to do Y. If s/he doesn’t, X isn’t the only thing that will happen.
Or: Well, A should. I suppose we could consider what to do if s/he doesn’t.”
Just part of the job. The problem is only to capture their “possible worlds”.
-Ed
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Chris Partridge
Sent: Tuesday, June 23, 2015 2:21 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Is Philosophy Useful in Software Engineering Ontologies?
"Whether the reconciled views have anything to do with “objective reality” is irrelevant, as is epistemology
and ethics. We are not interested in what is true, or what is real, or what is good, we are only interested in capturing the common beliefs of the stakeholders, or just enough of what each believes to make it possible for them to communicate and determine
certain consequences."
I have a very different picture, based upon practice. In general, the experts I meet are obviously really experts, but seem not to have (or have access to) formal models of their
expertise - ditto stakeholders - and, of course, I am not alone in this. And it seems to be in the nature of expertise/stakeholding to hold different views on what exists. The old joke about economists seems to hold of experts when you try to tie down their
expertise - put 4 experts in a room and you get 5 opinions.
Another way of expressing this is to say that one should always take the first version of a users' requirements with a pinch of skepticism. I remember a graduate student telling
me a while ago that some statement must be true as the expert has told them so - apparently this was the approach they had been taught at school. I was a little shocked so, over the years, I have asked fellow system builders what their view was. I have yet
to meet one who would not critically review what the experts/users said, and assume that it is probably seriously wrong in a number of ways.
It is also worth bearing mind that whether the system is for an aircraft or an ATM that there is a reasonably obvious way the system can fail to work - that seems to be based upon
a belief-independent world. If you came across a crashed aircraft, would you take seriously an 'expert' view that said it has not crashed because some stakeholder believes it would not crash in these circumstances? There are many cases of clear 'world-to-word'
fit. In this situation, it helps to have some kind of approach that can arbitrate between the world and the variety of views. And objective reality, in so far as you can grasp it, can and does play this role reasonably well.
(PS I also disagree with your view on philosophy, but that would take more debate.)
On 23 June 2015 at 17:58, Edward Barkmeyer <ebarkmeyer@xxxxxxxxxxxx> wrote:
David,
You wrote:
“If you’ve not found Philosophy useful when creating ontologies, what exactly is it that you
think you are doing? All I can imagine is that some folks are just encoding "old style" models of data structures using ontology languages. If instead they are trying to model reality, then they are using Philosophy every day and just don’t know it.”
What I do (and I am hardly alone) is make models that are useful to a purpose. The value of ontology
languages for making those models is that they are based on formal logic, so that the models are formulations of the problem space in a formal logic language. Such a language in turn supports reliable inferences and reliable transformations. The models we
make, like your Oil & Gas models, are there to reconcile the views of multiple stakeholders, and to allow them and their software to communicate effectively.
Whether the reconciled views have anything to do with “objective reality” is irrelevant, as is epistemology
and ethics. We are not interested in what is true, or what is real, or what is good, we are only interested in capturing the common beliefs of the stakeholders, or just enough of what each believes to make it possible for them to communicate and determine
certain consequences. We can model creationism and climate change denial, if that is what is needed for the stakeholders to communicate. We model possible worlds, and we make inferences in those worlds. The logic basis of ontologies enables those inferences.
We don’t care whether any of those possible worlds coincides with “reality”. We rely on logical contradictions and the bitter experiences of stakeholders to identify impossible worlds and deleterious departures from reality.
The other “philosophical” (or “logical”) skill that we use is
abstraction – the ability to identify the common properties of a bunch of examples, and tease out the stakeholders’ classification rules. But the abstraction is bottom-up, based on the problem at hand. It is influenced by the modeler’s way of approaching
classification, which may be based on some background philosophical commitments that probably are not based on deep thought.
As Pat Hayes once observed about upper ontologies: You model the problem space at hand, and then
you look to see if some upper ontology provides useful abstractions for that space, so you can copy those axioms instead of re-developing them.
I have always said that I am a knowledge engineer, not a logician, and not a philosopher. And I
have an engineer’s view of computational ontologies – they are artifacts of software engineering that are supported by formal mathematical logic. And frankly, I find that many philosophical and other “religious” commitments are primarily obstructions to intelligent
engineering (notably in two communities you and I have both worked in).
-Ed
Edward J. Barkmeyer
Thematix Partners
Email:
ebarkmeyer@xxxxxxxxxxxx
Phone:
+1 240-672-5800
As a practitioner building ontologies every day, it is surprising to find that this is a question being asked in 2015 on this forum. Perhaps philosophy’s impact on modeling is now
so ingrained and widespread that people have forgotten the what it was like in the past when many (I’d actually say most) people were only really concerned with modeling data structures that were not representations of reality. I remember “modeling” overlaid
Fortran data structures in the same memory location early in my career.
-
a branch of metaphysics concerned with the nature and relations of being
-
a particular theory about the nature of being or the kinds of things that have existence
and it is obvious that this much improved perspective wrt how do to good modeling is now widespread.
At the technical level, metaphysics has certainly been a major factor in the decisions made in the development of upper ontologies - so if you’re using an upper ontology you’re
using a specific philosophy wrt the nature and relations of being (and in particular change over time). I work in lots of different industries but in three large ontology-based apps in Oil and Gas we use ISO 15926 which is an ontology based in 4-dimensionalism.
In the Defence industry, I am aware of IDEAS [1] that is also using 4-dimensionalism.
Even if you don’t go to the rigour of using something like 4-dimensionalism, good ontologists question the nature of the things in their models using the same analysis approach
used by philosophers for millennia. Returning again to Merriam-Webster I think the most relevant of the various definitions of Philosophy is :
-
a discipline comprising as its core
logic, aesthetics, ethics,
metaphysics, and epistemology
So I suggest that the question should be rephrase as follows: If you’ve not found Philosophy useful when creating ontologies, what exactly is it that you think you are doing? All
I can imagine is that some folks are just encoding "old style" models of data structures using ontology languages. If instead they are trying to model reality, then they are using Philosophy every day and just don’t know it.
While I absorb many good and deep observations from people with knowledge, is the viewpoint given below relevant to this thread? John did touch it a bit.
-
Why use a word Ontology that has origin in philosophy - for IT or software engineering if it is not relevant?
-
Can semantics be devoid of ontology context / vice versa?
-
As discussed in this thread we describe real, model, physically measurable and repeatable science and engineering concepts (things) as these relate to basic philosophy concept "Ontology" using logic, language, programming and IT tools?
-
An example: software engineering became much more sturdy with inputs from business users rather than old software modules approaches of Mainframe era where the results from programmers were robust but did not accurately depict the business processes because
they did not understand fully the process they were modeling and had other technology limitations of that era.
-
Would all this not make a case for at least a few to understand both worlds "ontology" with philosophy and "ontology" with IT / software solutions?
On Mon, Jun 22, 2015 at 12:52 PM, Azamat Abdoullaev <ontopaedia@xxxxxxxxx> wrote:
On Mon, Jun 22, 2015 at 10:44 PM, Azamat Abdoullaev <ontopaedia@xxxxxxxxx> wrote:
That is a good topic to discuss, Thomas.
Here is the content I recently uploaded online:
On Sun, Jun 21, 2015 at 8:18 PM, Thomas Johnston <tmj44p@xxxxxxx> wrote:
I think starting a new thread was a good idea, but I hope it's not just you and I who will contribute to it.
I'm glad you posed this explicit question. A great deal of philosophical discussion has been going on in Ontolog since I joined a few months ago. I think that many of those discussions have illustrated the
value of thinking philosophically. What I am recalling are discussions where something is said, and then where I, or someone else, points out that what was said didn't clearly distinguish between A and B, where (i) A and B are different interpretations of
what was said, and (ii) have been themselves recognized, at least by philosophers :-) , as being important distinctions, ones that lead to important different positions on issues such as what concepts are, how language relates to the world, what it means to
say that something exists, and so on.
But your question, I think, would be “So what? Why does an ontology engineering, building software to help us clarify a set of concepts for a particular subject matter, need to know any of that stuff?” At least,
that's the question I've set myself to answer. And you've put the shoe on the other foot, with your Socratic questioning. Socrates pissed people off by engaging them in conversation about something they thought they knew about, and showing them that they really
didn't it understand at all.
I hope I can do better. And I hope you won't let me get away with any sleights of hand.
Some ontologists work top-down, starting with really big concepts like Thing, Property, Relationship, Space, Time, Process, Event, Society and so on. These constitute an upper-level ontology. Cyc has one (that
I don't know much about); DOLCE has/is another (that I do know a little more about).
What's the value of that? Well, I'd say it's like the value that an enterprise data model (EDM) has for an enterprise. Over time, different databases in an enterprise, and the apps that maintain and query them,
develop in considerable isolation from one another. Seldom can an extract from database D1 be shipped over to database D1 and directly loaded into D2. Let alone differences in naming, a program is usually needed to map D1's data onto D2's set of tables and
columns, and that mapping is almost never 1:1.
These are the data stovepipes that all enterprises have. But if these databases could be modified so each one was a special case of a single EDM, then the mappings in data exchanges would get closer and closer
to 1:1. In other words, we would be getting closer and closer to meaning the same thing by X, Y, Z (e.g. “customer”, “product”, “restocking-event”, etc.) across all our databases. And if we shared an EDM with other enterprises that we exchange data with, then
we would all be converging on meaning the same thing by our shared concepts, concepts expressed as tables and columns in databases.
Working IT guys (of whom I used to be one) would call this eliminating stovepipes. Ontology engineers, so far as I understand, would call this establishing semantic interoperability across all those databases.
So an EDM is like an upper-level ontology in this way. And there is another parallel. The different databases, D1, D2 and so on, in an enterprise have different tables and columns, since each supports a different
subject area. How do these tables and columns relate to the EDM of that enterprise?
Basically, the relationship is that these database-specific tables and columns should either be enlargements of the tables and columns in the EDM, or extensions of those tables and columns. By “enlargements”,
I mean that specific databases would add specific additional columns to their copies of those EDM tables. By “extensions”, I mean that all tables specific to a database would be implemented as subtype tables of tables already defined in the EDM.
Of course, projects to do this never happen, because an enterprise just doesn't see the value of all that work. EDMs are often built, but the re-engineering needed to make specific database conform to it never
happens. What sometimes does happen is that far-sighted data modelers attempt to shoe-horn in EDM conformance work with the end-user-visible paying work of specific projects.
So as a first cut, the value of an upper-level ontology is like the value of an EDM. But since real EDMs seldom get as general as upper-level ontologies, I suggest we see the value of having and using (or at
least consulting) an upper-level ontology as eliminating stovepipe problems across different EDMs.
Later on, I'll try to give some concrete examples of interoperability problems that an upper-level ontology could help us avoid. But for right now, I want to shift to the bottom-up perspective. When we get
right down to Customer tables, Employee tables, Job Requisition tables, Inventory Fact Tables and Product Hierarchy Dimension tables, and so on, how does philosophy help?
Nearly everybody has a Customer table, so I'll use that as an example.
A customer is someone who purchases goods and/or services from us.
Is a customer always an individual person? If so, can anyone qualify as a customer? Or only adults legally competent to enter into financial relationships? Or only adults with a credit score over 600?
If not, what kinds of groups can qualify as customers? Does a group have to have a tax-id number to qualify? Or can the Ladies' Sewing Circle open a customer account with the Fabric Mega Warehouse company?
Under what circumstances will we (the enterprise) drop someone as a customer? When we turn their balance over to a Collections agency? And when do we do that (i.e. what are the criteria for doing that)?
Can someone be enrolled as a customer (have a row in our Customer table created for them) prior to their making an initial purchase from us? If so, what triggers their becoming a customer? Is it filling out
an application? Or is it earlier in the relationship, for example when they first respond to any marketing material we may have issued?
The answers to all these questions usually are documented somewhere within the enterprise. Where is that? It's in the policies and procedures manuals of the enterprise. Somewhere in the enterprise, at some
point in time, someone does something that culminates in a new row being added to the Customer table (or a row being removed). The input to that initial action was some kind of request for the action to be performed. The person involved must consult enterprise
rules in deciding whether or not to proceed with that action. (Or have those rules in his head.)
Often, those rules are part of the work-a-day awareness of very low-level employees. Often, the supposed “subject matter experts” who are sometimes consulted if IT decides to create a data dictionary for a
new database, don't know all those specific rules. In which case, consulting those SMEs produces results like “A customer is someone who buys something from us”.
A philosopher is someone who knows that these rules exist, or should exist. A philosopher is someone who will ask the questions that will bring out these rules (or their absence).
It doesn't require a PhD. But it does require an awareness that I have very seldom found in working business analysts, data modelers and DBAs.
So here is a semantic interoperability problem which could have been avoided if precise definitions had been used. Our enterprise has two divisions, Div1 and Div2. The CEO wants to know which division has the
most customers.
Each division has a Customer table, so each one runs a SQL Count query on its table. The results are: Div1 has 3,240 customers and Div2 has 5,882 customers. The CEO tells the VP of Div1 that she isn't doing
a very good job, and needs to add another two-thousand customers within the next year. The VP, of course, spreads panic within her division. After all, it's a VP-level bonus that's at stake!
She begins by dropping the credit score requirement. This will certainly mean that her A/R unpaid balances will go up, and that her collection agency will be getting more business. But the CEO want more customers,
and so more customers he will get.
It also turns out that Div2 counts as a customer anyone who has responded to Div2 marketing material. In Div1, there is a separate Prospects table to keep track of those contacts. In other words, in Div1, prospects
and customers are different kinds of things, whereas they are not in Div2.
These are specifically ontological decisions. In Div2, then, the change from a party being a prospect to being a full-fledged customer is a matter of the date-of-first-purchase column being or not being null.
In Div1, the change is a matter of one thing – a prospect – being removed from the database and another thing – a customer – being added. Aristotle called this difference the difference between accidental change and essential change.
Well, being ontologically informed, the VP of Div1 decides to remove her ontological commitment to prospects. >From then on, she directs her staff, what they were calling “prospects” will be called “prospective
customers”, and what are currently called “customers” will be called “purchasing customers”.
A merely “verbal” matter? Not at all. A prospective customer is now a customer. This automatically added 800 new customers to Div1 – even though nothing in the real world changed! And whereas Div1 had turned
away 300 customer applications last year because of low credit scores, that won't happen from now on. So the Div1 VP can now anticipate an additional 300 or so customers in the coming year, assuming that application rates remain the same.
It also turns out that Div2 has the policy that a customer would not be purged from the Customer table because of inactivity until ten years had passed since the last purchase. Div1 had a policy of purging
customers who had been inactive for only five years. So naturally, Div1's VP immediately changed their policy to leave inactive customers in the Customer table until ten years had passed without a purchase.
By the end of the year, the customer gap between Div1 and Div2 had narrowed considerably. The VP of Div1 got her bonus after all.
I said above that the VP of Div1 was “ontologically informed”. But, of course, she really didn't need any philosophy at all. She knew exactly what to do without consulting Aristotle or Ockham.
So where's the value of philosophy in this story?
The value is in what could have been done. With an EDM whose tables were defined with as much precision as indicated above for customers, and with a policy of EDM conformance across all divisions of the company,
these policy issues – that the VP of Div1 most likely didn't even know about until her bonus became at risk – would have been explicitly considered, explicitly formulated, and implemented in the decisions about when to add a row to a Customer table and when
to delete a row from a Customer table. With these issues already decided, the customer counts in the two divisions would be comparable. With these issues decided, the two database queries would indeed be comparing apples to apples.
OK, but all of that could be done by intelligent and skilled business analysts, data modelers and DBAs. How about the new ontology engineer the company just hired? Does she have anything to contribute?
Indeed she does. Notice that in this panic-driven process of conceptual clarification, in Div1, it was people doing everything. People in Div2 comparing their policies for adding and removing customers, their
policies for distinguishing between customers and those non-customers they called prospects.
A really important thing would be to enable software to discover these differences, and when doing cross-database queries, to point out those differences in the result sets returned. For this to happen, each
of these policies, in each division, would have to be written down in some kind of formal language. For that to work, each of the key differentiators would have to be documented as a separate concept. A substantial set of concepts would quickly develop, just
to manage an ontology for customers.
Now software doesn't understand anything. But just as logic theorem provers can be relied on to generate only true statements from an initial set of true statements – purely by mechanical means – so too semantic
parsers, as I will call them, can do the same thing in the case of this example.
The parser would first do the two customer counts. It would then examine the formally-expressed definitions for each division. It would find that “has responded to marketing material”, together with “legally
eligible to enter into financial relationships”, was sufficient to generate a row in Div2's Customer table. And that those same two conditions were sufficient to generate a row in Div1's Prospect table. A sophisticated parser would then add the Prospects count
to the result set, so that there were now two counts for Div1, and would also note that these counts were combined in the one count for Div2. It would discover, and note in the result set, the other differences I mentioned.
Take just the prospects vs. customers issue. The annotated result set would clearly tell the people looking at it exactly what was going on. Using Div2's definition of customer, the corresponding count for
Div1 would be the sum of its customer and prospect counts. Using Div1's definition of customer, all we can tell is that there many be any number of prospects included in the single count for Div2.
A really sophisticated parser would examine the definition for each of Div2's columns and, let's suppose, finds the column “first-purch-date”, and further discovers, by examining additional formally expressed
definitional parameters, that the column is null, in any row, if and only if the party corresponding to that row had not yet made an initial purchase.
Now, with this additional information, the parser could also give a Div1 interpretation of the results. Div1, remember, had two counts returned – prospects and customers. The parser can now return the same
two counts for Div1. The Prospects count is the count of all rows in the Customer table whose first purchase date is null. The Customers count is all the other rows.
Now we've seen that there are any number of criteria that differ across different definitions of “customer” used in different databases. So the qualifications, and the consequent different definitions of “customer”
that a semantic parser could distinguish might be considerable. But if this formally expressed ontology that the parser uses had been agreed-on to begin with, then ideally there would be no qualifications, and only one number returned for Div1 and one number
for Div 2.
Think of this “semantic parser” as a DBMS. It processes the SQL Count statement against both Customer tables; but, having access to all these formally-expressed distinctions, it can do all the neat things I've
described.
To conclude for now, I think I've illustrated a role for a philosopher (aka ontologist) and for an ontology engineer. The ontologist (I'm going to switch over to this term now, since it's the one involved in
our prior discussions) is the person in all this who is aware of all the distinctions that might be involved in defining what a customer is, according to Div1 and Div2. The ontology engineer is the person who uses those distinctions to build the formal apparatus
needed by the semantic parser.
The value of ontology is that it provides better material for the ontology engineer than he is likely to come up with based only on his own intuitions.
So here's a promissory note for a later comment in this thread. How can anyone, no matter how ontologically aware, be aware of ALL the distinctions that might be involved in defining what a customer is?
I think I actually have an answer to this question. There are hints of it in MTRD. It's a method I used during the last several years of my consulting career. If I ever get around to carefully writing it up,
I might even give it the exalted title of a “methodology”. However, it is not a mechanical way of coming up with high-quality definitions. There are no mechanical ways of coming up with definitions. But there are a set of heuristics that I have found to generate
much better definitions than the ones I used to produce, and better than anything else I ever found in the world of commercial IT.
Now please do your Socratic gadfly job, and point out what's unclear in all this, and what's inadequate in any other way (e.g. being just plain wrong).
Thanks for your ever analytical, thoughtful approach. I have changed the title from that old ugly thread to this bright new nondurant thread that states the issues in a more constructive light.
LO: Rich, have you ever wondered why there are only about 5-6 folks engaged here in Ontolog discussions? It’s because
most of us have written these interactions off, as wastes of time. If people are serious about this topic, it’s a real time drain. Why? Because the discussants are largely not serious about learning/understanding more: they simply want to argue their opinions.
I have to agree with you on that, Leo. I asked questions of each input, and with zero inputs from Patsy, and nearly zero explanations to my questions, it seems ineffective to continue.
So this is a new thread wherein Tom wants to support the position that philosophy has value to software engineering, while I take the platonic side and ask questions (chime in others with questions)
to reach an unemotional conclusion, possibly somewhere between the two poles.
Chief Technology Officer,
MetaSemantics Corporation
MetaSemantics AT EnglishLogicKernel DOT com
Perhaps I'll eventually come to the same conclusions as Leo has. Prior to that time, I will try, as best I can, to be a Socratic gadfly to the ontology engineers gathered in this forum.
Though it's a little unnerving to reflect on what Socrates' habits led him. Hopefully, the worst it will lead me to is perceived irrelevance to the work of "real" engineers -- among whom I do
not number myself.
Rich, have you ever wondered why there are only about 5-6 folks engaged here in Ontolog discussions? It’s because most of us have written these interactions off, as wastes of time. If people
are serious about this topic, it’s a real time drain. Why? Because the discussants are largely not serious about learning/understanding more: they simply want to argue their opinions.
Sorry, and I wish it was otherwise, believe me, as as I used to argue with Peter when he ruled the realm.
Software engineering provides you with very informal ontologies, that are actually embedded as interpretations by the programmer in the code. Try to get that out and reuse it. Once we have
very solid NL technologies that can do semantic interpretation and mappings to ontologies in specific domains and contexts, then … We won’t need you or me: way stations of limited understanding at best.
And how, exactly, does
philosophy provide understanding? So far in this thread, it hasn't provided a single concrete example.
Since Pat popped off with another stink bomb, I have yet to hear one single reason, one clear explanation of worth, as to why and how, specifically, can philosophy contribute one simple clear
thing to the endeavor of software engineering? Just a lot of one-offs.
Pat poops again, and returns to sleep without explaining. You respond below, again without explaining why
philosophy, of all things, has anything whatsoever to contribute to the endeavor of software engineering. There are already ontologies in each and every software system written today. Software engineering does require ontologies, but does not
require philosophy. And, it seems, philosophers on this list have not yet offered a single reason to the contrary.
Chief Technology Officer,
MetaSemantics Corporation
MetaSemantics AT EnglishLogicKernel DOT com
Yes, but the main result is that no one looks at the other side, and everyone expects the other side to provide them neat answers when needed. And then neither side understands those neat answers,
and so quibble, quibble forever. Understanding involves learning about both sides. This is not rocket science. We experience it every day when we map your database/ontology into mine, and vice versa. Interoperability requires understanding. If neither party
wants to understand the other side, then you do this seemingly infinite dance, which takes a LONG time.
If you think understanding something extraneous to your current situation and state of knowledge is important, you need to take the time to learn about it. There are no miracles, no divine statements
about why you should. Otherwise, you are a dilletante. Most of us are dilletantes in the areas we don’t think are imporant to us, or crucial for our real understanding.
LO: Of course it helps if ontology engineers/implementors acquire a deep understanding of philosophy,
RC: How exactly does "a deep understanding of philosophy" help engineers? That is certainly not obvious from the discussions here. Most of the software people have agreed on objects and events
as the basis of systems. The philosophers on the list keep debating about perdurants and endurants, and endless ways to split hairs that have nothing to do with the software structures required by serious applications.
So please, describe why you think "a deep understanding of philosophy" can help engineers?
LO: and if philosphers acquire a deep understanding/practice of ontology engineers/implementors.
RC: Unless philosophers can somehow produce a payoff, a value as seen by the said engineers, what good are they to the engineers?
Dilletantes on either side obscure the issues of both, and spend their time on endless argumentation.
So far that seems to have been the progress of this thread.
Chief Technology Officer,
MetaSemantics Corporation
MetaSemantics AT EnglishLogicKernel DOT com
Of course it helps if ontology engineers/implementors acquire a deep understanding of philosophy, and if philosphers acquire a deep understanding/practice of ontology engineers/implementors.
Dilletantes on either side obscure the issues of both, and spend their time on endless argumentation.
>-----Original Message-----
>Sent: Friday, June 19, 2015 1:31 PM
>Subject: Re: [ontolog-forum] Ontologies and languages
>I completely agree with you:
>> What the history of Philosophy, and especially of ontology, shows us
>> is that important philosophers have not failed at the winnowing task,
>> but simply worked hard and carefully to -- with apologies for the
>> shift of metaphor -- slice the ontological pie in different ways.
>I would *never* try to stifle philosophical debate. That is absolutely
>essential for clarifying the issues and deciding what to represent, how
>to represent it, and what to do with the results.
>But everything that can be implemented on a digital computer can be
>expressed in first-order logic. Some extensions to FOL for supporting
>metalanguage and quantifying over relations and functions can simplify
>and clarify the mapping.
>What we have today is a huge amount of words taken out of context from
>the vast literature of philosophy and used to decorate the formal
>notations. It's OK to put some of those words (with citations to the
>original context) in the comments.
>But the meaning of the formalism is precisely defined by the model
>theory. None of the philosophical subtleties survive the translation
>from the original context into the software.
>When you use philosophical words to decorate the formal language, they
>are *worse* than useless because they confuse *everybody*:
> 1. The overwhelming majority of the programmers don't understand
> the philosophical issues. For them, those mysterious words
> may have some hidden meaning. So they carefully preserve them.
> 2. If those mysterious words weren't present, the programmers
> would examine the software to see exactly what is going on.
> But they have a vague feeling that those words have some
> deep power that goes beyond what is in the executable code.
> 3. For the philosophers who don't understand the software,
> they may have a comfy feeling that their ideas have somehow
> filtered down into the implementation. If so, they are
> even more confused than the programmers.
> 4. The result is a total breakdown in communication between
> the philosophers and the people who develop and use the
> software that is supposed to be based on the philosophy.
>My recommendation (copy below) is to force both sides to face the fact
>that digital computers are limited to FOL (or modest variations of
>FOL). Any terms that don't have a precisely defined mapping to FOL
>can't have any useful effect on any implementation -- but they can
>create a lot of confusion.
>Therefore, the philosophers and the implementers must agree on a simple
>terminology that *both* sides understand and that has a precisely
>defined mapping to what the computer does.
>______________________________________________________________
>As a general strategy, I would recommend:
> 1. A formal logic with the barest *minimum* amount of terminology.
> It must at least contain FOL + the option of quantifying over
> functions and relations + the option of using metalanguage for
> talking about whatever languages are being defined.
> 2. A huge *purging* of the immense philosophical terminology
> to a minimal set that is formally defined in the logic of #1.
> 3. The option of designing an open-ended family of formal notations,
> linear and/or graphic, that have a precise mapping to #1 and #2.
> 4. There may be huge debates about how to map NL terminology
> (including any and all terms in philosophy, science, business,
> the arts, etc., to the terms in point #2). But any proposed
> solution must be defined in the logic and minimal terminology of
> points #1 and #2 (or #3, which is defined in terms of #1 and #2).
>_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
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
_________________________________________________________________
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
--
_________________________________________________________________
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
_________________________________________________________________
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
_________________________________________________________________
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
|
_________________________________________________________________
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 (01)
|