[
Lists Home |
Date Index |
Thread Index
]
jonathan@openhealth.org (Jonathan Borden) writes:
>> jonathan@openhealth.org (Jonathan Borden) writes:
>> >When I think about ontologies I hardly think about processing at
>> >all. How exactly do ontologies intrude into your choices about
>> >processing?
>>
>> I see the meaning of markup as coming from the reader, whether that
>> reader is a human or a computer process. Ontologies strike me as a
>> deliberate effort to enforce a particular set of meanings across
>> processing contexts, so in that sense they affect the possibilities
>> I had open in my processing.
>>
>
>Fair enough. For certain, some types of writing are meant to be
>interpreted primarily if not completely by the reader, for example
>poetry.
There are, of course, poets (and definitely novelists) who have little
patience for the notion that meaning derives from the consumer rather
than the creator.
>Other types of writing are meant to be interpreted exactly by
>the reader as written by the author, for example: a medical
>prescription.
Prescriptions have a long and complex history. Pharmacists used to have
a good deal of discretion in how they filled out prescriptions, and they
certainly still have a role in cases where the pharmacist sees a drug
interaction that the doctor does not. "Dispense As Written" is a
current battlefield between doctors and insurers. There are a lot of
often conflicting perspectives here.
>Other documents are intended to fall somewhere in between.
I'd suggest that all documents fall in between, regardless of intention.
>Ontologies _are_ an effort to proscribe a deliberate _set of meanings_
>(as you write, this is spot on) between the reader and writer (i.e.
>across processing contexts if you wish to use this language). I hope
>you will allow that there are certain tasks for which it is essential
>that the reader and writer share a common understanding of the
>document (e.g. medical documentation).
Such efforts, insofar as they acknowledge that they are contingent
results, subject to further development and interpretation, may be
useful for categorizing and describing information. Unfortunately that
kind of acknowledgment of uncertainty seems frequently to fall to
grander visions of a unifiable representation of 'knowledge'.
Common understandings are useful, but I regard most ontology work as an
effort to create global understandings where local understandings are
both more flexible and workable without being globalized.
>> Beyond that, expectations that processing will be flexible enough to
>> handle changes in ontologies requires writing the processing in a
>> very different style, requiring my code to understand the ontologies
>> rather than just the markup.
>>
>> It may be declarative, but its impact reaches to the core of the
>> code.
>
>Ah, you expect your code to handle potential changes in the way the
>"world" is constructed! An admirable goal, but one not obtained by any
>software I know of. I certainly know little "code" that actually
>understands any extensive ontology I've seen -- perhaps we can start
>enrolling PCs in medical school in the next few years :-)))
>....
No, I don't expect my code to handle such changes. I do, however, hear
regular suggestions that ontologies provide a useful mechanism for
communicating such changes (and certainly alternate representations) to
programs - and that ontologies and code written around ontologies are
therefore more adaptive.
>> Thanks, but I don't need or want those burdens. It's not black
>> magic - it's merely naive faith in the coherence of logical
>> constructions built in a certain way of supposedly atomic facts. I
>> don't trust the premise, and I don't want the tools.
>>
>> Markup's premises are a lot smaller, far easier to comprehend, and
>> involve a lot less sleight of hand.
>
>Of course that is entirely true.
>
>It comes down to what you are trying to do. For certain tasks, such as
>those I frequently give examples of, dealing with markup _alone_
>doesn't solve the entire problem.
Markup alone solves no problems. Markup in particular contexts can be
very useful. You seem to find the creation of global contexts useful,
while I find them constraining and overwhelmingly tied to information
politics rather than technical need. Markup feels to me like an
opportunity to avoid such over-ambitious projects by letting people
label information using terms that are meaningful to them - and subject
to later interpretation.
>It's not helpful to me if you
>criticize a solution to a problem, without explaining an alternate
>solution. It's sort of like complaining that modern CPUs have too many
>transistors ... it may indeed be true, and it may be a noble goal of
>the computer industry to reduce the complexity of the next generation
>of CPUs, but for a guy that wants to transfer copies of DVs of his
>kids to a DVD, I really don't friggin' care about much except how much
>time I am sitting in front of the screen waiting for this task to get
>completed.
I think you've wandered off into irrelevant comparisons here.
>So please, if you are going to off hand dismiss my solutions, the
>least you can do is to try to understand the problems I am trying to
>solve. "Don't do that" doesn't quite cut it.
"Don't encourage that as a general solution" seems quite completely
appropriate to me. I lack sympathy for the problem-solving approach
you've chosen.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
