ontolog-forum
[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

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

from [Ravi Sharma] [Permanent Link][Original]
To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ravi Sharma <drravisharma@xxxxxxxxx>
Date: Thu, 25 Jun 2015 15:07:29 -0700
Message-id: <CAAN3-5cLqNTROccafpuRV_aNk0FDp1Utzrzjf+T6EcLGVBkHmg@xxxxxxxxxxxxxx>
Ed
Just wonderful and yes you are an excellent engineer but also a philosopher - from what you wrote.

Jokingly:
Einstein and those before him (seers of time- Kala Darshi) got us in trouble by having time as arrow and for some others for having time as a wheel (cyclic).

Just as when we were talking of reality and models a few weeks back, I mentioned that universe objects sending light that impinges on retina at a given epoch (time) but originates at different epochs (times), therefore what is real? Also what is real and where? On the other end of optic chiasma in neural network or at the retina or in the sense of real model of events / sky in the brain?

Your narration beautifully describes a detailed and professional process you use to get some useful end result from activities such as standards development, I participated with you in date-time effort and realized depths of math used by our group relating to Date-Time SBVR OMG effort.

It really is the time -nature and type - and context that also is central to Date-Time Vocabularies and synchronization of time in world event context - and different calendar systems for business use - was a challenge and automation software is another challenge.

Therefore, what is the time used in 4D -  3 for space and 1 for time - but which "time" from those described by you or different relevant time as parameters depending on the object (thing) being addressed?

Theoretically general relativity does imply a consistent Tensor representation where time is one of the multidimensional element.

Regards,



On Wed, Jun 24, 2015 at 10:20 PM, Edward Barkmeyer <ebarkmeyer@xxxxxxxxxxxx> wrote:

David,

 

“Every ontologist left to their own devices thinks differently and so if several work in an enterprise with no agreed comments/guidelines then you just add yet-another-project to re-model what has already been modelled twice. Using an agreed philosophy helps ameliorate that problem - solve a problem once, and only once and plan on reuse across apps, disciplines, etc. from the start.”

 

And put a systems engineering team in place to enforce the guidelines and ensure the cross-app and cross-discipline consistency of the models.  And then maybe you can maintain the enterprise models for a while before the changes in the enterprise force remodeling of various sectors.

 

The only way to get a consistent set of models across an enterprise is to have a team that works together to maintain consistency.  It is, after all, a “systems engineering project.” Starting with an abstraction 2-3 levels removed from anything of business interest does not maintain consistency of any overlapping business concepts.  And it does not provide much guidance to the team.

 

Suppose we all agree to model all relationships as temporal parts of the participating individuals.  Wonderful, what does that do to get consistent understanding of any given relationship?  My complaint about 15926 is not 4D.  It is ideas like “a product design is a class and some temporal parts of a physical object are instances of that class and others are not.”  The problem is then that those parts that are worn and no longer instances of the class are *unrelated* to the design, which loses an idea we need to capture!  And OBTW, our high-level model only really has about 8 relationship verbs, so ‘is made of’ becomes ‘is a subclass of’, because it was the nearest choice among the 8.  Such rigor constricts the modeler without providing real benefit.

 

“I have first hand experience with how a “no commitments” approach  results in silos of ontologies that are hard to make interoperable.”

 

We both have experience with the enforcement of a set of high-level abstractions and rigorous methods that have made the model specifications 3 times the required size, have made information exchange using the models cumbersome and hard to interpret, and have proved to lead to non-interoperable models when this same rigor is applied by different modelers in communities with somewhat different views.  So it ain’t about commitments; it is about getting consistent understanding of the problem space.

 

The only way to get consistent models is to get the modelers to work together!  I have seen no evidence that paying homage to a common set of abstractions and principles leads to interoperability or consistency.  

 

I have seen much hand-wringing about whether to model subclasses that have no modeled properties as subclasses or just individual values of a property.  Oh, it is “more interoperable” to model them as subclasses, but only if the model you have to interoperate with (sight unseen) models the same subclasses (by definition) and supplies properties that your community would agree with.  In fact, the individual values may just be naming versions of a fuzzy property that someone thinks ought to be a mechanism of classification.  Or they might actually be individuals in a class managed by a related ontology, so that what you think is an “instance of” relationship is viewed by that community as a kind of association.  In short, unless you know what the interoperability requirement is, the principle is an arbitrary choice.

 

“does that really mean that you don’t follow *any* agreed philosophy or make any commitments wrt approach when doing knowledge engineering?”

 

Well, I have spent many years (c. 50)  learning knowledge engineering by doing.  I have never tried to teach it, which would probably make me aware of what my “principles” are.  But I always do it bottom-up, starting with mind maps of what the experts wrote and said.  And then I ask a bunch of questions to clarify terms and fuzzy stuff in the mind map.  And I then try to organize what I have absorbed using a small set of conceptual modeling tools:  E-R a la Nijssen, subsumption, cardinality rules, and the like.  Then I can go back and ask much more pointed questions, and try out axioms on the domain experts.  My “philosophy” is the expressiveness of my toolkit, which has improved little by little over the years.  As I said, I am an engineer. 

 

I have worked on teams in which the high-level principles were agreed on by one or two people who managed the teams, and the rest of us worked around the bad ideas to get something close to useful (e.g., SC4).  I have also worked on teams of very bright people who somehow came to insightful understandings that made it all work (Remote Database Access, OAGIS).  And I have worked on teams that were hopelessly bogged down by heated debates among the ignorant (<expunged>).  Maybe the “insightful understandings” resulted from acceptance of a common philosophical approach.  And maybe the characterization “ignorant” just means “having a philosophy I reject”.  I wouldn’t know.  I don’t think of success being related to philosophical commitments.  It is rather about agreeing to see a certain important thing in a particular light and repeating that experience with a handful of things, each a special case, that make the overall effort come together.

 

Favorite tale:  A colleague, one Stan Hendryx, observed in a meeting that “the first of the month is really a class of time periods,” and that insight created a model for calendars that is cross-cultural.  Perhaps someone else can say what philosophical principle he applied. ;-)

 

