|
Ed,
Yes but... You create " models are formulations of the problem space" this is an essential difference from models of data about the problem space and this distinction is not made by many who use ontological languages for data modeling.
In trying to balance precision and intuitive conception some questions do seem to draw on philosophy, but not to the level of "objective reality ".
-cory
On Jun 23, 2015 12:59 PM, 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.
- a branch of metaphysics concerned with the nature and relations of being
- a particular theory about the nature of being or the kinds of things that have existence
and it is obvious that this much improved perspective wrt how do to good modeling is now widespread.
At the technical level, metaphysics has certainly been a major factor in the decisions made in the development of upper ontologies - so if you’re using an upper ontology you’re using a specific philosophy wrt the nature and relations of
being (and in particular change over time). I work in lots of different industries but in three large ontology-based apps in Oil and Gas we use ISO 15926 which is an ontology based in 4-dimensionalism. In the Defence industry, I am aware of IDEAS [1] that
is also using 4-dimensionalism.
Even if you don’t go to the rigour of using something like 4-dimensionalism, good ontologists question the nature of the things in their models using the same analysis approach used by philosophers for millennia. Returning again to Merriam-Webster
I think the most relevant of the various definitions of Philosophy is :
- a discipline comprising as its core
logic, aesthetics, ethics,
metaphysics, and epistemology
So I suggest that the question should be rephrase as follows: If you’ve not found Philosophy useful when creating ontologies, what exactly is it that you think you are doing? All I can imagine is that some folks are just encoding "old style"
models of data structures using ontology languages. If instead they are trying to model reality, then they are using Philosophy every day and just don’t know it.
While I absorb many good and deep observations from people with knowledge, is the viewpoint given below relevant to this thread? John did touch it a bit.
- Why use a word Ontology that has origin in philosophy - for IT or software engineering if it is not relevant?
- Can semantics be devoid of ontology context / vice versa?
- As discussed in this thread we describe real, model, physically measurable and repeatable science and engineering concepts (things) as these relate to basic philosophy concept "Ontology" using logic, language, programming and
IT tools?
- An example: software engineering became much more sturdy with inputs from business users rather than old software modules approaches of Mainframe era where the results from programmers were robust but did not accurately depict
the business processes because they did not understand fully the process they were modeling and had other technology limitations of that era.
- Would all this not make a case for at least a few to understand both worlds "ontology" with philosophy and "ontology" with IT / software solutions?
On Mon, Jun 22, 2015 at 12:52 PM, Azamat Abdoullaev <ontopaedia@xxxxxxxxx> wrote:
On Mon, Jun 22, 2015 at 10:44 PM, Azamat Abdoullaev <ontopaedia@xxxxxxxxx> wrote:
That is a good topic to discuss, Thomas.
Here is the content I recently uploaded online:
On Sun, Jun 21, 2015 at 8:18 PM, Thomas Johnston <tmj44p@xxxxxxx> wrote:
I think starting a new thread was a good idea, but I hope it's not just you and I who will contribute to it.
I'm glad you posed this explicit question. A great deal of philosophical discussion has been going on in Ontolog since I joined a few months ago. I think that many
of those discussions have illustrated the value of thinking philosophically. What I am recalling are discussions where something is said, and then where I, or someone else, points out that what was said didn't clearly distinguish between A and B, where (i)
A and B are different interpretations of what was said, and (ii) have been themselves recognized, at least by philosophers :-) , as being important distinctions, ones that lead to important different positions on issues such as what concepts are, how language
relates to the world, what it means to say that something exists, and so on.
But your question, I think, would be “So what? Why does an ontology engineering, building software to help us clarify a set of concepts for a particular subject
matter, need to know any of that stuff?” At least, that's the question I've set myself to answer. And you've put the shoe on the other foot, with your Socratic questioning. Socrates pissed people off by engaging them in conversation about something they thought
they knew about, and showing them that they really didn't it understand at all.
I hope I can do better. And I hope you won't let me get away with any sleights of hand.
Some ontologists work top-down, starting with really big concepts like Thing, Property, Relationship, Space, Time, Process, Event, Society and so on. These constitute
an upper-level ontology. Cyc has one (that I don't know much about); DOLCE has/is another (that I do know a little more about).
What's the value of that? Well, I'd say it's like the value that an enterprise data model (EDM) has for an enterprise. Over time, different databases in an enterprise,
and the apps that maintain and query them, develop in considerable isolation from one another. Seldom can an extract from database D1 be shipped over to database D1 and directly loaded into D2. Let alone differences in naming, a program is usually needed to
map D1's data onto D2's set of tables and columns, and that mapping is almost never 1:1.
These are the data stovepipes that all enterprises have. But if these databases could be modified so each one was a special case of a single EDM, then the mappings
in data exchanges would get closer and closer to 1:1. In other words, we would be getting closer and closer to meaning the same thing by X, Y, Z (e.g. “customer”, “product”, “restocking-event”, etc.) across all our databases. And if we shared an EDM with other
enterprises that we exchange data with, then we would all be converging on meaning the same thing by our shared concepts, concepts expressed as tables and columns in databases.
Working IT guys (of whom I used to be one) would call this eliminating stovepipes. Ontology engineers, so far as I understand, would call this establishing semantic
interoperability across all those databases.
So an EDM is like an upper-level ontology in this way. And there is another parallel. The different databases, D1, D2 and so on, in an enterprise have different
tables and columns, since each supports a different subject area. How do these tables and columns relate to the EDM of that enterprise?
Basically, the relationship is that these database-specific tables and columns should either be enlargements of the tables and columns in the EDM, or extensions
of those tables and columns. By “enlargements”, I mean that specific databases would add specific additional columns to their copies of those EDM tables. By “extensions”, I mean that all tables specific to a database would be implemented as subtype tables
of tables already defined in the EDM.
Of course, projects to do this never happen, because an enterprise just doesn't see the value of all that work. EDMs are often built, but the re-engineering needed
to make specific database conform to it never happens. What sometimes does happen is that far-sighted data modelers attempt to shoe-horn in EDM conformance work with the end-user-visible paying work of specific projects.
So as a first cut, the value of an upper-level ontology is like the value of an EDM. But since real EDMs seldom get as general as upper-level ontologies, I suggest
we see the value of having and using (or at least consulting) an upper-level ontology as eliminating stovepipe problems across different EDMs.
Later on, I'll try to give some concrete examples of interoperability problems that an upper-level ontology could help us avoid. But for right now, I want to shift
to the bottom-up perspective. When we get right down to Customer tables, Employee tables, Job Requisition tables, Inventory Fact Tables and Product Hierarchy Dimension tables, and so on, how does philosophy help?
Nearly everybody has a Customer table, so I'll use that as an example.
A customer is someone who purchases goods and/or services from us.
Is a customer always an individual person? If so, can anyone qualify as a customer? Or only adults legally competent to enter into financial relationships? Or only
adults with a credit score over 600?
If not, what kinds of groups can qualify as customers? Does a group have to have a tax-id number to qualify? Or can the Ladies' Sewing Circle open a customer account
with the Fabric Mega Warehouse company?
Under what circumstances will we (the enterprise) drop someone as a customer? When we turn their balance over to a Collections agency? And when do we do that (i.e.
what are the criteria for doing that)?
Can someone be enrolled as a customer (have a row in our Customer table created for them) prior to their making an initial purchase from us? If so, what triggers
their becoming a customer? Is it filling out an application? Or is it earlier in the relationship, for example when they first respond to any marketing material we may have issued?
The answers to all these questions usually are documented somewhere within the enterprise. Where is that? It's in the policies and procedures manuals of the enterprise.
Somewhere in the enterprise, at some point in time, someone does something that culminates in a new row being added to the Customer table (or a row being removed). The input to that initial action was some kind of request for the action to be performed. The
person involved must consult enterprise rules in deciding whether or not to proceed with that action. (Or have those rules in his head.)
Often, those rules are part of the work-a-day awareness of very low-level employees. Often, the supposed “subject matter experts” who are sometimes consulted if
IT decides to create a data dictionary for a new database, don't know all those specific rules. In which case, consulting those SMEs produces results like “A customer is someone who buys something from us”.
A philosopher is someone who knows that these rules exist, or should exist. A philosopher is someone who will ask the questions that will bring out these rules
(or their absence).
It doesn't require a PhD. But it does require an awareness that I have very seldom found in working business analysts, data modelers and DBAs.
So here is a semantic interoperability problem which could have been avoided if precise definitions had been used. Our enterprise has two divisions, Div1 and Div2.
The CEO wants to know which division has the most customers.
Each division has a Customer table, so each one runs a SQL Count query on its table. The results are: Div1 has 3,240 customers and Div2 has 5,882 customers. The
CEO tells the VP of Div1 that she isn't doing a very good job, and needs to add another two-thousand customers within the next year. The VP, of course, spreads panic within her division. After all, it's a VP-level bonus that's at stake!
She begins by dropping the credit score requirement. This will certainly mean that her A/R unpaid balances will go up, and that her collection agency will be getting
more business. But the CEO want more customers, and so more customers he will get.
It also turns out that Div2 counts as a customer anyone who has responded to Div2 marketing material. In Div1, there is a separate Prospects table to keep track
of those contacts. In other words, in Div1, prospects and customers are different kinds of things, whereas they are not in Div2.
These are specifically ontological decisions. In Div2, then, the change from a party being a prospect to being a full-fledged customer is a matter of the date-of-first-purchase
column being or not being null. In Div1, the change is a matter of one thing – a prospect – being removed from the database and another thing – a customer – being added. Aristotle called this difference the difference between accidental change and essential
change.
Well, being ontologically informed, the VP of Div1 decides to remove her ontological commitment to prospects. >From then on, she directs her staff, what they were
calling “prospects” will be called “prospective customers”, and what are currently called “customers” will be called “purchasing customers”.
A merely “verbal” matter? Not at all. A prospective customer is now a customer. This automatically added 800 new customers to Div1 – even though nothing in the
real world changed! And whereas Div1 had turned away 300 customer applications last year because of low credit scores, that won't happen from now on. So the Div1 VP can now anticipate an additional 300 or so customers in the coming year, assuming that application
rates remain the same.
It also turns out that Div2 has the policy that a customer would not be purged from the Customer table because of inactivity until ten years had passed since the
last purchase. Div1 had a policy of purging customers who had been inactive for only five years. So naturally, Div1's VP immediately changed their policy to leave inactive customers in the Customer table until ten years had passed without a purchase.
By the end of the year, the customer gap between Div1 and Div2 had narrowed considerably. The VP of Div1 got her bonus after all.
I said above that the VP of Div1 was “ontologically informed”. But, of course, she really didn't need any philosophy at all. She knew exactly what to do without
consulting Aristotle or Ockham.
So where's the value of philosophy in this story?
The value is in what could have been done. With an EDM whose tables were defined with as much precision as indicated above for customers, and with a policy of EDM
conformance across all divisions of the company, these policy issues – that the VP of Div1 most likely didn't even know about until her bonus became at risk – would have been explicitly considered, explicitly formulated, and implemented in the decisions about
when to add a row to a Customer table and when to delete a row from a Customer table. With these issues already decided, the customer counts in the two divisions would be comparable. With these issues decided, the two database queries would indeed be comparing
apples to apples.
OK, but all of that could be done by intelligent and skilled business analysts, data modelers and DBAs. How about the new ontology engineer the company just hired?
Does she have anything to contribute?
Indeed she does. Notice that in this panic-driven process of conceptual clarification, in Div1, it was people doing everything. People in Div2 comparing their policies
for adding and removing customers, their policies for distinguishing between customers and those non-customers they called prospects.
A really important thing would be to enable software to discover these differences, and when doing cross-database queries, to point out those differences in the
result sets returned. For this to happen, each of these policies, in each division, would have to be written down in some kind of formal language. For that to work, each of the key differentiators would have to be documented as a separate concept. A substantial
set of concepts would quickly develop, just to manage an ontology for customers.
Now software doesn't understand anything. But just as logic theorem provers can be relied on to generate only true statements from an initial set of true statements
– purely by mechanical means – so too semantic parsers, as I will call them, can do the same thing in the case of this example.
The parser would first do the two customer counts. It would then examine the formally-expressed definitions for each division. It would find that “has responded
to marketing material”, together with “legally eligible to enter into financial relationships”, was sufficient to generate a row in Div2's Customer table. And that those same two conditions were sufficient to generate a row in Div1's Prospect table. A sophisticated
parser would then add the Prospects count to the result set, so that there were now two counts for Div1, and would also note that these counts were combined in the one count for Div2. It would discover, and note in the result set, the other differences I mentioned.
Take just the prospects vs. customers issue. The annotated result set would clearly tell the people looking at it exactly what was going on. Using Div2's definition
of customer, the corresponding count for Div1 would be the sum of its customer and prospect counts. Using Div1's definition of customer, all we can tell is that there many be any number of prospects included in the single count for Div2.
A really sophisticated parser would examine the definition for each of Div2's columns and, let's suppose, finds the column “first-purch-date”, and further discovers,
by examining additional formally expressed definitional parameters, that the column is null, in any row, if and only if the party corresponding to that row had not yet made an initial purchase.
Now, with this additional information, the parser could also give a Div1 interpretation of the results. Div1, remember, had two counts returned – prospects and
customers. The parser can now return the same two counts for Div1. The Prospects count is the count of all rows in the Customer table whose first purchase date is null. The Customers count is all the other rows.
Now we've seen that there are any number of criteria that differ across different definitions of “customer” used in different databases. So the qualifications,
and the consequent different definitions of “customer” that a semantic parser could distinguish might be considerable. But if this formally expressed ontology that the parser uses had been agreed-on to begin with, then ideally there would be no qualifications,
and only one number returned for Div1 and one number for Div 2.
Think of this “semantic parser” as a DBMS. It processes the SQL Count statement against both Customer tables; but, having access to all these formally-expressed
distinctions, it can do all the neat things I've described.
To conclude for now, I think I've illustrated a role for a philosopher (aka ontologist) and for an ontology engineer. The ontologist (I'm going to switch over to
this term now, since it's the one involved in our prior discussions) is the person in all this who is aware of all the distinctions that might be involved in defining what a customer is, according to Div1 and Div2. The ontology engineer is the person who uses
those distinctions to build the formal apparatus needed by the semantic parser.
The value of ontology is that it provides better material for the ontology engineer than he is likely to come up with based only on his own intuitions.
So here's a promissory note for a later comment in this thread. How can anyone, no matter how ontologically aware, be aware of ALL the distinctions that might be
involved in defining what a customer is?
I think I actually have an answer to this question. There are hints of it in MTRD. It's a method I used during the last several years of my consulting career. If
I ever get around to carefully writing it up, I might even give it the exalted title of a “methodology”. However, it is not a mechanical way of coming up with high-quality definitions. There are no mechanical ways of coming up with definitions. But there are
a set of heuristics that I have found to generate much better definitions than the ones I used to produce, and better than anything else I ever found in the world of commercial IT.
Now please do your Socratic gadfly job, and point out what's unclear in all this, and what's inadequate in any other way (e.g. being just plain wrong).
Thanks for your ever analytical, thoughtful approach. I have changed the title from that old ugly thread to this bright new nondurant thread
that states the issues in a more constructive light.
LO:
Rich, have you ever wondered why there are only about 5-6 folks engaged here in Ontolog discussions? It’s because most of us have written these interactions off, as wastes of time. If
people are serious about this topic, it’s a real time drain. Why? Because the discussants are largely not serious about learning/understanding more: they simply want to argue their opinions.
I have to agree with you on that, Leo. I asked questions of each input, and with zero inputs from Patsy, and nearly zero explanations to my questions,
it seems ineffective to continue.
So this is a new thread wherein Tom wants to support the position that philosophy has value to software engineering, while I take the platonic
side and ask questions (chime in others with questions) to reach an unemotional conclusion, possibly somewhere between the two poles.
Chief Technology Officer,
MetaSemantics Corporation
MetaSemantics AT EnglishLogicKernel DOT com
Perhaps I'll eventually come to the same conclusions as Leo has. Prior to that time, I will try, as best I can, to be a Socratic gadfly to the
ontology engineers gathered in this forum.
Though it's a little unnerving to reflect on what Socrates' habits led him. Hopefully, the worst it will lead me to is perceived irrelevance to
the work of "real" engineers -- among whom I do not number myself.
Rich, have you ever wondered why there are only about 5-6 folks engaged here in Ontolog discussions? It’s because most of us have written these
interactions off, as wastes of time. If people are serious about this topic, it’s a real time drain. Why? Because the discussants are largely not serious about learning/understanding more: they simply want to argue their opinions.
Sorry, and I wish it was otherwise, believe me, as as I used to argue with Peter when he ruled the realm.
Software engineering provides you with very informal ontologies, that are actually embedded as interpretations by the programmer in the code. Try
to get that out and reuse it. Once we have very solid NL technologies that can do semantic interpretation and mappings to ontologies in specific domains and contexts, then … We won’t need you or me: way stations of limited understanding at best.
And how, exactly, does
philosophy provide understanding? So far in this thread, it hasn't provided a single concrete example.
Since Pat popped off with another stink bomb, I have yet to hear one single reason, one clear explanation of worth, as to why and how, specifically,
can philosophy contribute one simple clear thing to the endeavor of software engineering? Just a lot of one-offs.
Pat poops again, and returns to sleep without explaining. You respond below, again without explaining why
philosophy, of all things, has anything whatsoever to contribute to the endeavor of software engineering. There are already ontologies in each and every software system written today. Software engineering does require ontologies, but does not
require philosophy. And, it seems, philosophers on this list have not yet offered a single reason to the contrary.
Chief Technology Officer,
MetaSemantics Corporation
MetaSemantics AT EnglishLogicKernel DOT com
Yes, but the main result is that no one looks at the other side, and everyone expects the other side to provide them neat answers when needed.
And then neither side understands those neat answers, and so quibble, quibble forever. Understanding involves learning about both sides. This is not rocket science. We experience it every day when we map your database/ontology into mine, and vice versa. Interoperability
requires understanding. If neither party wants to understand the other side, then you do this seemingly infinite dance, which takes a LONG time.
If you think understanding something extraneous to your current situation and state of knowledge is important, you need to take the time to learn
about it. There are no miracles, no divine statements about why you should. Otherwise, you are a dilletante. Most of us are dilletantes in the areas we don’t think are imporant to us, or crucial for our real understanding.
LO: Of course it helps if ontology engineers/implementors acquire a deep understanding of philosophy,
RC: How exactly does "a deep understanding of philosophy" help engineers? That is certainly not obvious from the discussions here. Most of the
software people have agreed on objects and events as the basis of systems. The philosophers on the list keep debating about perdurants and endurants, and endless ways to split hairs that have nothing to do with the software structures required by serious
applications.
So please, describe why you think "a deep understanding of philosophy" can help engineers?
LO: and if philosphers acquire a deep understanding/practice of ontology engineers/implementors.
RC: Unless philosophers can somehow produce a payoff, a value as seen by the said engineers, what good are they to the engineers?
Dilletantes on either side obscure the issues of both, and spend their time on endless argumentation.
So far that seems to have been the progress of this thread.
Chief Technology Officer,
MetaSemantics Corporation
MetaSemantics AT EnglishLogicKernel DOT com
Of course it helps if ontology engineers/implementors acquire a deep understanding of philosophy, and if philosphers acquire a deep understanding/practice
of ontology engineers/implementors. Dilletantes on either side obscure the issues of both, and spend their time on endless argumentation.
>-----Original Message-----
>Sent: Friday, June 19, 2015 1:31 PM
>Subject: Re: [ontolog-forum] Ontologies and languages
>I completely agree with you:
>> What the history of Philosophy, and especially of ontology, shows us
>> is that important philosophers have not failed at the winnowing task,
>> but simply worked hard and carefully to -- with apologies for the
>> shift of metaphor -- slice the ontological pie in different ways.
>I would *never* try to stifle philosophical debate. That is absolutely
>essential for clarifying the issues and deciding what to represent, how
>to represent it, and what to do with the results.
>But everything that can be implemented on a digital computer can be
>expressed in first-order logic. Some extensions to FOL for supporting
>metalanguage and quantifying over relations and functions can simplify
>and clarify the mapping.
>What we have today is a huge amount of words taken out of context from
>the vast literature of philosophy and used to decorate the formal
>notations. It's OK to put some of those words (with citations to the
>original context) in the comments.
>But the meaning of the formalism is precisely defined by the model
>theory. None of the philosophical subtleties survive the translation
>from the original context into the software.
>When you use philosophical words to decorate the formal language, they
>are *worse* than useless because they confuse *everybody*:
> 1. The overwhelming majority of the programmers don't understand
> the philosophical issues. For them, those mysterious words
> may have some hidden meaning. So they carefully preserve them.
> 2. If those mysterious words weren't present, the programmers
> would examine the software to see exactly what is going on.
> But they have a vague feeling that those words have some
> deep power that goes beyond what is in the executable code.
> 3. For the philosophers who don't understand the software,
> they may have a comfy feeling that their ideas have somehow
> filtered down into the implementation. If so, they are
> even more confused than the programmers.
> 4. The result is a total breakdown in communication between
> the philosophers and the people who develop and use the
> software that is supposed to be based on the philosophy.
>My recommendation (copy below) is to force both sides to face the fact
>that digital computers are limited to FOL (or modest variations of
>FOL). Any terms that don't have a precisely defined mapping to FOL
>can't have any useful effect on any implementation -- but they can
>create a lot of confusion.
>Therefore, the philosophers and the implementers must agree on a simple
>terminology that *both* sides understand and that has a precisely
>defined mapping to what the computer does.
>______________________________________________________________
>As a general strategy, I would recommend:
> 1. A formal logic with the barest *minimum* amount of terminology.
> It must at least contain FOL + the option of quantifying over
> functions and relations + the option of using metalanguage for
> talking about whatever languages are being defined.
> 2. A huge *purging* of the immense philosophical terminology
> to a minimal set that is formally defined in the logic of #1.
> 3. The option of designing an open-ended family of formal notations,
> linear and/or graphic, that have a precise mapping to #1 and #2.
> 4. There may be huge debates about how to map NL terminology
> (including any and all terms in philosophy, science, business,
> the arts, etc., to the terms in point #2). But any proposed
> solution must be defined in the logic and minimal terminology of
> points #1 and #2 (or #3, which is defined in terms of #1 and #2).
>_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join:
http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
_________________________________________________________________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join:
http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
--
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
|