Re: [ontolog-forum] doing standards [was - Re: Webby objects]

[Amanda Vizedom <amanda.vizedom@xxxxxxxxx>]

Yes, all of those scary scenarios are scary. I wouldn't recommend the practices mentioned, such as abbreviation strings or other semi-meaningful IDs. Moreover, I wouldn't recommend anything that doesn't fit the actual use case; my advocacy of machine-generated opaque IDs is constrained to cases where there is sufficient payoff AND there is tool/interface/use support.  It is also an extension of the general principal: have the humans do what humans are good at; offload work that humans are really bad at to the machine, if it is better.

To clarify: 

The opaque IDs I imagine are machine-generated and for machine use. They can, if needed, be used when humans need to use absolutely unique identifiers without going through the machine, but without further detail I would constrain my recommendation to cases in which that's pretty rare.

Using opaque IDs works with tools that properly distinguish name and label. Humans should always be able to see labels. At minimum, they should see preferred labels appropriate to their context. Often, and easily if they choose, they should see more. This is very clarifying. The KR language and tools need to support this (and some do, but not the most common off-the-shelf ones) in all visualization and interaction modes.

If you have multiple and/or distributed user communities, if your ontology is used and developed multilingually (and especially cross-lingually), if your ontology is used with not only reasoning but NLP (as in semantic indexing, search and retrieval over web, federated, cross-domain, multilingual and/or other other corpora beyond narrow control), you will need to create all of these alternate labels anyway.

If this isn't your situation, then machine-generated opaque IDs might not be best for you, and I might not recommend 'em. If this is your situation, as it is with many struggling ontology projects, then they may really solve your problem, if you have the tool support.

Best,

Amanda

On Wed, Nov 28, 2012 at 12:06 AM, William Frank <williamf.frank@xxxxxxxxx> wrote:

I agree with Patrick, and with Ed's remarks


In fact, I think Ed's story:

   The other side of that coin is that the magic numbers become the terms of the language spoken by the in-crowd, ....

is scary. 

If an 'ontology' is something that is designed for computers to use, and not people, or only people who begin to mimic computers.

In addition, concepts of course should have identifiers (as always meaningingless strings), so it is scary that the edi codes ed mentions are NOT meaningless, but actually abbreviations for words.  For example, IFTMAN is clearly derived from 'freight manifest'.  So, if the latter may have multiple meanings, so may the former.

And, I find the increasing lack of collegiality, that leads to people getting *angry* when others even ask them what they mean by a term, let alone how angry they get when someone uses an _expression_ differently from them, is scarier still.  (I set this alot in various what-one-would-imagine-to-be technical forums)

So, to say that it is amazing that if we talk in numbers, we avoid arguments is scary to me, too.  Yup, computers don't argue overmuch.

The better solution, in my experience, is to

1. make sure that the identifiers are truly that, not meaningful,

2.  always use anywhere from two to five words as the *name* of a concept, never ever one, and a 141 character or less gloss.  And call it a gloss, not a comment.   With the understanding that the **meaning** of the concept is in the rules for its use, and not in the gloss or the name.

in other words, have three identifying items, an identifier, a name, a gloss.

On Tue, Nov 27, 2012 at 11:26 PM, Patrick Cassidy <pat@xxxxxxxxx> wrote:

Using human-friendly terms should not be a problem, if there is even a minimum of common collegiality in the process.  Whenever there is a dispute about whether some term should label one concept or another in one particular ontology, that bare term should be left unused and more specific variants can be used for concept representations that have different definitions.  So, instead of, e.g. a term “Process” (never defined the same way in any two upper ontologies I have seen), we might have “ContinuousProcess” for phenomena describable by differential equations, or “DiscontinuousProcess” for an Event represented as a series of steps (which may be considered instantaneous, or take some finite time, which distinction may lead to more refinement or expansion of the labels). When more than one ontology Is being considered, the formal way of doing this is just to use namespace prefixes so everyone can use the same label, but specify the namespace when creating the logical specification.  

 

I personally really hate using numbers or gensyms for labels, as I see no good reason not to use meaningful linguistic labels, and would rather not have to create and refer to a “label” property to remind me what the entity is intended to represent.  The actual logical specification is of course the definitive meaning, but it would be a waste of time to have to read that every time one encountered an ontological entity.  Linguistic labels can work just fine, used appropriately.

 

Pat

 

Patrick Cassidy

MICRA Inc.

cassidy@xxxxxxxxx

908-561-3416

 

From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ed Barkmeyer
Sent: Tuesday, November 27, 2012 6:52 PM

To: [ontolog-forum]
Subject: Re: [ontolog-forum] doing standards [was - Re: Webby objects]

 

Amanda Vizedom wrote:

