|
David,
I think you're still missing the concept - language distinction.
On Feb 26, 2012 5:54 PM, "David Price" <dprice@xxxxxxxxxxxxxxx> wrote:
>
> On 2/26/2012 9:34 PM, Amanda Vizedom wrote:
>>
>> Among the things beaten into the heads of ontologists-in-training (at least, if the training is any good) is that the name of the concept means nothing to the machine. The name has nothing to do with defining the concept, within the context of the computation artifact. The same is true if any text definition that may accompany it as a specialized comment. These are used by humans communicating to each other about the computational artifact, but they must always bear in mind that they are partial, misleading, and most importantly, opaque to the machine. That is, a concept in an ontology is defined by the formal assertions in which it is involved -- the ones that use the built-in formal semantics of the ontology language and other concepts built from those. Other things that may be attached to the concept may be used in other, non-inference computation (e.g., labels to help text analyzers spot possible references in unstructured data, code handles to help a federation engine find related data in external sources), but as far as the ontology core goes, only the formal assertions define a concept.
>
>
> In the development of applications I've seen, this simply isn't true. The meaning that's interesting to a user of any system (ontology or not) are in the algorithms, visualizations and analysis that depend completely on what the concepts of interest mean in the language of the discipline in which the application is used. That language is almost completely based on text read by a human - the software developer. The 'non-inference computation' is in no way secondary to the very limited capability available of logic languages in apps that support any engineering discipline, for example.
Yes, of course, the meaning that's interesting to the human user is the meaning of the language in use. That's not "what the concepts mean in a language," it's what the words, phrases, or other expressions mean in that language. From and ontological view, it's what concepts those expressions express (or refer to, or are used for, or (loosely) mean) in that language.
There are many ways of modeling what expressions in a language mean, all of which only capture it partially and for some kind of (human or machine) interpreter. A dictionary is one way to capture some of it for humans, for example. An ontology is another way, and it differs from the others partly by going through these abstract "concept" thingies. Those are precisely defined to behave iin accordance with certain logical and set-theoretic fundamentals. For at least this reason, they aren't pieces of natural language; they are artificial constructs used to model what the natural language is about.
> Let's not overdo what can be done with ontologies ... they are just one component of real world applications. They are an improvement over RDBs, UML, etc. but are by no means sufficient.
Of course! When ontologies are useful, they are most often useful as part of a larger system, in which they are but one component. It's important, though, to figure out what role an ontology is supposed to play in a given system, and whether and how an ontology can play that role. You seemed to be talking about how ontologies can help manage the polysemy of language across and even within systems. Since, from your questions, I'm pretty sure you never seen polysemy managed with ontologies in a good, successful way. I have, and I've seen that this is one of the specific things ontologies can be really good for. But I've also seen it fail when people used o ntologies without the needed features. And I've seen it fail when people don't understand the the concept/word distinction and get bogged down, still trying to get people to agree on single meanings for expressions when that's not necessary; they can identify all the concepts that an _expression_ is used for in their context, define those concepts separately, and map that _expression_ to all of them.
>> And, before somebody wonders how one could possibly work with and edit a massive ontology like that without readable names, the answer is, more easily than ever. You could view the concepts by ID only, or with the parenthetical inclusion of a preferred label in your language of choice. The presence of the ID first and the label in parens w/lang specified maintained awareness that the label is just one imprecise handle, and that you need to look at axioms, including placement in the overall ontology, to know what a concept is.
>
>
> We've had exactly the opposite experience - but you've ignored the problem this approach causes. It's not editing the ontology that's the issue. The issue is that if an ontology does not use meaningful names for concepts, then developing large applications that use an ontology are far more costly and error-prone because it's nearly impossible to develop, review and maintain the related software artifacts. In our case the names are local names in the URIs of OWL classes and the software artifacts are large, complex SPARQL SELECTs and CONSTRUCTs. We insist on sensible names for concepts (i.e. URIs) ... because software developers are people too and SPARQL is software.
No, you still see labels if you have good tools. If you are working with a large, multicontextual system, putting the meaning burden on names, and so pinning expressions to concepts across all contexts, leads to much more error and cost than if they can select context, even coarsely, and see the _expression_ for the concepts used in their own context. Else developers and users in whose context the selected "name" _expression_ does not match the concept it has been attached to not only aren't getting the right info from the concept names, they are continually getting misleading info.
>> I wish that practice were more widespread, and there were good, open tools to support it (that project used home-rolled tools, as most large successful ones seem to). Based on that experience, I would choose unreadable UIDs as concept names over the typical naming practice every time.
>
>
> I hope my issues point you and others away from recommending that as a best practice, at least for ontologies written using OWL.
For OWL, yes. OWL is not designed very well for support of complex semantic interoperability. It also lacks good support for lexical enrichment, needing at least significant extension before this is even possible. Also most OWL tools have non-overridable behaviors regarding the display of names and lab els. So, even if you put in rich, contextualized lexical information, you can't readily use it to support easier, more intuitive, more accurate ontology handling of the sort I described. So, yes, you really would have trouble using context-neutral, opaque names and contextualized labels as I described in OWL.
Otherwise, though, I'm mostly convinced that the concept / language distinction is still not widely or well enough understood for folks to readily see the power it can give ontologies. And probably writing long, wordy things like I'm doing isn't going to fix that; it needs illustration and demonstration. Going to put that into the hopper and churn on it a while.
Best,
Amanda
> Cheers,
> David
>
>
>> Best,
>> Amanda
>>
>> On Feb 26, 2012 3:54 PM, "Rich Cooper" <rich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> Dear Amanda and David,
>>>
>>>
>>>
>>> Amanda wrote:
>>>
>>> What probably causes the confusion is that the nodes in an ontology are not "terms" in this sense; they are NOT bits of language, which may have many meanings, but rather these nodes are *concepts*, abstracted from the various ways they might be expressed, in any language or jargon or context or by anyone. It *is* a rule of ontology that each abstract *concept* must have one formal definition/meaning; that's what makes it a *specific abstract concept*, and what makes it computable as part of an ontology. But there may be any number of ways of expressing this concept in language, symbols, etc., and any particilar bit of language may be associated with any number of different concepts. In an ontology, what it looks like for "terms", in the used-language sense, to have multiple meanings is that those terms are associated with multiple abstract concepts, where each of those concepts has a single, formal definition/meaning.
>>>
>>>
>>>
>>> It is an abstraction, IMHO, to call a concept by ANY linguistic term. That is, the concept has such depth of meaning when you look at how it interlocks with other concepts in the lattice that the phrases people use to describe the concept are misleading and even wrong at times – most times it seems.
>>>
>>>
>>>
>>> If concepts had some form of meaningless index, like a social security number, or other social construction that did not use English words, I could believe that the concept is different from the various terms used to describe it. But that is not the practice used on this forum to date. Concepts have always been described here by English terms, not by asemantic indexes.
>>>
>>>
>>>
>>> Given an index value, it could be wikified to show various English terms describing the concept for reference purposes. Then programmers could click on an index, get a pop up page of full description, and even search the set of indexes using Google like phrases to find a list of concept indexes which might be relevant. If that were done, I could believe that the index designates a set of abstract, language free concepts.
>>>
>>>
>>>
>>> But current practice is to refer to a concept with a word or phrase that captures only a tiny portion of the real semantics of that concept. Therefore David’s point of subjectivity blinding the philosophy of a concept set is very appropriate to the ways in which concepts are actually used in software development.
>>>
>>>
>>>
>>> When concepts are named with words or phrases, they are at least as ambiguous as the words or phrases.
>>>
>>>
>>>
>>> HTH,
>>>
>>> -Rich
>>>
>>>
>>>
>>> Sincerely,
>>>
>>> Rich Cooper
>>>
>>> EnglishLogicKernel.com
>>>
>>> Rich 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 Amanda Vizedom
>>> Sent: Sunday, February 26, 2012 12:26 PM
>>> To: [ontolog-forum]
>>> Subject: Re: [ontolog-forum] What goes into a Lexicon?
>>>
>>>
>>>
>>> David,
>>>
>>> Actually, I think that you *do* have it wrong. At least, when you say:
>>>
>>> "since as far as I know it's a hard & fast ontological rule that requires a term to have a single definition/meaning... an extremely unrealistic constraint for this sort of ugly real world challenge. [If I've got this wrong, please set me straight.] "
>>>
>>> Up to that point, your message seemed to be about lexicons, terminologies, and other bits of language. And of course, as you point out, these terminologies vary highly from one context to another, even as used by a singular person at different points in time.
>>>
>>> And you are right that some people have tried, using various modeling and standardization methods, to fix one meaning/definition for a term, where "term" = bit of language, word, phrase, abbreviation, _expression_, the kind of thing you would find in a lexicon or controlled vocabulary, and then tried and failed to use the result to represent content across heterogenous sources. Or tried and failed to impose this, top-down, on all data sources, users, systems, code, etc. Even within an enterprise with the supposed ability to enforce such uniformity, it fails. That approach simply doesn't fit with the realities of how people work, how meaning is bound up with context, how terminology evolves with use and how that local evolution is part of the development of expertise and efficiency.
>>>
>>> With respect to all of that, IMHO, you're absolutely right.
>>>
>>> Where things go wrong is in the bit I quoted above. It's absolutely NOT a hard & fast rule of ontology that each term have one definition/meaning, if by "term" you still mean what you meant in those previous paragraphs: a bit of language, word, phrase, abbreviation, _expression_, the kind of thing you would find in a lexicon or controlled vocabulary. In an ontology, each one of those things (e.g., each word, abbreviation, phrase...) can be associated with many different meanings. You might (or might not) even capture some relationship between those term-to-meaning associations and some context factors such as source, business process, localization, etc., if this is important for your usage. But even then, there is no restriction to one meaning per (language) "term" per context.
>>>
>>> What probably causes the confusion is that the nodes in an ontology are not "terms" in this sense; they are NOT bits of language, which may have many meanings, but rather these nodes are *concepts*, abstracted from the various ways they might be expressed, in any language or jargon or context or by anyone. It *is* a rule of ontology that each abstract *concept* must have one formal definition/meaning; that's what makes it a *specific abstract concept*, and what makes it computable as part of an ontology. But there may be any number of ways of expressing this concept in language, symbols, etc., and any particilar bit of language may be associated with any number of different concepts. In an ontology, what it looks like for "terms", in the used-language sense, to have multiple meanings is that those terms are associated with multiple abstract concepts, where each of those concepts has a single, formal definition/meaning.
>>>
>>> I hope that makes the matter a bit clearer. Where ontology is successfully used for interoperability, in environments where multiple meanings per used-language "term" are typical and assumed, the ontology can help by capturing and providing mappings between the polysemous used-language "terms" (including data values, field names, and unstructured or semi-structured text) and whichever, and however many, single-meaning abstract concepts those used-language terms are used for. So the used-language "terms" get to keep their many meanings; it's the abstract and formally defined *concepts* that must have just one.
>>>
>>> Again, I hope that clarifies thing a bit. It's made more confusing by the fact that the linguistic _expression_ "term" is used for multiple things. In some uses, "term" is used to mean a bit of used-language; in some uses, "term" is used to mean concept in an ontology. But despite that bit of typical, confusing polysemy, the fact is that ontologically, the bits of used-language can be associated with many meanings; it's the abstract concepts that have to have just one (though they can have many, and overlapping, used-language expressions).
>>>
>>> Best,
>>> Amanda
>>>
>>> On Feb 25, 2012 9:41 PM, "David Eddy" <deddy@xxxxxxxxxxxxx> wrote:
>>>
>>> Rich -
>>>
>>> On Feb 25, 2012, at 6:27 PM, Rich Cooper wrote:
>>>
>>> > Ontology
>>> > designers that produce a well documented, highly
>>> > learnable and usable ontology (i.e., something
>>> > simple and down in the details of a domain) could
>>> > provide a satisfying brick to many of those first
>>> > time developments.
>>>
>>>
>>> I am speaking in the context of the legacy software systems that
>>> enable our lives.
>>>
>>>
>>> The language/lexicon/terminology/slang/whatever already exists in the
>>> applications. Unfortunately it's pretty much been put together with
>>> a single ended one-time pad... & that guy(s) has left the building.
>>>
>>> The problem is, unless you have the SME sitting at your side, or lots
>>> & lots of time, the terminology is very difficult to grok. And when
>>> you move to the next assignment, the terminology/lexicon is very
>>> likely to be different, so you have to forget what you just spent 6
>>> months learning.
>>>
>>> I would likely argue that this language collection has not been
>>> accumulated with the idea of an organized ontology in mind.
>>>
>>> Imposing an organized ontology on this disorganized language
>>> collection probably isn't going be of much help.
>>>
>>> But something that quickly shows or records or suggests that in a
>>> particular context "no" actually means "id" (e.g. soc_sec_no....
>>> social security "number" is not a number, it's an index... a very
>>> different beast)... now that would be useful & likely to be embraced
>>> by the grunts—application owners, analysts, programmers—in the trenches.
>>>
>>>
>>> How ontologies could add value, I don't have a clue, since as far as
>>> I know it's a hard & fast ontological rule that requires a term to
>>> have a single definition/meaning... an extremely unrealistic
>>> constraint for this sort of ugly real world challenge. [If I've got
>>> this wrong, please set me straight.]
>>>
>>> ___________________
>>> David Eddy
>>> deddy@xxxxxxxxxxxxx
>>>
>>>
>>> _________________________________________________________________
>>> 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
>>
>
>
>
> --
> Managing Director and Consultant
> TopQuadrant Limited. Registered in England No. 05614307
> UK +44 7788 561308
> US +1 336-283-0606
>
>
>
>
> _________________________________________________________________
> 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)
|