Rob - (01)
On Feb 15, 2010, at 5:27 PM, Rob Freeman wrote: (02)
>> It has been my experience that there are names/labels EVERYWHERE in
>> computers & software... variable names, column names on reports,
>> folders,
>> files, subroutines, methods, programs, schemas, ad infinitum. When
>> names/labels are done poorly (which is most of the time), then it
>> makes
>> understanding more difficult.
>
> Most of those labels are an attempt to make code more accessible to
> humans. I don't think there are many at, say, the assembly level, and
> even those could probably be eliminated. (03)
IF we accept that one of the major expected benefits of ontologies
is to
make it easier for information systems (e.g. software) to interoperate
(e.g. exchange accurate, meaningful data), then isn't it necessary to
have "meaningful" labels in & around software? (04)
Surely we're not thinking about some sort of magic where we "tell"
Silo A, B & C to interoperate & just sit back while it happens? (05)
Personally I have experienced that "good labels" are extremely useful.
In systems when the labels also reliably indicate what the data is,
that's
bordering on miraculous. The combination of the two is an extremely low
happenstance. (06)
I am reading your statements to mean that good labels are not necessary. (07)
What magic associated with ontologies will make good labels unneeded? (08)
>> Are you saying that names/labels are not relevant to ontology
>> efforts & get
>> in the way of ontology discussions?
>
> Names and labels are useful, even essential, for people. What gets in
> the way is arguing about them.
>
> We just have to accept that they are inherently subjective. Most
> arguments evaporate if you accept that. You can get on with finding
> where there is overlap between the labels you are used to, and the
> labels someone else is used to. (09)
How about if there were a mechanism (clearly yet to be defined) whereby
humans (maybe even programs?) could verify what a label means? (010)
Example: (Not necessarily universal, but within the context of a company
& its operating subsidiaries) (011)
[A] PostalZip Code (means the string of numbers or letters used in
a legal
mailing address) (012)
[B] Postal Code (the 7 character string representing .....) (013)
[C] Zip Code (the 5, 9, 11, or 13 set of digits in a mailing
address...) (014)
The problem today, of course, is that in a program or database a
field labeled
Zip Code, depending on how it's technically implemented (typically
not know
unless you're deep inside the code of the system) could actually also
contain
Postal (or Post) Codes. (015)
Such "minutia" plays havoc with interoperability efforts. (016)
I would posit that if I were a clueless programmer (explaining WHY a
programmer
is doing something is typically not in the cards) faced with an ill-
defined
data interoperability task, if I had a mechanism that I could easily
(<--- key
idea) look up what a label means in the relevant context of the
moment, that
would be a huge inch-pebble leap forward. (017)
Currently what labels (both good & bad) mean is walking around in
peoples
heads & not accessible to automation. (018)
>
>> Or is there some means to avoid opaque, difficult-to-understand,
>> ambiguous
>> labels in software?
>
> I think you could avoid the opaqueness, but then you would have to
> have some way to make the labels more ambiguous. Perverse, I know. (019)
MORE ambiguous!? (020)
Clearly you have something in mind... please to explain. (021)
> At root this rigid unambiguity is what makes software labels opaque,
> not ambiguity. (022)
> Actually, because the terms used in actual code are usually quite
> rigorously defined, software is one of the few places where you will
> find unambiguous labels. (023)
It's been my experience that terms in code are NOT rigorously defined.
They may start that way, but over time the tendency is to decay or
wander. (024)
I am thinking of the "nouns" in code... not the "verbs" of the actual
software language. The nouns are the business stuff that gets
collected,
stored & moved around. (025)
e.g. COMPUTE A = B + C. COMPUTE and + are verbs. A, B, and C are
nouns (labels). (026)
> We could probably move towards that quite rapidly if we accepted our
> labels need to be ambiguous, and focused our efforts on the
> interpretation process, not on searching for ideal labels. (027)
Dealing with software is fundamentally an UNDERSTANDING process.
Good labels speed up the process of understanding. (028)
I certainly do NOT believe in "ideal" labels since what works for me is
gibberish for you. (029)
Particularly in software, where most of the context has been stripped
away,
good labels are pretty much all you have to hold on to. (030)
What's important for good labels (names) is consistency (e.g. this means
assisting humans in a task that humans are not very good at) and some
sort of
mechanism that attaches definitions/meanings & context to the labels. (031)
Perhaps querying the mystical ontology repository could be such a
mechanism? (032)
___________________
David Eddy
deddy@xxxxxxxxxxxxx (033)
781-455-0949 (034)
_________________________________________________________________
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (035)
|