Yep. I have seen the same thing elsewhere, as well; even though ontologists *know* that the concept names (vs. labels) are meaningless to the machine, the ontologists are still human language users and slip into various errors such as expecting names to carry a content burden and fighting over names.  I have also experienced the significant gains in usability and efficiency that can come from using concept IDs that are not easily interpreted by humans (e.g., hexadecimals at Convera). IMHO, that is the way to go -- it's amazing how much confusion is avoided when names are obviously there as unique handles but carry no meaning, and N-N mapping between NL terms and ontology terms is practiced and supported.

Yes, if you can get the community to maintain the discipline.

The other side of that coin is that the magic numbers become the terms of the language spoken by the in-crowd, and it becomes a jargon that freezes out those with an interest in the domain but lack that time or patience to deal with the black speech.  Supply-chain software people know what a DELJIT and an IFTMAN are.  They are the codes for EDI message types (shipment notifications and freight manifests) that have formal titles, aliases, and relatively clear textual descriptions, but the community doesn't use the titles or the descriptions.  They pronounce the codes, which mean nothing to the accountant or the man on the dock.

-Ed

 

Best,

Amanda

 

On Tue, Nov 27, 2012 at 5:22 PM, doug foxvog <doug@xxxxxxxxxx> wrote:

On Thu, November 22, 2012 16:59, Obrst, Leo J. wrote:
> Sure, Amanda, and that's why I (and we) advocate using natural
> language vocabularies that are linked/mapped to ontologies.

If you are referring to advocating the separation of NL vocabularies from
ontology term names, we certainly agree.  The ontology needs to express
an N-N mapping between NL terms and ontology terms.

> This was a hard lesson
> learned  (initially, by others, before my time) in the DoD in the early
> 1990s, and that I personally experienced in the metadata wars of the
> 2000s, where people will fight to the death to include their "words",
> mistaking these for the concepts behind them.*

This was a fight that the Cyc project thought it had solved in the
early '90s by establishing the 2-way mappings between NL & ontology
terms.  However, as Amanda well remembers, as new people came into
Cycorp, there were continual fights over what a term in the ontology
means -- and what it *should* mean, even when each of the competing
meanings were worthwhile concepts to have in the ontology.  This has
obviously continued after we both left.  You can find lots of terms in
OpenCyc whose names could be interpreted in multiple ways, yet whose
#$comments do little more than restate the name.  Often, the statements
remaining about the concepts in OpenCyc are not sufficient to understand
the intended meaning of the term.

> The important point is
> that if you shoehorn peoples'  semantics into "common" vocabularies
> or ontologies (and it's worse  for the  latter, because then you
> obliterate their differentiating semantics, not just how they refer to
> things), they may say they will agree with that concensus, but they will
> drag their feet, and the "information-sharing"  effort will fail.

Many ontologies (e.g., the OBO ontologies) get around this by using
numeric strings as IDs of the ontology terms, forcing people to look
at various comments and alternate names to understand what is
intended.

Also, +1 to Amanda's points, below.

-- doug foxvog

