|
Phil,
On Mar 2, 2012 3:35 PM, "Phil Murray" <pcmurray2000@xxxxxxxxx> wrote:
>
> Amanda --
>
> I have enjoyed your explanations, but in my experience
>controlled vocabularies -- including ontologies -- can easily
> provide names of concepts that are meaningful and useful
>to people, with little risk of developers making grossly
> unwarranted assumptions -- for example,
>
> "train (mode of transportation)"
> "train (clothing)"
> "train (astronomical phenomenon)"
Thanks. Yes, some version of this is common enough (varying syntactically and by the principles, if any, used to determine what goes in the parenthese (or after the dash or underscore, etc.).
> This is common practice in lexicography and knowledge
> organization. The parenthetical phrase is a "facet" (in the
> knowledge-organization/library science sense; perhaps not
> in the KR sense). This practice seems to work well. Do
> others use it?
It is certainly used at times. IME, the qualifier is not typically a facet or facet indicator, in any of the senses of "facet" I'm familiar with (LIS or ontological). More often it's a mid-level class of which the thing in question is an instance, or a class with "type of" prepended or "type" appended, if the thing in question is a subclass. But other qualifiers are used in other cases, depending on the distinctions that seem most relevant in the intended use context.
> Of course, it may not work well for everything.
>
> Additional notes can make other distinction clear, too.
>
> I'm assuming that the software does not impose unreasonable constraints on punctuation, etc.
>
> Or am I missing your point?
>
> Phil
>
Actually, for a machine-processed ontology, there often are some format constraints on name. Some part of the chain of components handling the ontology, or some language on which exports are made available for standards-compatibility or tool-neutrality reasons will be unable to handle some punctuation, white spaces, etc.. That can often be handled easily enough in automated transformations, but length cannot. Truncated names like those you've suggested, and you may be back to unclear variants of "train."
With an opaquename (label) system, names can generally be kept quite short, while a longer, intuitive name (label) pair, bulit from the name and lexical mappings together, can be used for human processing.
Length also matters for display, but that has to be managed with the opaquename (label) method also.
Agreed that additional notes can clarify to human users, as can the kind of label information I'm advocating for, as can selected ontological assertions and overall placement in an ontology. All of that is good practice to look at. Pragmatically, in many cases mappings, insertions, and selections need to be done quickly, and humans just don't have the time or robustness against tedium to consistently follow best practice. Less damage is done in those time- or resource- pressured development batches if the primary thing the human sees is as clear and disambiguating as is feasible, is not misleading, and is not playing into some basic human cognitive foible (like the draw to map a _expression_ or concept from elsewhere to a local concept with a string-matching name) that will generate errors under pressure.
Most fundamentally, though, I would say that the difference might be trivial if your ontology will never be used beyond the community for which it is initially developed, and that community has a certain degree of shared background and/or purpose.
The more diverse in backround and purpose the users are (where the difference can be as small as functional role within the same large enterprise), the less well it will work to rely on names with pre-selected qualifiers. The pre-selected expressions will rarely mean the same thing to all users, or be sufficiently relevant to distinguishing concepts from new concepts generated by different communities, or be intuitive and not misleading to all user communities. Differences in activity-based local jargon might render the expressions less opaque than differences in native natural language, but just as an en-uk and an en-us speaker often confuse each other in a way that an en-* speaker and an es-* don't approach, dialect or jargon differences within a single natural langauge are probably more likely to confuse and mislead.
So, the advantage here of going with opaque names and lexicalized, mapped labels is that many of the confusion and error-generation elements are dropped, while the intuitive labels, even qualified ones if desired, can be selected and used for primary display of concepts. And the modularity makes this selection more flexible and tool-selectable in a way most likely to be intuitive to the user.
Best,
Amanda
> Amanda Vizedom wrote:
>>
>> Pat +1!
>>
>> If they are logically inconsistent, they are not the same "term" where "term" = conceptual/ontological item.
>>
>> Systems A and B may use the same "term" where "term" = lexical item, to express different concepts. That's not a logical inconsistency. It's an ordinary difference in language (natural or artificial), and can be handled well by mapping those lexical expressions to different concepts.
>>
>> -Amanda
>>
>> P.s.: My controversial stand regarding labels grows in part out of the frequency and ordinariness of this situation. It's much harder for humans to do this mapping quickly and correctly when, say, Systems A and B use *lexicial* term "gruefulit" and some concept in the ontology ont1 is named "ont1:gruefulit." This exerts a strong cognitive pull towards mapping the lexical items SystemA-"grufulit" and SystemB-"gruefulit" to "ont1:grufulit." Since Systems A and B use lexical item "gruefulit" to express different concepts, if they are both mapped to ont1:gruefulit, that *will* be inconsistent. And mapping one but not the other to ont1:gruefulit makes thinks more confusing and harder to parse intuitively.
>> For this kind of usage, better accuracy and intuitiveness come from calling a concept ont1:0395 (some existing label), and deciding based on meaning whether it should also have labels ("gruefulit", sysA) or ("gruefulit", sysB) or neither.
>>
>>
>>
>> On Fri, Mar 2, 2012 at 00:38, Patrick Cassidy <pat@xxxxxxxxx> wrote:
>>>
>>> John,
>>> I am curious to know what kinds of inconsistency you are referring to:
>>>
>>> > So far, so good. But a problem arises when systems A and B
>>> > exchange messages that use only the "common" vocabulary defined
>>> > by the shared URIs. They may use the same terms, but their
>>> > specialized "senses" of the terms may be inconsistent.
>>>
>>> Does this refer to cases where two communicating systems define (or
>>> otherwise logically specify the intended meaning) of the *same* term (e.g.
>>> 'widget'), but use different definitions? Of course, they may be logically
>>> inconsistent. But don't the two terms have different URI's (assuming the
>>> URIs depend on the originating system)?
>>> In the interoperability scenario I have assumed that the mediating system
>>> that provides a translation of local systems depending on a common
>>> conceptual defining vocabulary would have to check for identity of
>>> definitions not in the common vocabulary, and *not* assign identity to two
>>> terms that do not have identical definitions, regardless of what local term
>>> is used to label that ontology construct.
>>>
>>> Pat
>>>
>>>
>>> Patrick Cassidy
>>> MICRA Inc.
>>> cassidy@xxxxxxxxx
>>> 908-561-3416
>>>
>>>
>>> -----Original Message-----
>>> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
>>> [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
>>> Sent: Thursday, March 01, 2012 10:17 AM
>>> To: ontolog-forum@xxxxxxxxxxxxxxxx
>>> Subject: Re: [ontolog-forum] Constructs, primitives, terms
>>>
>>> Dear Matthew, Chris, and Nicola,
>>>
>>> MW
>>> > One of the problems with primitives is that if you are developing
>>> > an ontology, then it is quite likely that entities that start out
>>> > primitive may acquire a complete definition over time.
>>>
>>> Yes, indeed. That is also a problem with URIs that are supposed to
>>> point to unique definitions. When you import such a definition into
>>> a context A that contains a lot of other axioms and definitions, the
>>> simple imported terms will be used in more specialized ways.
>>>
>>> Then if somebody else imports the same term into a different context B
>>> with different axioms (or procedures), it will be used in a different
>>> specialization.
>>>
>>> So far, so good. But a problem arises when systems A and B exchange
>>> messages that use only the "common" vocabulary defined by the shared
>>> URIs. They may use the same terms, but their specialized "senses"
>>> of the terms may be inconsistent.
>>>
>>> CM
>>> > It is impossible to define addition in terms of zero and successor.
>>> > The reason for this, in a nutshell, is that the addition symbol is
>>> > not eliminable; given the axioms for addition along with the axioms
>>> > for zero and successor, you can "say" things that you cannot say
>>> > in terms of the axioms for zero and successor alone...
>>>
>>> Yes. In general, a "closed form" definition can be eliminated.
>>> For example,
>>>
>>> f(x) = 3x^2 + 5x - 17
>>>
>>> You can replace any occurrence of f(y) by replacing x with y in the
>>> defining _expression_. But you can't do that for functions that are
>>> directly or indirectly defined by recursion. That is true of most
>>> terms in any realistic ontology.
>>>
>>> You can adopt a language that prohibits recursion, but that doesn't
>>> solve the problem. It just makes it impossible to state the full
>>> definition of your critical terms.
>>>
>>> Basic contradiction: You can't have a practical system with completely
>>> specified URIs and a restricted language to define them.
>>>
>>> NG
>>> > This is the reason why lightweight ontologies work very well as long as
>>> > their terms are simple and understood by everybody. When we have very
>>> > general, highly ambiguous terms, or technical terms whose meaning is
>>> > not understood by everybody, then the importance of a clear semantic
>>> > characterization (i.e., an axiomatic ontology) increases.
>>>
>>> Yes, indeed. And as in the examples by Chris, those axioms will be
>>> explicitly or implicitly recursive.
>>>
>>> The net result (Horror of Horrors!) is that your ontology language
>>> will be undecidable. But as anybody who has worked with any practical
>>> application knows, people have learned how to use undecidable languages
>>> in practical ways for real-world applications. In fact, decidable
>>> languages are *never* used in practical applications without having
>>> undecidable supplementary languages to do all the "heavy lifting".
>>>
>>> John
>>>
>>> _________________________________________________________________
>>> 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
>>
>
>
> --
> ---------------------
>
> The Semantic Advantage
> Turning Information into Assets
> phil.murray@xxxxxxxxxxxxxxxxxxxxx
> 401-247-7899
>
> Blog: http://semanticadvantage.wordpress.com
> Web site: http://www.semanticadvantage.com
_________________________________________________________________
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)
|