-Ed

 

 

 

From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Price
Sent: Tuesday, June 23, 2015 3:45 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Is Philosophy Useful in Software Engineering Ontologies?

 

Following up after what Chris said ...

 

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.

 

… and this is where my problem with this perspective lies. Every ontologist left to their own devices thinks differently and so if several work in an enterprise with no agreed comments/guidelines then you just add yet-another-project to re-model what has already been modelled twice. Using an agreed philosophy helps ameliorate that problem - solve a problem once, and only once and plan on reuse across apps, disciplines, etc. from the start. See below for how that affects organizations.

 

I have always said that I am a knowledge engineer, not a logician, and not a philosopher.  

 

Neither am I, but that is not what I said. You don’t have to be a philosopher to admit that philosophy has been useful in your work and to the community of knowledge engineers - and that’s all I’ve said.

 

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

 

Understand you don’t always like consequences of 4-dimensionalism - that’s fine.  However, does that really mean that you don’t follow *any* agreed philosophy or make any commitments wrt approach when doing knowledge engineering? Do you you therefore recommend others not do so either?

 

I have first hand experience with how a “no commitments” approach  results in silos of ontologies that are hard to make interoperable. I’ve got a customer now who has hired a variety of consultants as knowledge engineers over the past few years and provided them with zero guidance. Unsurprisingly, you would not want to use the word “engineering” anywhere near the result that has produced. It’s highly likely they’ll have to bring in more hired knowledge engineers to clean up the mess left by the first bunch - all because they did not make any commitments up front. I’ve even suggested they create what you might call an "ontology harmonisation team" which has as one of its roles to enforce those commitments (Ed, I’m sure you’ll remember when we had to create the STEP harmonisation team after producing a suite of non-interoperable APs … history repeating itself, still no lessons learned 20 years later).

 

If you really are serious about this non-commitment view, then we’ll just have to disagree wrt how a good knowledge engineer should go about their job. As I mentioned, I recommend exactly the opposite to customers interested in ontology development or when doing training in large enterprises. I’m not religious about the specific commitments themselves, only religious that there be some, that they have a sound philosophy underpinning them and that they are followed. I’ve never really had any push-back on this point either because if you take the time to explain this, talk about the experiences where that a lack of such agreement ends up wasting time and money in the long term, then organizations recognize the value. It’s not different from the old advice about recycling, etc. … Act locally, think globally.

 

Cheers,

David

 

On 23 Jun 2015, at 19:21, Chris Partridge <partridge.csj@xxxxxxxxx> wrote:

 

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

 

Chris

 

(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

 

 

 

 

From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Price
Sent: Tuesday, June 23, 2015 4:16 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Is Philosophy Useful in Software Engineering Ontologies?

 

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.

 

So, starting with the definition from a general dictionary like http://www.merriam-webster.com which says ontology is:

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

 

Cheers,

David

 

 

 

On 22 Jun 2015, at 22:15, Ravi Sharma <drravisharma@xxxxxxxxx> wrote:

 

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?

Regards,

Ravi

 

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:

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

 

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

 

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

 

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

>bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F Sowa

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

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

>  

>_________________________________________________________________

>Shared Files: http://ontolog.cim3.net/file/ Community Wiki:

>  

 

_________________________________________________________________

 

 

 

 



_________________________________________________________________
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
 




--

Thanks.
Ravi
(Dr. Ravi Sharma)
313 204 1740 Mobile


_________________________________________________________________
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
 



--
Thanks.
Ravi
(Dr. Ravi Sharma)
313 204 1740 Mobile

_________________________________________________________________
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)
[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  Re: [ontolog-forum] Test etc., Matthew West
Next by Date:  Re: [ontolog-forum] Need help on how to get around in this forum., Matthew West
Previous by Thread:  Re: [ontolog-forum] Is Philosophy Useful in Software Engineering Ontologies?, Edward Barkmeyer
Next by Thread:  Re: [ontolog-forum] Is Philosophy Useful in Software Engineering Ontologies?, Edward Barkmeyer
Indexes:  [Date] [Thread] [Top] [All Lists]