> *This also means that you need to differentiate between stakeholder
> committees and dedicated small ontology teams, where the latter work in
> the background to define the  semantics they hear the committee members
> (often domain experts) describe in the foreground.
>
> Thanks,
> Leo
>
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
> [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Amanda
> Vizedom
> Sent: Thursday, November 22, 2012 1:23 PM
> To: [ontolog-forum]
> Subject: Re: [ontolog-forum] doing standards [was - Re: Webby objects]
>
> <climbs atop a small pile of soapboxes>
>
> (1) Controlling language -- setting and using naming standards, for
> example, -- is *much* harder than building and using shared ontologies.
> Why? Because language and naming are things humans do/use constantly, are
> part of their natural behavior, are intertwined with cognitive and
> behavioral adaptations in many ways. And standardizing the language people
> use away from their ever-adapting expert language interferes with that
> adaptation. If the job needs to be done, the tension here is (correctly)
> going to resolve in favor of the adaptation and away from the
> standardization.
>
> (2) It is a central, advantageous feature of ontological representation
> that it can enable and support shared models, shared metadata, and
> interoperability *without* requiring controlled and standardized language
> use. Not all ontology-based projects have staff with sufficient training
> to understand and use that advantage. Those that don't use it end up
> bogged down in naming and language debates.
>
> (3) Available out-of-the-box tools (and standard KR languages) need to
> grow to support and emphasize this feature and ontologies (for example,
> via built-in support for specifying multiple labels for a concept, with
> lexical and localization information for those labels, and support for
> viewing/browsing an ontology with some specific localization used to
> select display labels. This is pretty easy compared to many other
> ontology-interaction problems. But it isn't there in the off-the-shelf
> stuff (in contrast, it *is* there in a range of commercial/proprietary
> and/or in-house tools that have to deal with multilingual, business
> vertical, or other localizations.
>
> (4) One reason people don't use ontologies more is because there is no
> consensus on quality and methodology, and they don't know who to trust.
> Those who say the have the One Methodology To Rule Them All are at best no
> better than everyone else at delivering something useful. That's because
> we *don't* need One Methodology To Rule Them All. We need a good
> understanding of what ontology features matter to what kinds of projects:
> that is, an understanding of what it means for an ontology to be suitable
> for an application, fit for a particular use case.
>
> (5) Until we build that kind of understanding -- at least a start -- some
> people who could benefit from ontology applications will continue to balk
> at the lack of clarity, while other people will go ahead but invest in
> ontology that is mismatched to the requirements. The latter experiences
> make the climate for ontology adoption worse.
>
> (6) I suggest that it should be very high on our priority list to work on
> building that shared understanding of the relationships between use case
> features and suitable ontology features. We can really only do that
> effectively as a community, sharing experiences and collaborating on the
> lessons learned. There are enough of us, across industries and sectors, to
> get going and make progress on this. There are also many who won't share
> just yet because they aren't sure whether the payoff of sharing outweighs
> their trained resistance to making in-house knowledge public. We can still
> move, and try to pick them up as we gain momentum.
>
> (7) A good ontologist can, in fact, come in and build something and make a
> difference in two weeks. BUT this assumes that it is clear what the
> ontology is for, how it will be used, what requirements come from
> downstream, and what sources are to be regarded as authoritative, AND that
> the ontologists is provided access to those sources. The reality is that
> the ontologist often walks into a situation in which few or none of those
> conditions are met. Sometimes it just hasn't occurred to anyone to do
> them; sometimes it has but no one knows how. Sometimes an experienced
> ontologist is actually there who knows how, but isn't give the authority
> or resource access to do this requirements identification. Result: value
> not delivered. I suggest that (6) is also important because it begins to
> address this problem by building shared understanding of what use case
> features are important to identify.
>
> </climbs down from soapboxes to go check on roasting turkey>
>
> Happy Thanksgiving!
>
> Best,
> Amanda
>
>
>
> On Thu, Nov 22, 2012 at 12:17 PM, David Eddy

> <deddy@xxxxxxxxxxxxx<mailto:deddy@xxxxxxxxxxxxx>> wrote:
> Peter -
>
> On Nov 22, 2012, at 10:24 AM, Peter Yim wrote:
>
>
> The basic question is "Why aren't practitioners using
> ontologies?"
>
> Because they're really, really, really HARD, aside from the fact that
> management has no idea what all the handwaving is about much less what any
> potential value might be.
>
> Plus the little detail of there being no foundation.  So ontologies are
> very much ivory towers in the clouds, particularly in commercial IT.
> Science/bio/pharma may very well be a different story since Mother nature
> has been carving the hierarchy for a few million years.  In commercial
> systems the concept of ordered hierarchies & languages is at best a
> distant fantasy.
>
>
> It has been my direct, commercial experience with Fortune 500
> organizations that very few (approaching none) have anything approaching

> something simple as "naming standards" (conventions—3 ring binders on

> the shelf, yes.  Enforced no.).  Obviously some systems have naming
> conventions, but that was typically driven by a single motivated
> individual & is not carried over to the next systems(s).
>
> Please to acknowledge the scale here... a Fortune 500 scale organization
> will have something like 1,000 to 5,000+ IBM mainframe applications.  This
> is not counting client/server, web, *nix, iSeries, etc.  Pretty much every
> one of those applications will have uniquely opaque language.
>
>
> I would argue that if the organization does not have the discipline to
> control its language something as pie-in-the-sky as ontologies is a castle
> in the sand.
>
> The reasoning/experience is that if they're as big & important as they are
> without naming standards, why bother.
>
> It is my assumption the same thinking & non-action carries over to the
> much more complex ontology domain.
>
> If the ontology consultant (that's singular) could show up on Monday &
> create something substantive in a week or two, AND get easy-to-use &
> understand results into the hands of the grunts, things would likely be

> different.  Requiring the grunts—the data entry/programmer/analyst folks
> doing the work—to learn yet another collection of technical languages is

> not a route to adoption.
>
> Does anything in the ontology domain deliver something that's as
> easy-to-use & mindlessly useful as a spellchecker?  Protege may be a
> wonderful product, but it's not even remotely close to being an end-user
> tool.
>
> - David
>
>
>
> _________________________________________________________________
> 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<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

 

-- 

Edward J. Barkmeyer                        Email: edbark@xxxxxxxx

National Institute of Standards & Technology

Systems Integration Division, Engineering Laboratory

100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528

Gaithersburg, MD 20899-8263                Cel: +1 240-672-5800

"The opinions expressed above do not reflect consensus of NIST, 

 and have not been reviewed by any Government authority."

_________________________________________________________________
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
 

--

William Frank

413/376-8167


This email is confidential and proprietary, intended for its addressees only.
It may not be distributed to non-addressees, nor its contents divulged,
without the permission of the sender.


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