Re: [ontolog-forum] Is Philosophy Useful in Software Engineering Ontolog

[Thomas Johnston <tmj44p@xxxxxxx>]

enough typos in the original to possibly be misleading. So here's the corrected version.

6/21/2015.

Rich,

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 engineer, 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 D2 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 databases 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.

What is a customer?

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 Prospect 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, uncovering their own policies and the policies in Div2, and comparing the policies for adding and removing customers, and policies for distinguishing between customers and 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 split out the Prospects count from the Customer count for Div1, 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 Div2. The Prospects count for Div2 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 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).

Regards,

Tom

On Sunday, June 21, 2015 1:18 PM, Thomas Johnston <tmj44p@xxxxxxx> wrote:

6/21/2015.

Rich,

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.

What is a customer?

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).

Regards,

Tom

On Saturday, June 20, 2015 7:20 PM, Rich Cooper <metasemantics@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Dear Tom,

 

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. 

 

Sincerely,

Rich Cooper,

Rich Cooper,

 

Chief Technology Officer,

MetaSemantics Corporation

MetaSemantics AT EnglishLogicKernel DOT com

( 9 4 9 ) 5 2 5-5 7 1 2

http://www.EnglishLogicKernel.com

 

From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Thomas Johnston
Sent: Saturday, June 20, 2015 3:40 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Ontologies and languages

 

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.

 

 

 

On Saturday, June 20, 2015 6:28 PM, "Obrst, Leo J." <lobrst@xxxxxxxxx> wrote:

 

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.

 

Thanks,

Leo

 

From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Obrst, Leo J.
Sent: Saturday, June 20, 2015 6:23 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Ontologies and languages

 

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.

 

 

From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Rich Cooper
Sent: Saturday, June 20, 2015 5:54 PM
To: '[ontolog-forum] '
Subject: Re: [ontolog-forum] Ontologies and languages

 

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.

 

Sincerely,

Rich Cooper,

Rich Cooper,

 

Chief Technology Officer,

MetaSemantics Corporation

MetaSemantics AT EnglishLogicKernel DOT com

( 9 4 9 ) 5 2 5-5 7 1 2

http://www.EnglishLogicKernel.com

 

From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Obrst, Leo J.
Sent: Saturday, June 20, 2015 2:14 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Ontologies and languages

 

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.

 

Thanks,

Leo

 

From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Rich Cooper
Sent: Saturday, June 20, 2015 1:34 PM
To: '[ontolog-forum] '
Subject: Re: [ontolog-forum] Ontologies and languages

 

Dear Leo,

 

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. 

 

Sincerely,

Rich Cooper,

Rich Cooper,

 

Chief Technology Officer,

MetaSemantics Corporation

MetaSemantics AT EnglishLogicKernel DOT com

( 9 4 9 ) 5 2 5-5 7 1 2

http://www.EnglishLogicKernel.com

 

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Obrst, Leo J.
Sent: Saturday, June 20, 2015 10:17 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Ontologies and languages

 

John,

 

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.

 

Thanks,

Leo

 

>-----Original Message-----

>From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-

>bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F Sowa

>Sent: Friday, June 19, 2015 1:31 PM

>To: ontolog-forum@xxxxxxxxxxxxxxxx

>Subject: Re: [ontolog-forum] Ontologies and languages

>  

>Tom,

>  

>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.

>  

>John

>______________________________________________________________

>  

>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    (01)